seminars
en, de
2005-
Oliver Klee, typo3-
Sat, 20 Dec 2025 17:54:33 +0000
The content of this document is related to TYPO3 - a GNU/GPL CMS/Framework available from www.typo3.org
If you like this extension, please submit a rating for it in the TER.
A TYPO3-12LTS-compatible version of this extension is available via an early-acces program.
If you would like to stay informed about this extension (including compatibility with newer TYPO3 versions), you can subscribe to the author's newsletter.
This extension allows you to create and manage a list of seminars, workshops, lectures, theater performances and other events as an overview or as detailed descriptions. In addition, it allows front-end users to register for these events.
Particularly, you can manage speakers, seminar sites and organizers and use them for the seminars. You can get an overview of how many people have registered for which seminar.
|img-1| Illustration 1: This is a front-end list a seminars. Note the color-coded number of vacancies in the last column.
|img-2| Illustration 2: This is the top of a front-end detailed view for a seminar.
|img-3| Illustration 3: This is the “my events” list for a logged-in front-end user.
|img-4| Illustration 4: This is the “my editor events” list where FE users that have been granted access may view the list of registrations for an event (this is useful e.g., for the organizers or the speakers).
|img-5| Illustration 5: This is the automatic configuration check (here: on the details page) having something to complain about.
If you would like to test the extension yourself, there is a DDEV-based TYPO3 distribution with this extension installed and some test records ready to go.
If you would like your site to be listed here, please drop the extension author a short email.
Thanks go to the following persons for contributing code, bug fixes or localizations or for doing code reviews:
Development of this extension has been funded by the following organizations and persons:
It is highly recommended to have your TYPO3 installation in composer mode. Without Composer mode, some functionality of the extension will not be available (e.g., inlining CSS in emails, and the CSV export (starting with seminars 5.2.0)).
If you want visitors to be able to register for your events without a FE login, using the onetimeaccount extension is recommended for this purpose.
As this extension follow semantic versioning, seminars 5.0 has all the breaking changes. So it is recommended you do the upgrade in the following order.
Also, clearing all caches after each step is recommended.
Some content elements have been removed in seminars 5.0.
Upgrade to seminars 4.4 and run the upgrade wizards (just to be sure).
If you would like to use the informal salutation mode in the frontend, set
plugin. in the
TypoScript constants (or conveniently in the constants editor).
If you are using a different currency than Euro (or you would like to tweak
the currency format), edit plugin.
in the TypoScript constants (or conveniently in the constants editor).
Starting with seminars 4.2, using the new FE editor is recommended. (The legacy FE editor was removed in seminars 5.0.)
Starting with seminars 4.3, using the new registration form is recommended. (The legacy registration form was removed in seminars 5.0.)
Starting with seminars 4.4, using the new backend module form is recommended. (The legacy backend module form was removed in seminars 5.0.)
Edit your backend user or user group permissions, grant the users/groups permissions for the new backend module, and drop their permissions for the old backend module.
Enable the seminars "URL segment" (slug) field for your editors. (Otherwise, you might get exceptions in the frontend if an event does not have a slug and your are using nice URLs for the single view.)
After having installed this extension (and the required extensions) via the extension manager, a few more steps are necessary to get the extension up and running:
IMPORTANT: All non-empty changes at the flexforms of the plug-in overwrite the settings of the corresponding TS setup. Empty data in the flexforms don't overwrite non-empty data from the TS setup, so if you want to overwrite non-empty values with empty values, you can enter a space or a comma (depending on the field).
Some of this extension's features require a FE user to be logged in, for example the event registration, the event management in the FE or access to the attendee lists. If you are not using any of these feature, you can skip this chapter.
There are two possible scenarios for the login page:
If you want to cover both scenarios, you can also use both plugins (on the same page.)
Allowing users to create an account with a double-opt-in process before they can log in is not, supported, though. (In that case, the redirect parameter to the registration page in the link to the login page will get lost.)
The onetimeaccount extension comes with two plugins:
Do not use this version anymore. (It was needed for the legacy seminars registration form that got removed in seminars 5.0.
Use this version with the the rewritten seminars registration form that was introduced in seminars 4.3.0.
Include the Seminars static template in your site template under “Include static (from extensions).”.
Then configure the plug-in in your TS template setup or the plug-in flexforms. The properties are listed in the reference.
Please note than when using flexforms, you need to set the corresponding values at all relevant instances of the plug-in: It doesn't do to specify the fields for the online registration in the seminar list front-end plug-in—you need to set these fields in the online registration front-end plug-in.
You can use this TypoScript setup template for setting all required values for a basic setup:
plugin.tx_seminars {
# PID of the sysfolder where event registrations (attendances) will be stored
attendancesPID =
}
# localizations for strings in emails and some FE parts go here (the example is for German)
plugin.tx_seminars._LOCAL_LANG.de {
}
plugin.tx_seminars_pi1 {
# PID of the sysfolder that contains all the event records (e.g., the starting point)
pages =
# PID of the FE page that contains the event list
listPID =
# PID of the FE page that contains the single view
detailPID =
# PID of the FE page that contains the "my events" list
myEventsPID =
# PID of the FE page that contains the seminar registration plug-in
registerPID =
# PID of the FE page that contains the login form or onetimeaccount
loginPID =
}
# localizations for FE-only parts go here (the example is for German)
plugin.tx_seminars_pi1._LOCAL_LANG.de {
}
# here you can change stuff like the number of items per page etc.
plugin.tx_seminars_pi1.listView {
}
Note that the notification email to the organizer and the list view show the headings even for empty fields, while the single view and the notification email to the participant remove the headings for some seminar properties (not all, just where it makes sense).
In addition to the website\_users\_folder , you need to create some system folders for storing records needed by this extension.
If you don’t have many events and you can keep the overview even if the event dates and the registrations are on one page each, you can create a minimal SysFolder structure like this:
|img-6| Illustration 6: SysFolder structure for minimum requirements
If you have only one page with one list view for the events, you can have all current event records in one system folder:
|img-7| Illustration 7: All current events in one folder
If it is okay for to have the registrations for all organizers arrive in one system folder or if you have only one organizer, you only need one folder for the registrations:
|img-8| Illustration 8: Registrations for all organizers in one folder
The following system folder structure is proposed for a full-blown installation with lots of events and different organizers that manage their registrations independently:|img-9| Illustration 9: Full blown installation
If you create these folders outside of the site root page with the template, you still need to create a template for them and “include static (from extensions)” in that template, or else the back-end module will not be able to use the extension's default configuration (e.g., the date and time format, so that date won't get displayed in the back-end module).
The user groups who should be able to manage seminars should have:
If you want to enter registrations manually for participants who don't have a front-end user account yet, or if you want to be able to edit the front-end user data, you need to set the following access rights as well:
If your site does not use the online registration feature, you have to explicitly disable that feature.
Your page structure can then look like this:
|img-10| Illustration 10: Page structure for a setup without online registration
Usually, you’ll want to use this extension with the online registration feature. For this, the minimal page structure will look like this:
|img-11| Illustration 11: Page structure for a minimal setup with online registration
For a full-blown registration with several list views, two archive pages, the “my events page” (where a user can see the events to which they have signed up), registrations lists for participants and s and front-end editing, the page structure would look like this (usually, you only need some of these pages):
|img-12| Illustration 12: Page structure for a full-blown setup
To enable users to unregister themselves from events (using the “my events” page), you need two things:
The category list shows all categories for which there are events in the selected system folders and in the selected time-frame. If your events are not assigned to any categories, the category list will be empty.
The category names are linked to the list view, filtered by that category (in other words: only events from the selected category are displayed).
This tutorial assumes that you already have set up a list view of your events.
This feature allows front-end users who have signed up for an event to see who has signed up for that event as well, e.g., for forming car pools or for coordination before the event takes place. In addition, this allows so-called editors (e.g., speakers or organizers of that event) to see that list as well. Both features are disabled by default. When using this feature, make sure that this complies with your privacy policy!
Both lists are set up separately. Even if you useboth lists, they need to be set up separately.
You can enter a list of FE user field names that will be displayed in the registration lists using the TS setup variable plugin.tx_seminars_pi1.showFeUserFieldsInRegistrationsList. The default is to only display the attendees' names.
Please note that there is no fine-grained access rights system: Either you allow all attendees to view the registration lists for all events for which they have signed up, or you don't.
If there is no “my events” page yet, create one. This page will show all events for which a FE user has signed up.
Now add a second page for the registration lists (preferably a sub page of the “my events” page), set it to not appear in the menu and set the page access to “show at any login.”
Now return to the page with the “my events” list and edit that content element again.
Please note that this feature has a rather fine-grained access right system: For each event, you can specify which FE users should be allowed to view the registration lists of that particular event.
Set up a “my editable events” page. This page will list exactly those events for which that particular FE user is set as an editor.
Now add a second page for the registration lists (preferably a sub page of the “my events” page), set it to not appear in the menu and set the page access to “editors.”
Now return to the page with the “my events” list and edit that content element again.
Warning
The CSV export currently will be empty if the b13/ package is
installed.
This extension offers a Scheduler Task to trigger actions. It can be configured to send reminders to the events' organizers
The reminders are emails with a localized text and the list of registrations appended as CSV.
To setup the CLI, do the following:
The mails send via Scheduler can contain a CSV file with the registrations to the event the mail is sent for. To customize the contents of the CSV file use the following options:
The Scheduler task also can send a (usually daily) digest of new registration. This functionality can be enabled and configured via TypoScript setup in the namespace plugin.tx_seminars.registrationDigestEmail.
The emails will use the language that has been set as default language for the Scheduler back-end user.
This extension has an automatic configuration checking feature which will check pretty much all configuration settings of this extension for sanity. If it has found anything that needs to be fixed, it will display a big red box with a message. This message will contain information about the following things:
To make sure that your configuration is correct, please log in as a front-end user and visit all of your pages that contain the Seminar Manager plugin-in. In the back end, please visit the back-end module.
The configuration check slightly decreases the performance of this extension. When your configuration is finished and approved by the checking feature, you can disable the feature in the extension manager.
Note: This feature still is pretty new and edgy. If you think that a particular warning message isn't correct (or you think that a a particular check is missing), please take a minute and file a bug in the bug tracker.
This extension uses a couple of different HTML templates:
Note: Do not change the HTML templates directly in the extension directory as then your changes will be overwritten when you upgrade the extension to a new version. Make a copy and modify the copy instead:
If you are using a different currency than Euro (or you would like to tweak
the currency format), edit plugin.
in the TypoScript constants (or conveniently in the constants editor).
You can set up to four different prices for each event: a “standard price” and a “special” price, e.g., for students and people in full employment (each of them can also be saved as an early bird price). In addition. In the registration form, the user can select the price to pay.
Events for free: In the single view, the standard price always gets displayed (even if it is 0.00), while the special price only gets displayed if it is not 0.00. This means that if you need to enter a price that is 0.00 (e.g., as a special discount), you need to enter this as the standard price and enter the non-zero price as the special price even if the non-free price technically is the standard price.
The early bird prices will only have an effect if you also define an early bird deadline (until when these prices are valid). If no early bird price is set or the deadline has already passed by, these prices won't be visible in the front end.
If you have only one price per seminar, you can configure the list view to not display the special price column (look in the reference for details). In addition, you might want to set some of the following options to just display “price” instead of “standard price”:
For the front-end view:
For the emails to the attendees:
If you have two prices for some or all seminars, you can change the default labels “regular price” and “special price,” e.g., to “Adults” and “Children.” You can change them using these variables:
For the front-end list view and detail view:
For the emails to the attendees and the drop-down box in the registration form:
Replace “ language ” with your two-letter language code if you use a language other than English, e.g., “de” for German. Use “default” as language code for English.
If you would like to use the informal salutation mode in the frontend, set
plugin. in the
TypoScript constants (or conveniently in the constants editor).
You can change most of the localized strings that are used on the front end and for the emails. (The localized strings for the back end cannot be changed.)
When you want to change some strings, please don't change locallang.xlf directly as these changes would get overwritten on the next update. Instead, do it like this:
On the second registration page, you can have up to two “terms & conditions” checkboxes. If you would like the checkbox labels to link to the page containing the terms & conditions (or if you would like to open that page as a pop-up), you can use some HTML for the checkbox label. For example, this will add a link to the first terms & conditions checkbox for a German site:
plugin.tx_seminars_pi1._LOCAL_LANG.de.label_terms = <a href="/index.php?id=1106&type=11" onclick="popup(this.href); return false">Die Allgemeinen Geschäftsbedingungen</a> habe ich gelesen und erkenne sie hiermit an.
You can do the same for the label\_terms\_2 label.
The extension provides its own basic set of CSS styles (which work best with a white background and if you're already using a CSS-based design and css_styled_content). These stylesheets usually get included automatically. However, if you have set disableAllHeaderCode = 1 and want to use the provided stylesheet , you need to include the stylesheet typo3conf/ext/seminars/pi1/seminars\_pi1.css manually into your page header.
The TR elements of the list view already have a few classes automatically set:
In the list view, the color of the squares in the vacancies column is configured using CSS. The table cell for the vacancies has three CSS classes:
The square itself also has a CSS class:
This allows you to configure the color of the square in detail, depending on the number of vacancies. The default style sheet uses:
The corresponding part of the default CSS file looks like this. You can do this likewise in your own style sheet:
.tx-seminars-pi1-vacancies-available .tx-seminars-pi1-square {
background-color: #00a500;
color: inherit;
}
.tx-seminars-pi1-vacancies-2 .tx-seminars-pi1-square, .tx-seminars- pi1-vacancies-1 .tx-seminars-pi1-square {
background-color: #ffff3c;
color: inherit;
}
.tx-seminars-pi1-vacancies-0 .tx-seminars-pi1-square, .tx-seminars- pi1-cancelled .tx-seminars-pi1-square {
background-color: #c30000;
color: inherit;
}
In the default configuration, this extension allows each user to register only one seat per event. This can be changed if you need users to register more than one seat per registration (e.g., when you use this extension for a theater, or you would like companies to register all their attendees in one go).
Please note that this doesn't enable users to register multiple times—it just allows them to enter the number of seats for their registration.
This is what needs to be changed:
If the field seats is not filled in (i.e., the registration is for 0 seats), the registration is counted as 1 seat.
Please note the the number of seats currently is not included in the automated email to the user. This will be implemented in a later version of this extension.
Only do this if you really trust your users to only enter serious events and no fun or test records.
Note
This is the new front-end editor that was introduced in seminars 4.2.0.
Important
I plan to remove this feature in seminars 6 as nobody seems to be using front-end editing of events nowadays. If you are using it, please let me know in order for me to keep this feature.
You can assign managers (front-end users) to each single event. These editors are allowed to see all registrations for the events where he/she is manually added as an editor.
If you want to allow a group of editors to see the registrations of all events, you can add all those editors to a group. Just add the UID of that group to the TS configuration plugin.tx\_seminars\_pi1.defaultEventVipsFeGroupID .
After clearing the cache, all members of that group will see all events on their “my editor events” page, and will be able to see the registrations list of all those events.
You can also set the group's uid in the flexform configuration or the plugin. But you will need to set it for each plug-in(on every page). It's easier to set it via TypoScript setup on a global page.
If you are linking to the list view from other pages, you can preselect stuff in the URL (by using the variables from the list view filter form):
&tx_seminars_pi1[place][]=1
&tx_seminars_pi1[event_type][]=3
&tx_seminars_pi1[category]=1
&tx_seminars_pi1[country][]=DE etc. (the uppercase ISO 3166 alpha2 code)
&tx_seminars_pi1[city][]=Berlin
&tx_seminars_pi1[language][]=EN (the uppercase ISO 639 alpha2 code)
This also works with combinations of these:
&tx_seminars_pi1[event_type][]=3&tx_seminars_pi1[place][]=3
&tx_seminars_pi1[place][]=1&tx_seminars_pi1[category]=1
You can not only preselect categories, but also specify search phrases directly in the URL. To do so, just add this to the URL of the page that contains the seminars list view:
&tx_seminars_pi1[sword]=searchphrase
If you want to use whitespaces make sure you replace them with %20, e.g.:
&tx_seminars_pi1[sword]=I%20am%20searching%20something
It's not necessary to have a search field on the list view activated. So you can specify search phrases in the URL to filter your results without offering the opportunity to specify other search phrases.
If you want to specify search phrases for a page by default without specifying parameters in the URL, just enter this to your Typoscript Setup:
plugin.tx_seminars_pi1._DEFAULT_PI_VARS.sword = searchphrase
If anyone opens this page, only trainings that match your search will be displayed.
Attention
Please enable the seminars "URL segment" (slug) field for your editors. Otherwise, you might get exceptions in the frontend if an event does not have a slug.
First run the upgrade wizards to generate the slugs for all event records. (You can change them later to suit your needs.)
Then add this to your site configuration file:
routeEnhancers:
EventSingleView:
type: Plugin
limitToPages:
- 17
routePath: '/{slug}'
namespace: 'tx_seminars_pi1'
_arguments:
slug: showUid
requirements:
slug: '[a-z0-9/\-]+'
aspects:
slug:
type: PersistedAliasMapper
tableName: 'tx_seminars_seminars'
routeFieldName: 'slug'If you already have route enhancers configured, add the Event
enhancer next to your other router enhancers.
The limit setting is optional, but required for better performance.
The given page UID(s) should be the page(s) on which the seminars single view
content element is located.
Add this to your site configuration file:
routeEnhancers:
EventRegistration:
type: Extbase
limitToPages:
- 18
extension: Seminars
plugin: EventRegistration
defaultController: 'EventRegistration::checkPrerequisites'
routes:
- routePath: '/check/{event}'
_controller: 'EventRegistration::checkPrerequisites'
_arguments:
event: event
- routePath: '/new/{event}'
_controller: 'EventRegistration::new'
_arguments:
event: event
aspects:
event:
type: PersistedAliasMapper
tableName: 'tx_seminars_seminars'
routeFieldName: 'uid'
registration:
type: PersistedAliasMapper
tableName: 'tx_seminars_attendances'
routeFieldName: 'uid'If you already have route enhancers configured, add the Event
enhancer next to your other router enhancers.
The limit setting is optional, but required for better performance.
The given page UID(s) should be the page(s) on which the registration form
content element is located.
Add this to your TypoScript setup:
config.pageTitleProviders {
eventTitle {
provider = OliverKlee\Seminars\Seo\SingleViewPageTitleProvider
before = record
}
}# Re-enable indexing for event single view pages, but not for the (empty)
# detail page without any event UID parameter
[traverse(request.getQueryParams(), 'tx_seminars_pi1/showUid') > 0]
page.meta {
robots = index,follow
robots.replace = 1
}
[global]You can use the PSR-14 event
\Oliver to change the slug
for an event before it gets written to the database.
Target groups of events are merely displayed, but don’t limit the registration in any way.
Examples: Adults, teenagers, single parents, sociologists.
This module provides easy-to-use access on event records, organizers, speakers and registrations.
Important: Only the records of the currently selected sysfolder get displayed. This means that you need to select different sysfolders if your records are located in several sysfolders (for examples you registrations might be places somewhere different than your event records).
Records that are created via this back-end module are saved in the currently selected sysfolder, too.
|img-29| Abbildung 13: Tab "Events" in the back-end module “Events”
Record type:
If an event needs to be canceled, you can cancel it by clicking on the “Cancel” button. This also sends an email to all registered participants:
|img-36| Abbildung 14: canceling an event
In the email form, there already is a default text which you can edit before sending the email. The placeholder %s will automatically be replaced with the participant’s name.
A canceled event still will be visible in front end, but is clearly recognizable as canceled (so that you don’t get tons of “Where can I find information about the event on the web site?” request after canceling it ;-) ). Registration for canceled events is not possible.
When you feel sure that an event is certain to take place (if enough participants have signed up and you’ve got the speakers’ okay), you can mark an event as confirmed by using the “Confirm” button. This also sends an email to the registered participants:
|img-37| Abbildung 15: marking an event as confirmed
Signing up for a confirmed event still is possible (as long as there are any vacancies); only the text in the confirmation email is a bit different.
|img-38| Abbildung 16: Tab "Registrations" in the back-end module “Events”
In this tab, all registration records of the currently selected sysfolder are displayed (i.e., of all events).
The first list Regular registrations contains those registrations that are not on the waiting list.
|img-39| Abbildung 17: Tab "Speakers" in the back-end module “Events”
In this tab, all speaker records of the currently selected sysfolder are displayed (i.e., of all events).
In this tab, all organizer records of the currently selected sysfolder are displayed (i.e., of all events).
Registration for an event is possible until the registration deadline. If the event has no such deadline, registration is possible until the start of the event.
When a logged-in front-end user registers for a seminar, the following happens:
From the “my events” page the user has the possibility to unregister from an event. When a user unregisters the corresponding attendances record will be marked as hidden.
In the **back-end module “Events”, you can
At the top in the event list in the back-end module Events , you’ll find a button labelled "Download as CSV file" that will save the data of all events on the current page as CSV.
At the top in the registration list for an event in the back-end module Events, you’ll find a button labelled "Download as CSV file" that will save the data of all registrations of the selected event as CSV, also including data from the registered FE user. Please note that the CSV file contains the columns for the data from the registration records first and then data from the corresponding FE user record.
The columns used for the export of
registrations is determined by the two configuration
variables fields and fields.
If you want to export the registrations on the waiting queue, you have to set
show to true.
The CSV export can be configured via TS Setup in plugin.tx_seminars for the page where the event records are located. Please see the reference for details.
CSV export of registrations is only available if:
You can edit registration records using Web > List as well as the back-end module Events.
Front-end users can unregister themselves from an event using the “my events” view if they are logged in and all of the following conditions are met:
You can also use this extension to record payments from participants for their seminar. If you have received a payment (be in in cash, bank transfer, credit card or whatever), edit the corresponding registration record and fill in the following fields:
If you want to record who has attended a seminar and who hasn't (e.g., for certificates), you can edit the corresponding registration record and fill in this field:
If you would like to link to the detailed description for a seminar (from other seminar descriptions or from any other page), you can use this format:
<URL of seminar listing page>?tx_seminars_pi1[showUid]=<UID of the seminar>
For example, if the URL of the seminar listing page is http://www.casebo.de/casebo-workshops.html and you would like to the seminar with the UID 27, the complete URL to that seminar would be this:
http://www.casebo.de/casebo- workshops.html?tx_seminars_pi1[showUid]=27
(In the links from the list view, the URLs contain an addition ampersand after the question mark, but that can be ignored.)
There are two sections in TS setup that contain setting for this extension: plugin.tx_seminars and plugin.tx_seminars_pi1.
You can configure the plug-in using your TS template setup in the form plugin.tx_seminars. property = value. The values in this table can only be configured using your TypoScript setup, but not via flexforms.
comma-separated list of section names that shouldn't be displayed in the thank-you email to the user
allowed values are in: hello, title, uid, ticket_id, price, seats, to tal_price,attendees_names,lodgings,accommodation,foods,food,checkbox es, kids, accreditation_number, credit_points, date, time, place, room,paymentmethod, billing_address,interests,url, footer,planned_disclaimer,unregistration_notice
cssFileForAttendeeMailDefault
Comma-separated list of section names from the registration that shouldn't be displayed in the notification email to the organizers. These fields are the big blocks in that email, and some are further divided.
Allowed values are in:
Default
Default
If there are at least this many vacancies, “enough” (localized) is displayed instead of the exact number.
Set this to a number higher than the highest number of vacancies if you want the exact number to be always displayed.
[tsref:plugin.tx_seminars]
You can configure the plug-in using flexforms of the front-end plug-in (for most values) or your TS template setup in the form plugin.tx_seminars_pi1. property = value.
If your want to set a value for all instances of the plug-in in one place, use the TS template setup. If you use flexforms, make sure to set the values at all relevant instances of the plug-in: It doesn't do to specify the fields for the online registration in the seminar list front-end plug-in—you need to set these fields in the online registration front-end plug-in.
Note: If you set any non-empty value in the flexforms, this will override the corresponding value from TS Setup.
The UID of an event record. If an event is selected, the plug-inalways shows the single view of this event and not the list.
This must be set using flexforms.
Default
comma-separated list of column names that shouldn't be displayed in the list view, e.g. organizers,price\_special
The order of the elements in this list has no influence on the output.Allowed values are in: category, title,subtitle,uid, event_type, language, accreditation_number, credit_points, teaser, speakers, date, time, expiry, place, city, country, seats, price_regular, price_special, total_price, organizers, target_groups, attached_files, vacancies, status_registration, registration, list_registrations, status, edit, imagePlease note that some columns will only be shown if a front-end user currently is logged in.
comma-separated list of field names that shouldn't be displayed in the detail view, e.g. organizers,price\_special
The order of the elements in this list has no influence on the output.Allowed values are in: event_type, title, subtitle, language, description, accreditation_number, credit_points, category, date, uid, time, place, room, expiry, speakers, partners, tutors, leaders, p rice_regular,price_special,additional_information, target_groups, attached_files, paymentmethods, target_groups, organizers, vacancies, deadline_registration, otherdates, eventsnextday, registration, back, image, requirements, dependencies
Default
Default
Default
Default
[tsref:plugin.tx_seminars_pi1]
For the list view, there are some additional configuration option that can only be set using the TS setup in the form plugin.tx_seminars_pi1.listView. property = value. Those values can not be set via Flexforms.
[tsref:plugin.tx_seminars_pi1.listView]
These configuration options can only be set via TypoScript setup within the plugin.tx_seminars.registrationDigestEmail namespace, not via flexforms.
These settings only affect the seminars Scheduler task.
Default
Default
Default
Default
[tsref:plugin.tx_seminars.registrationDigestEmail]
You can configure the plug-in using your TS template constant in the form plugin.tx_seminars_pi1. property = value.
[tsref:plugin.tx_seminars_pi1]
Events and hooks provide an easy way to extend the functionality of the this extension without blocking others to do the same.
Contents:
The following list contains the PSR-14 events of the seminars extension.
Contents:
The PSR-14 event
\Oliver
gets triggered after a slug has been generated or updated for an event record,
and before the slug gets written to the database.
Listeners may overwrite the slug if desired.
Registration of the event listener in the extension's Services.:
services:
# Place here the default dependency injection configuration
MyVendor\MyExtension\EventListener\Seo\SlugGeneratorEventListener:
tags:
- name: event.listener
identifier: 'generateEventSlugsWithUid'
The corresponding event listener class:
<?php
declare(strict_types=1);
namespace MyVendor\MyExtension\EventListener\Seo;
use OliverKlee\Seminars\Seo\Event\AfterSlugGeneratedEvent;
/**
* Generates event slugs in the format "slugified-title_uid".
*/
final class SlugGeneratorEventListener
{
public function __invoke(AfterSlugGeneratedEvent $event): void
{
$slugContext = $event->getSlugContext();
if ($slugContext->getEventUid() > 0) {
$event->setSlug($slugContext->getSlugifiedTitle() . '_' . $slugContext->getEventUid());
}
}
}
Warning
Using hooks requires in-depth knowledge of PHP classes, implementation of interfaces and seminars object internals.
Hooks allow extending the functionality of seminars without using XCLASSes. There are hooks for these parts of seminars:
Please contact us if you need additional hooks.
Important
seminars is undergoing a major rewriting to keep up with modern TYPO3 programming techniques. We try to keep changes as small as possible. Please inform yourself about changes by reading CHANGELOG.md, the DocBlocks of interfaces you implement and this chapter of the documentation before updating to a new seminars major version.
There is a hook into the single view. It is executed just before the template
gets rendered to HTML. You may set custom markers or change existing values for
markers. See also Classes/ for available
properties and methods.
Register your class that implements
\Oliver
like this in ext_ of your extension:
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['seminars'][\OliverKlee\Seminars\Hooks\Interfaces\SeminarSingleView::class][]
= \Tx_Seminarspaypal_Hooks_EventSingleView::class;Implement the methods required by the interface:
use OliverKlee\Seminars\Hooks\Interfaces\SeminarSingleView;
class Tx_Seminarspaypal_Hooks_SingleView implements SeminarSingleView
{
/**
* Modifies the seminar details view.
*
* This function will be called for all types of seminars (single events, topics, and dates).
*
* @param DefaultController $controller the calling controller
*/
public function modifySingleView(DefaultController $controller): void
{
// Your code here
}
}There are 4 hooks into the list view(s). First hook is called just before the seminar bag (the seminars to show in the list) or the registration bag (the seminars a user is registered for) is build. It is always called, even when there will be an empty list.
The other hooks are called during seminar list table creation:
my_event list: right after the row hook mentioned aboveIn these hooks you may set custom markers or change existing values for markers. See also
Classes/ for available properties and methods.
The hook to the seminar or registration bag building process allows for changing
the seminars/registrations shown in the list. You may add more filters or remove
existing ones. See also Classes/,
Classes/ and Classes/
for available properties and methods.
There are 7 types of lists your implementation must handle:
topic_list )seminar_list )my_events )my_vip_events )events_next_day )other_dates )The last two list types (events next day and other dates) are part of the single view, but handled as fully rendered seminar lists (including bag building).
Register your class that implements
\Oliver
like this in ext_ of your extension:
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['seminars'][\OliverKlee\Seminars\Hooks\Interfaces\SeminarListView::class][]
= \Tx_Seminarspaypal_Hooks_ListView::class;Implement the methods required by the interface:
use OliverKlee\Seminars\Hooks\Interfaces\SeminarListView;
class Tx_Seminarspaypal_Hooks_ListView implements SeminarListView
{
/**
* Modifies the list view seminar bag builder (the item collection for a seminar list).
*
* Add or alter limitations for the selection of seminars to be shown in the
* list.
*
* @see AbstractBagBuilder::getWhereClausePart()
* @see AbstractBagBuilder::setWhereClausePart()
*
* This function will be called for these types of seminar lists: "topics", "seminars",
* "my vip seminars", "my entered events", "events next day", "other dates".
*
* @param DefaultController $controller the calling controller
* @param EventBagBuilder $builder the bag builder
* @param string $whatToDisplay the flavor of list view: 'seminar_list', 'topic_list',
* 'my_vip_events', 'events_next_day' or 'other_dates'
*/
public function modifyEventBagBuilder(
DefaultController $controller,
EventBagBuilder $builder,
string $whatToDisplay
): void {
// Your code here
}
/**
* Modifies the list view registration bag builder (the item collection for a "my events" list).
*
* Add or alter limitations for the selection of seminars to be shown in the
* list.
*
* @see AbstractBagBuilder::getWhereClausePart()
* @see AbstractBagBuilder::setWhereClausePart()
*
* This function will be called for "my events" lists only.
*
* @param DefaultController $controller the calling controller
* @param RegistrationBagBuilder $builder the bag builder
* @param string $whatToDisplay the flavor of list view ('my_events' only?)
*/
public function modifyRegistrationBagBuilder(
DefaultController $controller,
RegistrationBagBuilder $builder,
string $whatToDisplay
): void {
// Your code here
}
/**
* Modifies the list view header row in a seminar list.
*
* This function will be called for all types of seminar lists ("topics",
* "seminars", "my seminars", "my vip seminars", "my entered events",
* "events next day", "other dates").
*
* @param DefaultController $controller the calling controller
*/
public function modifyListHeader(DefaultController $controller): void
{
// Your code here
}
/**
* Modifies a list row in a seminar list.
*
* This function will be called for all types of seminar lists ("topics",
* "seminars", "my seminars", "my vip seminars", "my entered events",
* "events next day", "other dates").
*
* @param DefaultController $controller the calling controller
*/
public function modifyListRow(DefaultController $controller): void
{
// Your code here
}
/**
* Modifies a list view row in a "my seminars" list.
*
* This function will be called for "my seminars" , "my vip seminars",
* "my entered events" lists only.
*
* @param DefaultController $controller the calling controller
*/
public function modifyMyEventsListRow(DefaultController $controller): void
{
// Your code here
}
/**
* Modifies the list view footer in a seminars list.
*
* This function will be called for all types of seminar lists ("topics",
* "seminars", "my seminars", "my vip seminars", "my entered events",
* "events next day", "other dates").
*
* @param DefaultController $controller the calling controller
*/
public function modifyListFooter(DefaultController $controller): void
{
// Your code here
}
}There is a hook into the selector widget of the list view. If the selector widget
is activated, the hook is executed just before the template gets rendered to HTML.
You may set custom markers or change existing values for markers. See also
Classes/ for available properties and methods.
Register your class that implements
\Oliver
like this in ext_ of your extension:
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['seminars'][\OliverKlee\Seminars\Hooks\Interfaces\SeminarSelectorWidget::class][]
= \Tx_Seminarspaypal_Hooks_EventSelectorWidget::class;Implement the methods required by the interface:
use OliverKlee\Seminars\Hooks\Interfaces\SeminarSelectorWidget;
class Tx_Seminarspaypal_Hooks_EventSelectorWidget implements SeminarSelectorWidget
{
/**
* Modifies the seminar widget, just before the subpart is fetched.
*
* This function will be called for all types of seminar lists, if `displaySearchFormFields` is configured for it.
*
* @param SelectorWidget $selectorWidget
* @param EventBag $seminarBag the seminars used to create the selector widget
*/
public function modifySelectorWidget(
SelectorWidget $selectorWidget,
EventBag $seminarBag
): void {
// Your code here
}
}There are the following hooks into the registration notification emails:
You may set custom markers or change existing values for markers in the template hooks.
See also Classes/ for available properties and methods.
The plain text hook is always called, because a HTML email always contains a plain text version, too.
The HTML hook is called only if emails are sent as HTML.
With the other hooks you may modify the complete Mail object (e.g. sender or receiver addresses,
subject line or the complete body). See also sysext/ for
available properties and methods.
Register your class that implements
\Oliver
like this in ext_ of your extension:
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['seminars'][\OliverKlee\Seminars\Hooks\Interfaces\RegistrationEmail::class][]
= \Tx_Seminarspaypal_Hooks_RegistrationEmail::class;Implement the methods required by the interface:
use OliverKlee\Seminars\Hooks\Interfaces\RegistrationEmail;
class Tx_Seminarspaypal_Hooks_RegistrationEmail implements RegistrationEmail
{
/**
* Modifies the attendee "Thank you" email just before it is sent.
*
* You may modify the recipient or the sender as well as the subject and the body of the email.
*
* @param string $emailReason Possible values:
* - confirmation
* - confirmationOnUnregistration
* - confirmationOnRegistrationForQueue
* - confirmationOnQueueUpdate
*/
public function modifyAttendeeEmail(
MailMessage $email,
Registration $registration,
string $emailReason
): void {
// Your code here
}
/**
* Modifies the attendee "Thank you" email body just before the subpart is rendered to plain text.
*
* This method is called for every confirmation email, even if HTML emails are configured.
* The body of a HTML email always contains a plain text version, too.
*
* You may modify or set marker values in the template.
*
* @param Registration $registration
* @param string $emailReason Possible values:
* - confirmation
* - confirmationOnUnregistration
* - confirmationOnRegistrationForQueue
* - confirmationOnQueueUpdate
*/
public function modifyAttendeeEmailBodyPlainText(
Template $emailTemplate,
Registration $registration,
string $emailReason
): void {
// Your code here
}
/**
* Modifies the attendee "Thank you" email body just before the subpart is rendered to HTML.
*
* This method is called only, if HTML emails are configured for confirmation emails.
*
* You may modify or set marker values in the template.
*
* @param Registration $registration
* @param string $emailReason Possible values:
* - confirmation
* - confirmationOnUnregistration
* - confirmationOnRegistrationForQueue
* - confirmationOnQueueUpdate
*/
public function modifyAttendeeEmailBodyHtml(
Template $emailTemplate,
Registration $registration,
string $emailReason
): void {
// Your code here
}
/**
* Modifies the organizer notification email just before it is sent.
*
* You may modify the recipient or the sender as well as the subject and the body of the email.
*
* @param string $emailReason Possible values:
* - notification
* - notificationOnUnregistration
* - notificationOnRegistrationForQueue
* - notificationOnQueueUpdate
*/
public function modifyOrganizerEmail(
MailMessage $email,
Registration $registration,
string $emailReason
): void {
// Your code here
}
/**
* Modifies the organizer additional notification email just before it is sent.
*
* You may modify the recipient or the sender as well as the subject and the body of the email.
*
* @param string $emailReason Possible values:
* - 'EnoughRegistrations' if the event has enough attendances
* - 'IsFull' if the event is fully booked
* see RegistrationManager::getReasonForNotification()
*/
public function modifyAdditionalEmail(
MailMessage $email,
Registration $registration,
string $emailReason
): void {
// Your code here
}
}It is also possible to extend the salutation used in the emails with the following hook:
To use this hook, you need to create a class with a method named modifySalutation. The method in your class should expect two parameters. The first one is a reference to an array with the following structure:
array('dear' => String, 'title' => String, 'name' => String)
The second parameter is an user object FrontEndUser.
Your class then needs to be included and registered like in this example:
// register my hook objects
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['seminars']['modifyEmailSalutation'][] = \MyVendor\MyExt\Hooks\ModifySalutationHook::class;There are hooks into the date and time span creation of the seminars. If at any place a date or time span
is required, these hooks are called to allow modification of the date or time span assembling. See also
Classes/ for details about the default methods.
Register your class that implements
\Oliver
like this in ext_ of your extension:
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['seminars'][\OliverKlee\Seminars\Hooks\Interfaces\DateTimeSpan::class][]
= \Tx_Seminarspaypal_Hooks_DateTimeSpan::class;Implement the methods required by the interface:
use OliverKlee\Seminars\Hooks\Interfaces\DateTimeSpan;
class Tx_Seminarspaypal_Hooks_DateTimeSpan implements DateTimeSpan
{
/**
* Modifies the date span string.
*
* This allows modifying the assembly of start and end date to the date span.
* E.g., for Hungarian: '01.-03.01.2019' -> '2019.01.01.-03.'.
*
* The date format for the date parts are configured in TypoScript (`dateFormatYMD` etc.).
* Get them from `$dateTimeSpan->getConfValueString('dateFormatYMD')` etc. The event
* dates are also retrievable:
* `$beginDateTime = $dateTimeSpan->getBeginDateAsTimestamp();`
* `$endDateTime = $dateTimeSpan->getEndDateAsTimestamp();`
*
* @param string $dateSpan the date span produced by `AbstractTimeSpan::getDate()`
* @param AbstractTimeSpan $dateTimeSpan the date provider
* @param string $dash the glue used by `AbstractTimeSpan::getDate()` (may be HTML encoded)
*
* @return string the modified date span to use
*/
public function modifyDateSpan(
string $dateSpan,
AbstractTimeSpan $dateTimeSpan,
string $dash
): string
{
// Your code here
}
/**
* Modifies the time span string.
*
* This allows modifying the assembly of start and end time to the time span.
* E.g., for Hungarian: '9:00-10:30' -> '9:00tol 10:30ban'.
*
* The time format for the time parts is configured in TypoScript (`timeFormat`).
* Get it from `$dateTimeSpan->getConfValueString('timeFormat')`. The event
* times are also retrievable:
* `$beginDateTime = $dateTimeSpan->getBeginDateAsTimestamp();`
* `$endDateTime = $dateTimeSpan->getEndDateAsTimestamp();`
*
* @param string $timeSpan the time span produced by `AbstractTimeSpan::getTime()`
* @param AbstractTimeSpan $dateTimeSpan the date provider
* @param string $dash the glue used by `AbstractTimeSpan::getTime()` (may be HTML encoded)
*
* @return string the modified time span to use
*/
public function modifyTimeSpan(
string $timeSpan,
AbstractTimeSpan $dateTimeSpan,
string $dash
): string
{
// Your code here
}
}The hook classes need to be registered and written like this:
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['seminars']['backEndModule'][]
= \tx_seminarspaypal_Hooks_BackEndModule::class;It's used like this:
class BackEndModuleHook implements BackEndModule {
/**
* Modifies the general email sent via the back-end module.
*
* Note: This hook does not get called yet. It is just here so the interface
* is finalized.
*
* @param Registration $registration
* the registration to which the email refers
*/
public function modifyGeneralEmail(Registration $registration, MailMessage $email): void {…}There is a hook into the CSV generation of registration lists to modify the generated CSV text.
Register your class that implements
\Oliver
like this in ext_ of your extension:
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['seminars'][\OliverKlee\Seminars\Hooks\Interfaces\RegistrationListCsv::class][]
= \Tx_Seminarspaypal_Hooks_RegistrationListCsv::class;Implement the methods required by the interface:
use OliverKlee\Seminars\Hooks\Interfaces\RegistrationListCsv;
class Tx_Seminarspaypal_Hooks_RegistrationListCsv implements RegistrationListCsv
{
/**
* Modifies the rendered CSV string.
*
* This allows modifying the complete CSV text right before it is delivered.
*
* @param string $csv the CSV text produced by `AbstractRegistrationListView::render()`
* @param AbstractRegistrationListView $registrationList the CSV data provider
*
* @return string the modified CSV text to use
*/
public function modifyCsv(string $csv, AbstractRegistrationListView $registrationList): string
{
// Your code here
}
}There is a hook into the data handler to additionaly manipulate seminars FlexForm data during
TCE validation (just before storing the data). You may apply additional constraints and dynamically
adjust values (e.g. registration deadline = begin date - 14 days).
TCE validation is a TYPO3-defined process. seminars gets the form values from the content element's
FlexForm and stores required changes of the values into the database.
Register your class that implements
\Oliver
like this in ext_ of your extension:
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['seminars'][\OliverKlee\Seminars\Hooks\Interfaces\DataSanitization::class][]
= \Tx_Seminarspaypal_Hooks_DataSanitization::class;Implement the methods required by the interface:
use OliverKlee\Seminars\Hooks\Interfaces\DataSanitization;
class Tx_Seminarspaypal_Hooks_DataSanitization implements DataSanitization
{
/**
* Sanitizes event data values.
*
* The TCE form event values need to be sanitized when storing them into the
* database. Check the values with additional constraints and provide the modified
* values to use back in a returned array.
*
* @param int $uid
* @param mixed[] $data the events data as stored in database
*
* @return mixed[] the data to change, [] for no changes
*/
public function sanitizeEventData(int $uid, array $data): array
{
// Your code here
}
}In some cases, the list view in the front-end plug-in may be empty. Do this:
b13/bolt package is
installed.b13/bolt package is installed.