This site showcases a fully working installation of the extension with realistic sample data. It’s a great way to
see how events and registrations are presented in the frontend.
If you like this extension and want to say thanks, feel free to drop me an email or sponsor the
development of the extension. Please also consider to support the TYPO3 community by sponsoring
events, code sprints or by becoming a TYPO3 association member.
Thanks from me to:
Georg Ringer for his extension "news", from where I adapted some concepts and code I use in this extension
Alexander Kellner for his extension "powermail", from where I adapted some concepts and code I use in this extension
Thies Kracht who developed the CSV export
Phat Hoang and Oleksandr Bachynskyi from Pixelant AB for their ideas and contributions
Phat Hoang from Pixelant AB for the reCAPTCHA implementation
Jean-François Sillen from Wikafi S.P.R.L for sponsoring the sys_category refactoring
Jean-François Sillen from Wikafi S.P.R.L for sponsoring the price option feature
W52 MarketingKommunikation GmbH for sponsoring the waitlist, user registrations frontend plugin and email attachments
New Communication GmbH & Co. KG for sponsoring and ideas
Tymoteusz Motylewski for implementing event speakers and other contributions
Gerd Müller from Vogt-Schild Druck AG for sponsoring organisator filtering
Alexander Grein from Mediaessenz for implementing the default storage Pid feature
Bernhard Sirlinger for adding the automatic RealURL config
Marc Bastian Heinrichs for adding Cache Tags in list and detail view and for implementing the checkPidOfEventRecord setting
Rune Piper for several code cleanups and Pull Requests
Haisam Zehrawi from SeminarPool GmbH for sponsoring refactoring in the CSV export
Stefano Kowalke for several Pull Requests
Manuel Munz for adding additional registration fields
Christoph Lehmann for several Pull Requests
Christoph Lehmann from networkteam GmbH for sponsoring the backport of user generated content in custom notifications.
Der PARITÄTISCHE Wohlfahrtsverband Hamburg e.V. for sponsoring the GDPR clean command
mediaconcept GmbH for sponsoring the metadata feature for events
A price option can be added to an event record to allow the user
to select a price during the registration process.
Events
Events are the main record of this extension. An event contains several fields, which can be used to
describe the event in detail.
General
The general tab is used to add general information about the event like a title, start- and enddate
and a description.
Field:
Description:
Title
Title of the event.
Top event
If checked, the event is considered as a top event
Startdate
Date and time, when the event starts.
Enddate
Date and time, when the event ends.
Teaser
The teaser for the event.
Description
The description for the event.
Additional
The additional tab contains additional fields for the event like price, location, organiser, link and
program/schedule.
Field:
Description:
Price
A price for the event.
Tax Rate
The tax rate in percent for the price.
Currency
The currency for the price.
Price options
If the event has multiple prices of which the user must choose of while
registering, you can define one or multiple price options. The following
fields are availabe for price options.
Title
Desciption
Price
Date until the price is valid (selected date is included)
The event management will automatically output the current price if
the
{event.currentPrice} getter is used.
Special getters:
{event.activePriceOptions} - returns all valid price options
{event.priceOptions} - returns all price options. Use {priceOption.isValid} to
decide, if the price option is selectable or not.
If an event has price options defined and registration is enabled, the user
must chose one of the available price options in the registration
process.
A custom RTE text field. The field can e.g. be used to show, that event registration has ended.
Relations
The relations tab contains fields which holds relations locations, organisators and related events.
Field:
Description:
Location
The location of the event choosen from the location records created.
Room
Optional field for the room, where the event happens.
Organisator
The organisator of the event choosen from the organisator records created.
Speaker
One or multiple speaker of the event.
Related events
One or more related events
Media
The media tab contains fields which holds media-data for the event.
Field:
Description:
Image
One or more images. Each image can be configured to be shown either in the listview, the detailview or both.
Files
One or more files.
YouTube embed code
A YouTube embed code
Additional images
One or more additional images (e.g. images from the event).
Categories
You can assign one or multiple categories to an event.
Field:
Description:
Category
One or multiple categories for the event
Registration Options
For each event, it is possible to enable registration and to limit the
amount of free places, so only a limited amount of people can participate to the event. It is also
possible to allow the user to create multiple registrations at once, if the field "Max. simultaneous
registrations per user" is set to a value greater than 1.
Field:
Description:
Enable registration
Option to enable registration for the event. If enabled, users can register for
participation to the event.
Allow registration until end date and time
If set, it is possible to register to an event until the event end date and time is reached.
Note, that this option has no effect, if the registration deadline is earlier than the
event end date and time.
Registration start date
If set, registration is only possible after the given date.
Registration deadline
If set, registration is only possible until the given date.
Enable cancellation
Option to enable cancellation of registrations for the event. If enabled, users can cancel their
registration to the event.
Cancellation deadline
If set, cancellation is only possible until the given date.
Enable automatic confirmation of event registrations
If set, new registrations for the event will automatically be confirmed regardless of the global
setting
settings.registration.autoConfirmation
Max. participants
The amount af max. participants. If the value is zero, there is no limitation.
Max. simultaneous registrations per user
The amount of registrations the participant can create with one single registration. If this
field contains a value greater than 1, a dropdown box can be shown in the registration view
where the user can select how many registrations should be created.
Enable waitlist
Option to enable a waitlist for the event, if the max. amount of registrations is reached.
Enable unique email check for registration
If set, email adresses of registrations are checked for uniqueness for the event.
Enable Payment
If checked, a user registering for an event can select available payment options.
Restrict available payment methods
If checked, the available payment methods for the event can be restricted
Selected payment methods
Selected payment methods, if "Restrict available payment methods" is checked.
Custom payment methods can be added. For documentation, please refer to the
Payment section in the developers manual.
Notify admin
When enabled, the administrator will receive an email for new event registrations (create/confirm)
Notify organisator
When enabled, the organisator will receive an email for new event registrations (create/confirm). The email
sent will use the same template as the admin email.
Registrations
Contains all registrations for the event. Only visible, when registration is enabled.
Field:
Description:
Registrations
A list of participants registered to the event.
Registrations on the waitlist
A list of participants registered to the waitlist of the event. This option is only visible, when the waitlist feature is enabled for the event.
Metadata
Contains fields related to meta tags
Field:
Description:
Keywords
One or multiple keywords used to output the meta tag "keywords"
Description
A description used to output the meta tag "description"
Alternative title
An alternative title which either can be used as meta tag "title" or
which is is used to override the page title.
Categories
You can create categories to structure event records in the frontend (e.g. show events which belong to one
or more categories)
Since the extension uses TYPO3 system categories, you create new categories by choosing "System records" -> "Category"
Locations
Locations can be assigned to an event.
Field:
Description:
Title
Title of the location.
Address
Address of the location
Zip
Zip of the location
City
City of the location
Country
Country of the location
Description
Description (RTE field) of the location.
Link
Link to location or link to a map (e.g. OpenStreetMap)
Latitude
Latitude of the location.
Longitude
Longitude of the location.
Organisator
The organisator can be assigned to an event.
Field:
Description:
Name
Name of the organisator.
E-Mail
E-Mail of the organisator
E-Mail signature
E-Mail signature of the organisator (can e.g. be used in email templates)
Phone
Phone of the organisator
Image
Image of the organisator
Speaker
One or multiple speakers can be assigned to an event.
Field:
Description:
Name
Name of the speaker
Job title
Job title of the speaker
Description
Description of the speaker
Image
Image of the speaker
Registrations
If the registration option is enabled for an event, participants can register to the
event. A registration contains the data the participant entered during the registration
process and also some administration fields like "confirmed" or "paid".
Default fields in the registration form are:
Gender
Title
Firstname
Lastname
Company
Address
Zip
City
Country
Phone
E-Mail
Date of birth
Notes
Accept terms and conditions
Additionally, the following fields are only shown under certain conditions:
Amount of registrations (if Max. simultaneous registrations per user > 1)
Price option (only if event has price options)
Payment method (only if event has enabled payment)
If you need additional field in the registration form, you can add individual
fields on event basis. For more information, see Registration field
General
The general tab contains personal data about the participant, who registered to the event
Field:
Description:
Gender
Gender of the participant
Title
Title of the participant
Firstname
Firstname of participant
Lastname
Lastname of participant
Company
Company of participant
Address
Address of participant
Zip
Zip of the participant
City
City of the participant
Country
Country of the participant
Phone
Phone of the participant
E-mail
E-mail of the participant
Date of birth
Date of birth of the participant
Accepted terms and conditions
Indicates, that the user has confirmed the terms and conditions (if field is used in template)
Notes
Notes from the participant
Registration date
The date the registration was created. This field can be edited in the backend, so you can control which
registration will move up from the waitlist for the default waitlist move up process.
Additional
The additional tab contains additional data about the registration
Field:
Description:
Frontend user
If there was a valid frontend user session at registration time, a relation to the frontend user record
is saved in this field
Confirmation until
Administration field. Date/time until the registration must be confirmed. Hides automatically,
when the registration has been confirmed.
Confirmed
Administration field. Will be set automatically, when the user confirms the registration.
No email notifications
It this field is set to true, the participant will not receive notifications sent by the
backend module.
Amount of registrations
Read-only field which shows the number of registrations the participant has created. Only
shown, if participant has created more than one registration
Parent registration
Read-only field which shows the parent registration. Only shown, if the registration depends
on another registration (multiple registrations created by the same participant)
Registration waitlist
If checked, the registration is on the waitlist
Registration field values
The registration fields tab contains all submitted registration field values.
Field:
Description:
Registration field values
List of registration field values
Payment
The payment tab contains information about payment of the registration
Field:
Description:
Paid
Administration field used to set if the user has paid for the event
Price (when registered)
The price of the registration when the user registered to the event.
This is either the field "price" from the event record or the
price of the selected price option, if the event has price options.
Price Option
The price option the user selected on registration
Payment method
Selected payment method on registration
Payment reference
This field can be used by a payment extension for sf_event_mgt to store a payment reference
Registration field
If the registration option is enabled for an event, you can use registration fields to add additional
fields to the default registration form.
Field:
Description:
Title
Title of the field. Will be rendered as field label in the frontend
Type
Type of the registration field
Possible values:
Textfield (input)
Radiobutton
Checkbox
Textarea
Text
Divider
Date, Datetime or Time
Options
Options for the type "Radiobutton" and "Checkbox".
Example:
Option 1|value1
Option 2|value2
Required
If checked, field must be filled out in frontend
Placeholder
Placeholder for the field
Default value
The default value of the field
Date input mode
Only visible when the selected field type is "Date/Time".
Selects the date input mode: either 'date' (default), 'datetime' or 'time'
Please note: The default template just uses HTML5 input types. You might want to extend that to use a
JavaScript datetimepicker instead.
Prefill with frontend user data
Field will be prefilled with value of selected frontend user data.
Registration field value
If the registration option is enabled for an event and registration fields are configured for an event,
the field values of each registration field are saved as a registration field value
Field:
Description:
Value
The data, the user entered in the registration form for the field
Value datatype
Datatype of the registration field value
Field
Relation to the registration field
Price Option
Price options can be used to define multiple prices of which the user must
choose one during the registration process. The selected price option is
saved to the user registration and the price on registration is saved to
a dedicated field.
If an event has price options defined and registration is enabled, the user
must chose one of the available price options in the registration process.
Price options can be limited to one or multiple frontend user groups and
can be used with the TYPO3 start/stop fields in order to show/hide a
price option on a specific date.
When a registration is saved, the price option and the price option price
is saved to a dedicated field of the registration record.
Field:
Description:
Title
Title of the price option.
Description
Description of the price option.
Price
The price of the price option
Tax Rate
The tax rate in percent for the price.
Date until the price is valid (includes selected date)
A date, until the price option is considered as valid and selectable
in the registration process.
Open the the backend module "Events" from the TYPO3 backend menu and next select
a sysfolder containing your events.
To filter in the list of events, use the 3 search-fields title, startdate and enddate.
Available actions
The backend module contains 5 actions in the upper left.
The first 4 actions creates new items (event, location, organisator, speaker)
The last action does the same as the cronjob, it hides/removes expired registrations
CSV export
With the backend module, you can export a list of participants for events, which are
enabled with the registration option. If the list of fields exported does'nt fit your
needs, you can adjust the fields in the module TypoScript settings as described in the
configuration section of this extension.
Sending custom notification
For events which are enabled with the registration option, you can also send custom
email notification to the participants of the event. Press the "+" icon to get to
the view, where you can select the custom notification template.
If you want to create a custom notification, you just need to add some TypoScript
and a Fluid template for the new custom notification. Please refer to the manual
in the administration section of this extension.
Live Search
You can use the TYPO3 live search to search for specific events by adding "#event:"
as a prefix to your search like shown on the screenshot below
Some general settings can be configured in the Extension Configuration.
Go to Admin Tools > Settings > Extension Configuration
Choose sf_event_mgt
Records
Slug behaviour slugBehaviour
slugBehaviour
slugBehaviour
Type
string, keyword
Default
unique
Choose one of the following slug behaviours:
uniqueInSite
The same slug can be used for news in different sites. Use this
setting only if no event records are shared between sites.
unique
The same news title in different sites will lead to different slug names.
E-Mail
Use FluidEmail for email notifications useFluidEmail
useFluidEmail
useFluidEmail
Type
bool
Default
If active, all notifications generated by the extension will be sent using
FluidEmail.
Note, that the body content of the email is rendered using the internal
FluidRenderingService and then send using the TYPO3 system email layout.
So if you want to change the email content, the templates in
Resources/Private/Notification/ must be overwritten.
Payment
Enable payment method 'invoice' enableInvoice
enableInvoice
enableInvoice
Type
bool
Default
1
Enable payment method 'invoice'
Enable payment method 'transfer' enableTransfer
enableTransfer
enableTransfer
Type
bool
Default
1
Enable payment method 'transfer'
Backend
Hide registrations in event record by limit hideInlineRegistrations
hideInlineRegistrations
hideInlineRegistrations
Type
bool
Default
Enable feature to hide registrations when editing an event in the backend
Hide registrations in event record by limit hideInlineRegistrationsLimit
hideInlineRegistrationsLimit
hideInlineRegistrationsLimit
Type
int
Default
500
Max amount of registrations to display before event registrations will be hidden when editing an event.
List view, Detail view, Registration view, Calendar view, Search view
Since some plugins use the same settings, this section covers the settings
for the following plugins:
List view
Detail view
Registration view
Calendar view
Search view
Nearly all important settings can be made through the plugins, which override the
settings made with TypoScript.
Tab settings
Display Mode
displayMode
displayMode
Type
string
Default
all
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
With this setting, the plugin can be configured to show all events, only future or only past events.
Available options:
all
future
current_future
past
time_restriction
Note
Display mode past will not include events that have no enddate.
Show a Single Event Record
singleEvent
singleEvent
Type
int
Default
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Detail, Registration
The detail view will show the configured event record if no event is passed to the detail or registration
action by parameter. Can be used to display a single event on a page without the need to link to the detail
or registration page from a list view.
Allow preview of hidden event records
previewEvent
previewEvent
Type
int
Default
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Detail
If set, hidden event records are displayed. Be aware to secure the page (e.g. set page visibility to "hidden") as
this page could be called by anyone using any event record uid to see its content.
Note
Note, that this functionality requires a valid backend user session.
Sort By
orderField
orderField
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
Defines which field should be used for sorting events in the frontend.
Sorting Direction
orderDirection
orderDirection
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
Defines the sorting direction for orderField.
Possible values:
(empty value)
asc
desc
Top Event Restriction
topEventRestriction
topEventRestriction
Type
int
Default
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
With this setting, the plugin can be configured to show only top event events, to except top events,
or to ignore the top event restriction.
Available options:
0 (None - ignore top event restriction)
1 (Except top events)
2 (Only top events)
Max Records Displayed
queryLimit
queryLimit
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
The maximum number of records shown.
Category Mode
categoryConjunction
categoryConjunction
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
This setting defines how categories are taken into account when selecting events.
The following options are available:
Ignore category selection
Show events with selected categories (OR)
Show events with selected categories (AND)
Do NOT show events with selected categories (NOTOR)
Do NOT show events with selected categories (NOTAND)
Category
category
category
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
Restrict events to be shown by one or more categories.
Include Subcategory
includeSubcategories
includeSubcategories
Type
int
Default
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
Includes subcategories of the selected category.
Location
location
location
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
Restrict events to be shown by one location.
Organisator
organisator
organisator
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
Restrict events to be shown by one organiser.
Speaker
speaker
speaker
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
Restrict events to be shown by one speaker.
Record Storage Page
storagePage
storagePage
Type
int or list of ints
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar, Registration, Detail
One or more sysfolders where events are stored.
Recursive
recursive
recursive
Type
int
Default
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar, Registration, Detail
Recursion level for record storage page.
Comma Separated List of Field Names, Which Are Required
registration.requiredFields
registration.requiredFields
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
List of field names that are mandatory for registration. The fields
firstname, lastname, and email are always required and cannot be overridden.
The following additional fields are available:
title
company
address
zip
city
country
phone
gender
dateOfBirth
notes
accepttc
Note that all fields are checked if they are empty or not. If the field "accepttc" (or any other
boolean field) is included in the list of required fields, it is checked if the field value is true.
Tab additional
Detail Page
detailPid
detailPid
Type
int
Default
0
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar, Registration, Detail
Page where the plugin is configured to show event details.
List Page
listPid
listPid
Type
int
Default
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar, Registration, Detail
Page where the list view for events is shown. Only available when the plugin is configured to show event details.
Registration Page
registrationPid
registrationPid
Type
int
Default
0
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar, Registration, Detail
Page where the plugin is configured to show event registration.
Payment Page
paymentPid
paymentPid
Type
int
Default
0
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar, Registration, Detail
Page where the plugin is configured to handle payments for registration.
Restrict Foreign Records to Storage Page
restrictForeignRecordsToStoragePage
restrictForeignRecordsToStoragePage
Type
int
Default
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
Categories, locations, and organizers will only be loaded from the configured storage page (recursive).
Disable Override Demand
disableOverrideDemand
disableOverrideDemand
Type
int
Default
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
If set, the settings of the plugin can't be overridden by arguments in the URL.
Tab template
Template Layout
templateLayout
templateLayout
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar, Registration, Detail
With this setting, the plugin can be configured to show different template layouts.
Template layouts can be configured with Page TSConfig.
Template layout can be used/set by TypoScript (settings.templateLayout)
Tab notification
Notification Configuration
notification.senderEmail
notification.senderEmail
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
Email address of emails sent to the user. This should be the email address of the site admin or a general information
email address. The user will see this email address as sender.
notification.senderName
notification.senderName
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
Name of the sender.
notification.replyToEmail
notification.replyToEmail
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
Reply-to email address of emails sent to the user.
Default: empty
notification.adminEmail
notification.adminEmail
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
E-Mail address(es) of website admin(s) who receive new/confirmed registrations.
Multiple E-Mail addresses must be separated with a comma.
notification.registrationNew.userSubject
notification.registrationNew.userSubject
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
Subject of email sent to the user when a new registration is created.
notification.registrationWaitlistNew.userSubject
notification.registrationWaitlistNew.userSubject
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
Subject of email sent to the user when a new registration on the waitlist is created.
notification.registrationNew.adminSubject
notification.registrationNew.adminSubject
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
Subject of email sent to the admin when a new registration is created.
notification.registrationWaitlistNew.adminSubject
notification.registrationWaitlistNew.adminSubject
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
Subject of email sent to the admin when a new registration on the waitlist is created.
notification.registrationConfirmed.userSubject
notification.registrationConfirmed.userSubject
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
Subject of email sent to the user when a registration has been confirmed.
Subject of email sent to the admin when a registration on the waitlist has been confirmed.
notification.registrationCancelled.userSubject
notification.registrationCancelled.userSubject
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
Subject of email sent to the user when a registration has been cancelled.
notification.registrationCancelled.adminSubject
notification.registrationCancelled.adminSubject
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
Registration
Subject of email sent to the admin when a registration has been cancelled.
Tab category menu
Categories Configuration
categoryMenu.categories
categoryMenu.categories
Type
list of strings
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
A subset of categories that will be shown in the category menu. If empty, all categories will be shown.
categoryMenu.includeSubcategories
categoryMenu.includeSubcategories
Type
int
Default
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
Includes subcategories of selected categories in the category menu.
categoryMenu.orderField
categoryMenu.orderField
Type
string
Default
title
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
Order field for the category menu (internally limited to "title", "uid", and "sorting").
categoryMenu.orderDirection
categoryMenu.orderDirection
Type
string
Default
asc
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Plugin
List, Search, Calendar
Order direction for the category menu.
Frontend user registrations
The plugin is both used to output a list- and a detail view.
Nearly all important settings can be made through the plugin, which override the
settings made with TypoScript. All plugin settings can also be configured with TypoScript
(use
plugin.tx_sfeventmgt.settings. with the keys shown below).
Important
Make sure,that you place the Plugin on a page with "Usergroup Access Rights" configured to only show
the plugin output for logged in users and/or users belonging to a user group. Anyway, the plugin will only output
content if there is an active frontend user session.
Tab settings
Display mode
userRegistration.displayMode
userRegistration.displayMode
Type
string
Default
all
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
With this setting, the plugin can be configured to show registrations for all events, only
future or only past events.
Available options:
all
future
current_future
past
time_restriction
Sort by
userRegistration.orderField
userRegistration.orderField
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Defines which field should be used for sorting events in the frontend.
Possible values:
event.title
event.startdate
event.enddate
Sorting direction
userRegistration.orderDirection
userRegistration.orderDirection
Type
string
Default
(none)
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Defines the sorting direction for orderField.
Possible values:
(none)
asc
desc
Registration pid
registrationPid
registrationPid
Type
int
Default
0
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Page where the event plugin is configured to show event registration.
Record storage page
userRegistration.storagePage
userRegistration.storagePage
Type
int or list of ints
Default
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
One or more sysfolders where events and registrations are stored.
Recursive
userRegistration.recursive
userRegistration.recursive
Type
int
Default
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Recursion level for record storage page.
Tab additional
Detail Page
detailPid
detailPid
Type
int
Default
0
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Page where the plugin is configured to show event details.
Registration Page
registrationPid
registrationPid
Type
int
Default
0
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Page where the plugin is configured to show event registration.
Payment Page
paymentPid
paymentPid
Type
int
Default
0
Path
plugin.tx_sfeventmgt.settings
Scope
Plugin, TypoScript Setup
Page where the plugin is configured to handle payments for registration.
Payment
The Plugin Events and event-registration - Payment plugin should
be placed on a separate TYPO3 page. You must reference the Events and event-registration
plugin settings to the TYPO3 page UID if you want to use the payment plugin.
If set, the calendar will show events for all days of all shown weeks of the calendar and not only
events for the current month.
settings.calendar.showWeekNumber
settings.calendar.showWeekNumber
settings.calendar.showWeekNumber
Type
int
Default
1
Defines if the calendar should show week numbers or not.
settings.detail.checkPidOfEventRecord
settings.detail.checkPidOfEventRecord
settings.detail.checkPidOfEventRecord
Type
int
Default
If set, the detail view checks the incoming event record against the defined starting point(s).
If those don’t match, the event record won’t be displayed.
settings.detail.imageWidth
settings.detail.imageWidth
settings.detail.imageWidth
Type
int
Default
200
Default width of images in detail view
settings.detail.imageHeight
settings.detail.imageHeight
settings.detail.imageHeight
Type
int
Default
(none)
Default height of images in detail view
settings.detail.isShortcut
settings.detail.isShortcut
settings.detail.isShortcut
Type
int
Default
This setting should be set to "1" if the event should be fetched from the Content Object data.
This option should only be set to "1", if events are displayed using the "Insert Record" content element
settings.registration.checkPidOfEventRecord
settings.registration.checkPidOfEventRecord
settings.registration.checkPidOfEventRecord
Type
int
Default
If set, the registration view checks the incoming event record against the defined starting point(s).
If those don’t match, the registration to the event is not possible.
settings.registration.autoConfirmation
settings.registration.autoConfirmation
settings.registration.autoConfirmation
Type
int
Default
If set to 1, new registration will automatically be confirmed by redirecting
the user to the confirmRegistration-Action.
settings.registration.deleteExpiredRegistrations
settings.registration.deleteExpiredRegistrations
settings.registration.deleteExpiredRegistrations
Type
int
Default
If set to 1, expired registrations will be deleted by the action in the backend module. If this
setting is set to false, expired registrations will just be set to hidden
Note, this setting has no effect for the cleanup CLI command.
settings.registration.formatDateOfBirth
settings.registration.formatDateOfBirth
settings.registration.formatDateOfBirth
Type
string
Default
d.m.Y
Date format of field dateOfBirth
settings.registration.requiredFields
settings.registration.requiredFields
settings.registration.requiredFields
Type
string
Default
empty
List of required fields in registration. The fields firstname, lastname and email
are always required and cannot be overridden.
The following additional fields are available:
title
company
address
zip
city
country
phone
gender
dateOfBirth
notes
accepttc
captcha
Note, that all fields are just checked, if they are empty or not. If the field "accepttc" (or any other
boolean field) is included in the list of required fields, it is checked if the field value is true.
settings.registration.linkTermsAndConditions
settings.registration.linkTermsAndConditions
settings.registration.linkTermsAndConditions
Type
string
Default
empty
A page or an external URL that can be used in the registration template to show "Terms & Conditions"
settings.registration.prefillFields.{fieldname}
settings.registration.prefillFields.{fieldname}
settings.registration.prefillFields.{fieldname}
Type
string
Key/value mapping for prefilling fields from fe_users table. The
key-field is the fieldname in sf_event_mgt and the value-field is
the fieldname in fe_users.
Default
firstname = first_name
lastname = last_name
address = address
zip = zip
city = city
country = country
email = email
phone = telephone
settings.registration.rateLimit.enabled
settings.registration.rateLimit.enabled
settings.registration.rateLimit.enabled
Type
int
Default
If set to 1, the registration form will have a reate limit enabled.
settings.registration.rateLimit.limit
settings.registration.rateLimit.limit
settings.registration.rateLimit.limit
Type
int
Default
5
Amount of successful registrations allowed in the configured timeframe, before new successful registration
attempts are rate limited.
settings.registration.rateLimit.interval
settings.registration.rateLimit.interval
settings.registration.rateLimit.interval
Type
string
Default
15 minutes
Defines the interval for which the configured limit applies.
settings.registration.rateLimit.handling
settings.registration.rateLimit.handling
settings.registration.rateLimit.handling
Type
string
Default
flashMessage
Defines how to handle a possible rate limit. Valid values are:
flashMessage: Add a flash message to the message queue and forwards back to previous action.
httpResponse429: Returns a 429 HTTP response with a message.
The message is defined in rateLimiter.exceeded localization key.
Note: If you use the setting flashMessage, you must output <f:flashMessages /> in your registration template.
If set to 1, a registration will keep the dependency to the main registration if the registration
has been submitted using the simultaneous registration process. Note, that it is recommended to set this
value to false (0), since cancellation of the main registration will also cancel moved up "child"
registrations.
settings.confirmation.linkValidity
settings.confirmation.linkValidity
settings.confirmation.linkValidity
Type
int
Default
3600
Validity of confirmation link in seconds
settings.confirmation.additionalVerificationStep
settings.confirmation.additionalVerificationStep
settings.confirmation.additionalVerificationStep
Type
bool
Default
false
Defines, if the confirmation of a registration requires an additional manual verification step by the user.
If active, confirmation links in emails will refer to a page, where the user has to confirm the registration
by clicking a link.
Note
Please ensure, that the
action argument for the
f:link.action ViewHelper in your notification
templates equal to
{cancelAction}
settings.cancellation.additionalVerificationStep
settings.cancellation.additionalVerificationStep
settings.cancellation.additionalVerificationStep
Type
bool
Default
false
Defines, if the cancellation of a registration requires an additional manual verification step by the user.
If active, cancellation links in emails will refer to a page, where the user has to confirm the cancellation
by clicking a link.
Note
Please ensure, that the
action argument for the
f:link.action ViewHelper in your notification
templates equal to
{cancelAction}
Fields to be included in a query for the search view
settings.search.adjustTime
settings.search.adjustTime
settings.search.adjustTime
Type
int
Default
true
When the setting settings.search.dateFormat is set to a date only, it is recommended to set this option
to true. The time for a given startdate will be set to 00:00:00 and the time for a given enddate will be set
to 23:59:59, so all events for the given dates will be found by a search.
settings.pagination.enablePagination
settings.pagination.enablePagination
settings.pagination.enablePagination
Type
int
Default
false
If true, the list view outputs required variables to render a pagination.
settings.pagination.itemsPerPage
settings.pagination.itemsPerPage
settings.pagination.itemsPerPage
Type
int
Default
10
Amount of items per paginated page.
settings.pagination.maxNumPages
settings.pagination.maxNumPages
settings.pagination.maxNumPages
Type
int
Default
10
Maximum number of pages to show in the pagination.
If an event for the detail and registration view is not found (e.g. is hidden or deleted), you can configure,
if the plugin should redirect to the list view, show a 404 error or render the view (default) without the
event data.
Possible values:
redirectToListView
pageNotFoundHandler
showStandaloneTemplate
The "showStandaloneTemplate" option requires a Template and optional an HTTP status code.
Note: For TYPO3 9.5, this setting has only effect when the event is not passed through GET parameters to the
action (e.g. event set in plugin). For all other scenarios, the TYPO3 "sites" error handling steps in.
Comma-separated list of fields to include in CSV export. Please note, that you must write the property
names of the fields to export (e.g. firstname, lastname, dateOfBirth, event.title)
In order to export the values of registration fields, use "registration_fields" as fieldname. Note, that
it is only possible to export all registration fields at once.
If switched on, a warning message is shown in the backend module, when a backend user does not have
read/write access rights to the temp-folder of the default storage.
settings.csvExport.fieldDelimiter
settings.csvExport.fieldDelimiter
settings.csvExport.fieldDelimiter
Type
string
Default
,
Comma-separated list delimiter
settings.csvExport.fieldQuoteCharacter
settings.csvExport.fieldQuoteCharacter
settings.csvExport.fieldQuoteCharacter
Type
string
Default
"
Comma-separated list quote character
settings.csvExport.prependBOM
settings.csvExport.prependBOM
settings.csvExport.prependBOM
Type
int
Default
Prepend UTF-8 BOM to export. Switch this setting on if you have problems when opening the exported CSV file
with Microsoft Excel
settings.list.itemsPerPage
settings.list.itemsPerPage
settings.list.itemsPerPage
Type
int
Default
10
Number of items to show per page in the backend module
settings.search.dateFormat
settings.search.dateFormat
settings.search.dateFormat
Type
string
Default
d.m.Y H:i
Date format for search fields in the backend module
settings.search.fields
settings.search.fields
settings.search.fields
Type
string
Default
title, teaser
Fields to be included in a query from the backend module
This setting allows setting the default storage pid of new events generated over the backend module.
To set the default storage pid for new event records, for example, to a sysfolder with the pid 20, use:
The following example shows a basic configuration for routes of sf_event_mgt.
Note
The examples shown are for version 6.x of the extension, where several new plugins
have been introduced. For an example routing configuration that covers version 4.x and 5.x
of the extension, please switch to the version of the documentation to the left.
Note, that some requirements are too loose (e.g. eventuid, reguid) and can not be simplified, so therefore
a cHash parameter will be added to the route automatically.
The extension also extends sys_category with a slug field the same way as ext:news does. Please note, that
the
overwriteDemand/category argument is a string, which can contain multiple category UIDs. When you
use the overwriteDemand for categories with only one category, the example configuration above will work.
If you pass multiple, comma separated category UIDs to the
overwriteDemand/category argument, you have to
implement you own routing aspect.
Changing paths of the template for frontend plugins
Please do never change templates directly in the Ressources folder of the extensions,
since your changes will get overwritten by extension updates.
The easiest way to override templates is to set the following constants:
plugin.tx_sfeventmgt.view.templateRootPath
plugin.tx_sfeventmgt.view.partialRootPath
plugin.tx_sfeventmgt.view.layoutRootPath
Those values will automatically be added after the default paths configuration of the extension. If you prefer
to configure the path-values using TypoScript setup, please refer to the example below
(note the plural of the path-name):
Doing so, you can just override single files from the original templates.
Changing paths of the template for backend module
Since TYPO3 12.4 the override functionality for backend templates has been
reworked. Instead of invoking TypoScript to retrieve template paths, it is
now required to use TSConfig:
DateTime object with the first day of the current month
{previousMonthConfig}
Array with date, month and year of the previous month
{nextMonthConfig}
Array with date, month and year of the next month
{weekConfig}
Array holding the year and weeknumber for the current, previous and next week.
This variable must be used to create a calendar view by week.
{contentObjectData}
The current content object of the plugin
{pageData}
The current page data
Search view
Object:
Description:
{events}
An object holding all events that matched the configured demand in the plugin settings and the given searchdemand
{categories}
All available categories
{locations}
All available locations
{organisators}
All available organisators
{speakers}
All available speakers
{searchDemand}
The searchDemand object
{overwriteDemand}
The overwriteDemand object
{contentObjectData}
The current content object data
{pageData}
The current page data
Notification views
The following objects can be used in notification views
Object:
Description:
{event}
An object holding the given event
{registration}
An object holding the given registration
{settings}
An array of extension settings
{hmac}
HMAC for the registration UID
{reghmac}
Appended HMAC for the registration UID
E-Mail subjects
The following objects can be used in email subjects for event registration and custom notifications
Object:
Description:
{event}
An object holding the event for a registration
{registration}
An object holding the registration
Registration message views
Registration message views are
cancelRegistration,
confirmRegistration and
saveRegistrationResult
Object:
Description:
{event}
An object holding the given event
{registration}
An object holding the given registration
{failed}
If the status is failed
{titleKey}
The key of the title to use in <f:translate> viewHelper
{messageKey}
The key of the message to use in <f:translate> viewHelper
{result}
The integer value of the {messageKey} variable
iCalendar view
The iCalendar view is used to render an iCal file which can be downloaded by the user for the given event.
Please note, that the iCalendar view is a simple textfile. If you choose to extend the view, be sure that
new fields are compliant with RFC 5545 https://tools.ietf.org/html/rfc5545
Object:
Description:
{event}
An object holding the given event
Plugin: Events and event-registration - FE user registrations
List view
Object:
Description:
{registrations}
An object holding all registrations that matched the configured demand in the plugin settings
Special Getters
Some domain objects contain special getters which are used in templates to avoid complex fluid conditions.
Event
The Event-Object has the following special getters
Getter:
Description:
{event.registrationPossible}
Returns, if registration for the event is possible. This getter respects if registration is enabled,
if max. participants is configured/reached, if registration deadline is configured/reached and if
registration deadline / event startdate is reached.
{event.freePlaces}
Returns the amount of free places for an event
{event.activePriceOptions}
Returns all active price options sorted by date ASC
{event.currentPrice}
Returns the current price of the event respecting possible price options
{event.cancellationPossible}
Returns, if cancellation for registrations of the event is possible
{event.registrationFieldsUids}
Returns an array with registration field uids
{event.registrations}
Special getter to return the amount of registrations that are saved to default language
{event.registrationsWaitlist}
Special getter to return the amount of waitlist registrations that are saved to default language
{event.endsSameDay}
Returns if the event ends on the same day
{event.images}
Returns the same ans
{event.image}
{event.listViewImages}
Returns all images from
{event.image} that are configured to be shown in list view
{event.firstListViewImage}
Returns the first image from
{event.image} which is configured to be shown in list view
{event.detailViewImages}
Returns all images from
{event.image} that are configured to be shown in detail view
{event.firstDetailViewImage}
Returns the first image from
{event.image} which is configured to be shown in detail view
Viewhelpers
The following viewhelpers can be used in you templates.
PrefillViewHelper
This viewhelper prefills fields in the registration form with values from fe_users.
This viewhelper does generates a link to the given page with the given
arguments.
This viewhelper can be used in email templates for custom notifications, when you want to link to a
given page in you TYPO3 website.
Note
This ViewHelper is not aware of any extbase context, so arguments must be
fully resolved (e.g. use
{event.uid} if an action required the
event argument)
This viewhelper renders an array of possible simultaneous registration for
the given event. The viewhelper respects the max. amount of simultaneous
registrations per user and also respects the amount of remaining participants
for the event.
The index of the array returned starts with 1, so the resulting array can be used
directly in the f:form.select viewhelper.
Formats the given DateTime object according to rfc5545, so it can be used in the iCalendar view
Format.ICalendarDescriptionViewHelper
Formats the given string according to rfc5545, so it can be used in the iCalendar view
Registration.Hmac
Must be used, when the plugin Frontend user registrations is used and it should be possible
for users to cancel registrations (if configured in event). See usage in UserRegistration templates.
Registration.IsRequiredField
Can be used to show content, if a field or registration field is configured as required.
See usage in Registration template and registration field partials.
Can be used to show a string, when a given field or registration field has validation errors
See usage in Registration template and registration field partials.
Use this viewhelper to set the page title and indexed search title on event-detail and -registration pages.
Example:
<e:title pageTitle="{event.title}" indexedDocTitle="A custom title for indexed search"/>
Copied!
Category.Count
Can be used to get the amount of events per category.
Example:
<e:category.count categoryUid="{category.uid}" />
Copied!
MetaTag
Use this viewhelper to add various meta tags related to the event. The default template for the event
detail view uses this viewhelper to output the meta tags "keyword", "description" and "og:title".
In the List view, Detail view, Registration view, Calendar view, Search view you can define criterias for the listview, so it e.g. only
shows the events of a special category or for a special location. Nearly all settings
affecting the demand of the shown events can be overwritten by a URL parameter called
overwriteDemand.
Below follows some examples for the overwriteDemand setting:
Filter by category
The following code snippet shows a list of links which restrict the category to be shown
to the given category:
As all links are generated using the
f:link.action viewHelper, they are fully cached.
Filter by special location properties
It is possible to filter events by the location city and country. Using the overwriteDemand
parameter is as following:
<f:link.action action="list" controller="Event" arguments="{overwriteDemand:{locationCity: 'Hamburg'}}">Show all events in Hamburg</f:link.action>
<f:link.action action="list" controller="Event" arguments="{overwriteDemand:{locationCountry: 'Germany'}}">Show all events in Germany</f:link.action>
Copied!
Filter by year, month and/or day
It is possible to filter events by a specific year, month or day. Using the overwriteDemand
parameter is as following:
<f:link.action action="list" controller="Event" arguments="{overwriteDemand:{year: '2017'}}">All events in 2017</f:link.action>
<f:link.action action="list" controller="Event" arguments="{overwriteDemand:{year: '2017', month: '10'}}">All events in october of the year 2017</f:link.action>
<f:link.action action="list" controller="Event" arguments="{overwriteDemand:{year: '2017', month: '10', day: '1'}}">All events on the 1st of october 2017</f:link.action>
Copied!
The filtering also respects events, which are in between the given filter criteria. If you for example set
the filter option to filter events for the 2st of october 2017, then also an event will be shown, that start
at the 1st of october and ends at the 3rd of october.
CLI Commands
Cleanup expired registrations
Only needed if you use registrations for events
If a new participant registers to an event, the participant must confirm the registration in a
given timeframe (default 1 hour from registration time). If the participant does not confirms
the registration in the given timeframe, the booked place for the event should be made available
again for other participants.
In order to remove/hide expired registrations, a CLI command is available to remove/hide expired registrations.
It is recommended to setup a scheduler task to execute the CLI command periodically.
GDPR cleanup for registrations
Local data privacy policies may require, that you only save personal user data
when needed. In order to remove personal user data of registrations including
saved registration field data for expired events, a CLI command is available.
Arguments
days - Amount of days reduced from todays date for expired event selection.
Options
softDelete - If set, registration will not be deleted hard, but only flagged as deleted
ignoreEventRestriction - If set, simply all available registrations will be selected and deleted. Use with care!
It is recommended to setup a scheduler task to execute the CLI command periodically.
Note
The GDPR cleanup only includes events, which have a start- and enddate. Events with no enddate are
not covered by the cleanup, since it is not possible to calculate, when the event has ended.
Custom notifications
If you use the registration option for events, you have to possibility to send
custom notifications to participants of the event. In order to do so, use the
admin module to open the "Notify participants" view.
Create an own notification
To create an own notification, you first need to create a HTML template that will
be used as the notification body. The template must be located in the following
path:
Templates/Notification/User/Custom/
Copied!
In this example, I create the file MyNotification.html
You can use the following objects in your template:
{registration}
{event}
{settings}
{hmac}
{reghmac}
{customNotification}
After you created the notification template, you have to configure the new notification
in the TypoScript settings of the admin module.:
module.tx_sfeventmgt {
settings {
notification {
customNotifications {
myNotification {
title = A title for the notification
template = MyNotification.html
subject = A subject for the email
}
}
}
}
}
Copied!
After configuring the new notification to the TypoScript settings, you can use it to
notifiy participants of the event.
Selecting the recipients of custom notifications
If you want to send a custom notification only to a selected group of recipients (e.g. those who
actually have paid for the event), you can use the "constraints" setting to limit the recipients.:
module.tx_sfeventmgt {
settings {
notification {
customNotifications {
myNotification {
title = A title for the notification
template = MyNotification.html
subject = A subject for the email
constraints {
paid.equals = 1
}
}
}
}
}
}
Copied!
Using the example above, only those participants will receive an email where the field "paid" equals with "1".
You can use the following conditions
equals
lessThan
lessThanOrEqual
greaterThan
greaterThanOrEqual
You may also combine the conditions like shown below:
module.tx_sfeventmgt {
settings {
notification {
customNotifications {
myNotification {
title = A title for the notification
template = MyNotification.html
subject = A subject for the email
constraints {
paid.equals = 1
confirmed.equals = 1
}
}
}
}
}
}
Copied!
Note, that combined conditions are always combined with a logical AND statement, so custom
notifications with the example settings from above will be sent to all participants, who have
paid and confirmed to the event.
Also note, that the usage of conditions like shown above are rudimentary and does not cover all
scenarios.
How to create links to actions for notifications sent using the backend module
The native
f:uri.action ViewHelper will create links in backend context when used for notifications in the
backend module. In order to create links in frontend context, the extension comes with an a custom ViewHelper,
which creates links for frontend context. See
Uri.PageViewhelper in Viewhelpers
E-Mail attachments
If the registration option is enabled for an event, participants can register to the
event. The extension allows you to send emails to the participant in order to notify
him, that he has registered or confirmed his registration.
The extension supports to add attachments to the following type of emails:
New event registration
New event registration on the waitlist
Confirmed event registration
Confirmed event registration on the waitlist
Custom notifications sent from backend (only recipient group
user)
Configuring email attachments
Attachments must be configured in TypoScript and it is possible to add attachments globally to all emails of a
specific type or individual per event. Due to readability, the default TypoScript setup does not include an
example configuration for email attachments.
Possible attachment configurations
Attachment configuration can be added to the following TypoScript settings:
The example above configures the attachments for emails to the user (the participant) when a new registration is
created.
The
fromFiles setting configures the file
fileadmin/terms-and-conditions.pdf to be added to the email. If the
file does not exist, it will not be added.
The
fromEventProperty setting configures to add all files from the event properties
files and
image. Those
properties are of the type
\TYPO3\CMS\Extbase\Persistence\ObjectStorage and may contain fileReferences. It is also
possible to use properties of the type
\TYPO3\CMS\Extbase\Domain\Model\FileReference
The configuration ot the
fromRegistrationProperty setting is similar to the
fromEventProperty setting. In the
example above, the property
registrationFiles will be used. Note, that the registration model of the extension does
not contain any default fields that can be used as attachments, so you have to add your own if you need them.
iCal attachment
Configuration of an iCal attachment is similar to the configuration of attachments (see above). The only difference is,
that the iCal attachment is only supported for the recipient group
user
Properties for attachment configuration
Property:
Data type:
Description:
Default:
iCalFile
boolean
If set, a iCal file for the event will be attached to the user email
In the example above, emails for new user registrations will include an iCal file for the event.
Email attachments using PSR-14 Events
If the TypoScript configuration settings for email attachments do not fulfill your requirements, you can
use the
ModifyUserMessageAttachmentsEvent Event to add custom attachments using PHP (see PSR-14 Events)
RSS feed
This section describes how you add a RSS feed for the list of events. The implementation of the RSS feed in
sf_event_mgt is similar to the RSS feed implementation in the news extension from Georg Ringer. Many parts
of the RSS feed documentation are taken from his extension with small modifications to fit sf_event_mgt.
The template for the RSS feed can be found in the file
Resources/Private/Templates/Event/List.xml
To configure sf_event_mgt to use this template, simply set the format of the output als shown below:
plugin.tx_sfeventmgt.settings.list.format = xml
Copied!
RSS feed by TypoScript (recommended)
One way to generate the RSS feed is to use TypoScript. Add to following TypoScript to your site and adopt it to your
needs:
This example will show all events which are saved on the page with uid 3. The detail view page is the one with uid 4.
The RSS feed itself can be found with the link /?type=9918.
RSS feeds by using a plugin
If you want to use the sf_event_mgt plugin to configure the settings of your RSS feed, then just configure the
event plugin as if you are creating a list view (set startin point, categories, detail page, ...)
Next, add a new TypoScript template to the page and insert the following TypoScript to the setup section
Important
If the sf_event_mgt plugin is located in different column than default (0), you
need to extend the TypoScript as following:
page.10.select.where = colPos=1
Copied!
Note
When using Fluid Styled Content, you have to make sure, that you override layouts and templates of
Fluid Styled Content in order to remove the wrapper-div and also to ensure the RSS feed contains
no empty lines. To keep things simple, it is recommended to configure the RSS feed using TypoScript
RSS feed configuration
Don't forget to configure the RSS feed properly as the sample template won't fulfill your needs completely.
Please look up the constants and change the mentioned settings.
plugin.tx_sfeventmgt {
rss.channel {
title = Feed title
description =
link = http://domain.tld/
language = en-gb
copyright = TYPO3 Event management and registration
category =
generator = TYPO3 EXT:sf_event_mgt
}
}
Copied!
Add a link to the RSS feed in the list view
To be able to render a link in the header section of the normal page which points to the RSS feed you can use
something like this in your List.html fluid template.
The registration form of the extension may be target of spam bots, which submit the form with various data.
Besides the fact, that this may require manual work to delete all spam submissions from the database, it may
even be a bigger problem for events with a fixed amount of free places, when spam bots registrations block
valid user registrations.
The extension offers possibilities to reduce the amount of spam in the registration form to a minumum:
It is possible to configure spam checks which are executed on form submission. A configurable max spam score is used
to determine, if a form submission is considered as spam or not. Each spam check can increase the total spam score
by a configurable amount.
Configuration
The configuration is (hopefully) self explaining.
The spam check can be enabled or disabled using Typoscript.:
To enable the spam check,
plugin.tx_sfeventmgt.settings.registration.spamCheck.enabled = 1 must be set.
Next, each spam check must be activated and configured to your needs.
The honeypot spam check
This check adds a field (either invisible input field or a hidden form field) to the registration form.
If the field is filled out, it is very likely that the form submission is spam. Therefore you should configure
a high
increaseScore, so the spam check as a whole already is considered as failed when this check fails.
If this spam check is configured and the field is not submitted (missing in POST parameters), the check is also
considered as failed.
The link spam check
This check counts the amount of links in all submitted form fields. If the configured
maxAmountOfLinks is
exceeded, the check is considered failed.
The challenge/response spam check
This check adds a hidden input field to the registration form. The check expect a specific value to be submitted
in the hidden input field. If this value is not present, the check is considered failed.
The spam check has the following configuration options:
challengeResponse {
enabled = 0
name = Challenge/Response check (JavaScript required) using ROT13 encryption/obfuscation
class = DERHANSEN\SfEventMgt\SpamChecks\ChallengeResponseSpamCheck
increaseScore = 10
configuration {
prefix = SfEventMgt
postfix = TYPO3
}
}
Copied!
The spam check calculates a challenge consisting of the configured pre- and postfix and a hmac which includes the
uid of the event. This challenge is added as data-attribute to the hidden form field.
The check expects the challenge to be returned ROT13 encrypted/encoded. There is a plain vanilla JavaScript script in
Resources/Public/JavaScript/cr-spamcheck.js that does the job for you, if you use the included partial for
the spam checks of the extension. The required JavaScript file is automatically included, when the challengeResponse
check is activated.
Creating a custom spam check
It is also possible to create custom spam checks. To do so, just add an own configuration array to the
checks array and implement your check as a class that extends
\DERHANSEN\SfEventMgt\SpamChecks\AbstractSpamCheck
Please refer to the existing spam checks in the extension for details.
You should evaluate, which captcha service suits best for your needs, since the reCAPTCHA
service may not be inline with local laws (e.g. privacy concerns due to GDPR)
Configuration
Both hCaptcha and Google reCAPTCHA require API credentials, so the captcha can be check against an API.
The API credentials must be added as TypoScript constants (see example below).
Note, that you must replace
<event-record-pid> and
<detail-pid> with your own values.
Tip
When you only want to show future events, you can extend the config by
additionalWhere = tx_sfeventmgt_domain_model_event.enddate > UNIX_TIMESTAMP()
Language menu on event detail pages
If a language menu is rendered on a detail page and the languages are configured to use a strict mode, the following snippet
helps you to setup a proper menu. If no translation exists, the property available is set to false - just as if the current
page is not translated.
10 = TYPO3\CMS\Frontend\DataProcessing\LanguageMenuProcessor
10 {
as = languageMenu
addQueryString = 1
}
11 = DERHANSEN\SfEventMgt\DataProcessing\DisableLanguageMenuProcessor
# comma separated list of language menu names11.menus = languageMenu
Copied!
Default waitlist move up process
The extension contains a built in waitlist feature to allow your users to register on a waitlist for events, where
all places are taken. It is possible to automatically move up user from the waitlist either by the built in logic
in the extension or by implementing a custom logic using the PSR-14 event
WaitlistMoveUpEvent
Note
The default waitlist move up process is designed to meet the most common and simple requirements to a
waitlist move up process. If the move up process does not fulfill your needs, you have to implement an
own process.
Additionally note, that the default waitlist move up process works in frontend context only.
How does the waitlist move up process work?
The default automatic move up process is active, when the following conditions are met for the event:
"Enable cancellation" is activated
"Enable waitlist" is activated
"Automatic waitlist move up" is activated
As soon as the event is fully booked, new registration will be added to the waitlist of the event.
When a registered user cancels the registration, registrations will move up from the waitlist.
Note, that the following conditions decide, if a registration will move up:
The registration must be confirmed
The registration must have a valid date in the field "Registration date"
The registration with the earliest "Registration date" will move up first
As soon as a registration moved up from the waitlist, the user will recieve an email, that the registration moved up.
Things to keep in mind when using the default move up process
The default move up process does not execute, when registrations are removed from the event because the confirmation deadline exceeded
When the simultaneous registration process is used, registrations are treated separately by the default move up process.
This can result in, that the main registration will be moved up, but additional may not.
When the simultaneous registration process is used, the dependency to the main registration will automatically be
removed. This is recommended, since the cancellation of the main registration will result in the cancellation
of all "connected" registrations. The TypoScript setting
settings.waitlist.moveUp.keepMainRegistrationDependency
can be used to keep the dependency to the main registration.
When the simultaneous registration process is used, moved up registrations will automatically be enabled for
notification.
If a payment process is activated for the event, the
AfterRegistrationMovedFromWaitlist event must manuelly be implemented
in order to send an email with payment information (e.g. payment link) to the user who moved up.
Customizing the move up process
If the default move up process does not fulfill your needs, you can use the PSR-14 event
WaitlistMoveUpEvent
to create a custom move up logic. Please refer to the code of the default move up process to see how a custom
logic can be implemented.
If you implement a custom move up logic and to not want the default move up process to be executed, make sure
so set
$processDefaultMoveUp to
false in your event listener.
LinkHandler
LinkHandler is the synonym for making it possible for editors to create links to custom records.
Tip
This tutorial is also valid for creating links to any other record.
Configuration for the backend
PageTsConfig is used to configure the link browser in the backend.
TCEMAIN.linkHandler {
tx_event {
handler = TYPO3\CMS\Recordlist\LinkHandler\RecordLinkHandler
label = Events
configuration {
table = tx_sfeventmgt_domain_model_event
# Default storage pid
storagePid = 26
# Hide the page tree by setting it to 1
hidePageTree = 0
}
scanAfter = page
}
}
Copied!
Configuration for the frontend
The links are now stored in the database with the syntax <a href="t3://record?identifier=tx_event&uid=123">A link</a>.
By using TypoScript, the link is transformed into an actual link.
The extensions contains many PSR-14 events which make it possible to extend the extension with own functionality.
You can for example add own variables to all views or extend email notifications by own needs.
Please note, that there is no documentation for each PSR-14 event in detail, so you have to check each event
individually for supported properties. Generally I tried to make the events as self explaining as possible.
If you are new to PSR-14 events, please refer to the official TYPO3 documentation about
PSR-14 events and Event Listeners.
The extension supports custom payment methods, which can be added by creating an own extension that adds a new
payment method and implement Event Listeners for the PSR-14 Events for the different payment actions. It is
required, that the payment is processed by an external payment provider (e.g. Paypal payment page).
Please refer to the General workflow image shown below.
It is also required, that each Event Listener uses a Fluid standalone view to render the output that will be
shown in the desired payment action in sf_event_mgt
Note
Please note, that it is only possible to start the payment process after the registration has been
confirmed by the user.
This section describes how to create your own payment solution for sf_event_mgt which makes use of the provided
payment actions.
I will assume, that the new payment method is called
mypaymentmethod and the extension key for the new
payment method is
sf_event_mgt_mypaymentmethod
General workflow
Depending on the selected payment method, the user is redirected to the payment providers payment page.
Depending on the requirements of the payment method, you should implement an Event Listener for available PSR-14 Events.
You should at least implement handling of redirect, success, failure and cancel actions.
The code below shows how to implement your payment method to the redirectAction PSR-14 Event of sf_event_mgt:
After you registered your event listener, you can add code for your Event Listener to initialize the payment:
<?php
namespace Vendor\Extension\EventListener;
use DERHANSEN\SfEventMgt\Event\ModifyDetailViewVariablesEvent;
class YourListener
{
public function __invoke(ModifyDetailViewVariablesEvent $modifyDetailViewVariablesEvent): void {
// Implement your code (e.g. add variables)
$variables = $modifyDetailViewVariablesEvent->getVariables();
$variables['newVariable'] = 'Just testing';
$modifyDetailViewVariablesEvent->setVariables($variables);
}
}
Copied!
The setters in all events allow you to control the behavior of the payment process in the main extension.
4. Add payment class
Please refer to the class
AbstractPayment in sf_event_mgt for possible settings. You payment class
must extend
AbstractPayment and you should override/set the local
$enable properties in order
to enable the actions in sf_event_mgt
Please also refer to the
PaymentController in sf_event_mgt to see all available PSR-14 Events.
In this example I create the class
\DERHANSEN\SfEventMgtMypaymentmethod\Payment\Mypaymentmethod and add
the following method.:
/**
* Adds required HTML (for redirection) to the given values-array
*
* @param array $values
* @param bool $updateRegistration
* @param \DERHANSEN\SfEventMgt\Domain\Model\Registration $registration
* @param ActionController $pObj
* @return void
*/
public function renderRedirectView(&$values, &$updateRegistration, $registration, $pObj)
{
$pluginSettings = $this->getPluginSettings();
$view = GeneralUtility::makeInstance(StandaloneView::class);
$view->setFormat('html');
$view->setLayoutRootPaths($pluginSettings['view']['layoutRootPaths']);
$view->setPartialRootPaths($pluginSettings['view']['partialRootPaths']);
$view->setTemplateRootPaths($pluginSettings['view']['templateRootPaths']);
// @todo - e.g. call payment providers API to initialize payment
//
// Make sure to multiply the price with the given amount of depending registrations
//
// Depending on the payment provider you may receive a redirection URL or a token
// which can be passed to the standalone view.
$view->assignMultiple([
'settings' => $pluginSettings['settings'],
]);
$values['html'] = $view->render();
}
Copied!
Replace the @todo section with your own code. The returned view should include some text
and at least the link for the redirection. In order process automatic redirection, the
view could include a JavaScript redirect to the payment providers payment page.
5. Implement methods
Step 4 already showed how to implement one action. Feel free to implement other required
actions (at least
success,
failure and
cancel to your need.
Each PSR-14 Event enables you to update the given registration. Just set the properties of the
$registration object and set
$updateRegistration to
true.
It is also possible to remove a registrations, if payment failed or was cancelled. Please
see the corresponding PSr-14 Events for possible options.
6. cHash in generated links
All links created in
PaymentController will automatically have a cHash added by TYPO3.
This should be ok for most scenarios, but sometimes the payment provider will append GET
parameters to links (e.g. successUrl or failureUrl), which then leads to the situation,
that the TYPO3 cHash check fails.
Since all Payment actions are uncached and the registration GET parameter is checked
using a HMAC, the cHash can manually be removed from generated URLs by implementing
the
ProcessPaymentInitializeEvent PSR-14 event.
7. Security conciderations
Make sure that your rendered Fluid standlone views do not contain sensitive data or possibilities
for Cross Site Scripting (XSS) (
values['html'] is rendered with
f:format.raw).
FAQ
The event detail page shows a 404 error
This problem can occur in TYPO3 versions greater than 9.5.17 or 10.4.2 when the TYPO3 website has multiple
sites that use a shared folder for events. If this is the case, you must configure
unique slug handling
in the extension settings
slugBehaviour.
Why do you not include a nice CSS stylesheet?
Because you normally customize templates/stylesheets to your needs. Therefore the
extension just comes with a rudementary CSS stylesheet available in
EXT:Resources/Public/Css/events_default.css which must be included manually like
shown below:
Is it possible to extend events/registrations with own fields?
Yes, since version 3.0 of the extension, you can add additional Registration field on event basis.
You can also extend sf_event_mgt with own fields (e.g. new fields for Event). I have created a demo extension,
which shows how to add new fields to the event and registration domain model.
This only works, if you create links with
f:link.action as shown above. If you want to display the
categories in a select-box, then I suggest you create a CSS only select box (e.g. UL menu)
When does {event.registrationPossible} return TRUE
For each event, the attribute registrationPossible returns TRUE or FALSE, if registration for
the event is possible. TRUE is returned, when all conditions below are fulfilled:
Registration option is activated for the event
Max participants is not reached (if max. participants > 0) or max participants is not reached and waitlist is enabled
Date set at registration deadline is not reached
Startdate of event is not reached
Startdate of registration is reached (if set)
Why does the extension not support recurring events?
The user registration is one of the main features of the extension and it requires, that every event is unique in order
to save registrations for a particular event. This makes it impossible to only have one event record, that has multiple
recurrences.
Since there is no smart way to add recurring events to the extension without making it more complex and harder to
maintain, this feature will not make it into the extension.
How can I disable double opt-in for event registration?
You can enable autoConfirmation for new registrations as described in the TypoScript reference section.
With autoConfirmation enabled, new registrations will automatically be confirmed and the user
will not receive a confirmation email.
How does the simultaneous registration process work?
If the field "Max. simultaneous registrations per user" is set to a value greater than 1 for the given
event, a user is able to create multiple registrations at once. If the user in the registration view
chooses to create more than one registration, there will be created the given amount of registrations
in the backend for the user. All fields (e.g. firstname, lastname, email) will contain the same values.
The first registration saved is the "main registration", and all other registrations saved later will
depend on the "main registration". All "dependent registrations" will automatically get the option
"No email notifications" set to true, so custom notifications are only sent to the email address
of the "main registration".
If automatic confirmation is turned off (default), the user has to confirm the registration by clicking
a link in the confirmation email. When the user confirms the registration, all "dependent registrations"
of the "main registration will automatically also be confirmed.
How can I set a default currency?
You can set default values for many fields in TYPO3 by using TCAdefaults. To set a default value for the
currency field, add the following to the Page TSConfig, which sets € as the default currency for new records:
How to make the field "Accept terms and conditions" mandatory
The field "Accept terms and conditions" is part of the registration domain model, but it is not required
during registration. To make the field required, add the field to the list of required field like shown below:
You can override all language files with your own translations/labels. As an example, the following code
overrides/extends the
locallang_db.xlf and the
locallang.xlf
Add this example code to a
ext_localconf.php file (e.g. in a site package extension).:
How can I use the overwriteDemand feature for the search view
It is also possible to use the overwriteDemand feature for the search view in order to limit the
events that the search result includes. If you for example wish to limit the search to a special
category, you must pass the category UID as shown below (the value field contains the category UID).:
Native pagination is not supported for the searchview, since besides GET parameters
also POST parameters need to be considered in order to render the pagination. Although
it technically would be possible to implement this feature, it will not be includes
in the extension as it is a suboptimal solution (search word as dynamic GET parameter).
If you need a paginated search for events, it is recommended to use a search extension
(e.g. ext:ke_search or ext:solr).
How does the payment process work
For each event with registration enabled, you can also enable payment. If payment is enabled, you can output
available payment methods for the event in the registration form. When a user registers for an event, he
can select a payment method.
The extension comes with 2 default payment methods
debit and
transfer. Both payment methods do not include
any further payment processing.
It is possible to extend the extension with own payment methods that include further payment processing (e.g. by
an external payment provider).
For more information on how to add custom payment methods, see Payment section
The default payment methods are missing
Open the extension settings in the extension manager and press the "Save" button.
Configured price options do not show up in frontend
Make sure that the date for the price option is valid. Also make sure, that you use
{event.currentPrice} in your
Fluid template to output the current price.
How can I use the iCalDownload action in the Listview?
With the following Fluid snippet, you can use the iCalDownload in the listview:
Note, that you have to set the pageUid to a page with the detail view plugin.
Why does the next/previous month links not work for the calendar view?
The next/previous links use the
overwriteDemand feature, which by default is disabled. Make sure you have
unchecked the Disable overwrite demand setting in the plugin.
The category filter for the list view does not work
The filtering also uses the
overwriteDemand feature, which by default is disabled. Make sure you have
unchecked the Disable overwrite demand setting in the plugin and also ensure that the category mode is not
equal to
Ignore category selection.
How do I show the event title as page title on the detail page?
Either use the TYPO3 PageTitle API or you can use the title-ViewHelper of this extension.
How do I set the indexed search title for an event?
Use the title-ViewHelper of this extension.
The Payment Plugin throws exception about missing default controller
The page with the Payment Plugin shows the following error:
The default controller for extension "SfEventMgt" and plugin "Pipayment" can not be determined. Please check for TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin() in your ext_localconf.php
Copied!
Please delete the content element with the Payment Plugin and create a blank content element of type "Plugin" and
next directly select the Payment Plugin from the plugins select box.
If the plugin originally was a plugin with Flexform settings and switchableControllerActions, those settings
will remain in the database field pi_flexform and lead to the described error.
How can I move registrations on the waitlist automativally up, if a registered user cancels a registration?
Since version 5.2.0 there is a simple and default waitlist move up process. Please refer to the documentation
section about the Default waitlist move up process for further information.
If the default move up process does not fulfill your needs, you can use the PSR-14 Event
WaitlistMoveUpEvent
to implement your own move up logic.
Event registrations get confirmed by search engines
Under certain conditions with extensions that create sitemaps it may happen, that a confirmation link of a
registration email gets added to the sitemap and afterwards visited by a search engine crawler.
This behavior has at least been seen when the extension
metaseo has been used to create a sitemap.
In order to avoid the registration link from being added to the sitemap, the page with the
registration plugin needs to be excluded from the sitemap, i.e. use "Exclude from sitemap" in the page
settings or by other means (e.g. blacklist in EXT:metaseo).
Displaying events using the "Insert Record" content element
If you display events using the "Insert Record" content element, you may want to use a different layout to display
the event detail view. For this purpose, you can use
{settings.detail.isShortcut} in the Detail.html Fluid
Template to render a different layout.
How can I display JSON-LD data for events?
If you want to to display JSON-LD data for events in the event detail view, you can add an own partial including
the JSON-LD data you need. Since requirements of data in JSON-LD may vary per project, sf_event_mgt does not ship
with a partial or ViewHelper to create such data.
Example Partial Code (will work until Fluid < 3.0):
Note: When using Fluid, always make sure to escape variables properly.
As an alternative, you could create an own ViewHelper which generates the required JSON-LD data.
Images for categories are not shown in the frontend?
Categories in TYPO3 backend do not have an image by default. The TYPO3 extension ext:news
by Georg Ringer adds additional fields (e.g. an image-field) to the category domain model.
If you want ext:sf_event_mgt to use the category domain model of ext:news, the category domain model
of ext:sf_event_mgt needs to be overridden as shown below:
Add this to an extension (e.g. your sitepackage) in
ext_localconf.php:
After adding this snippet and clearing the cache, all categories in events do now use the category
domain model of ext:news
Editing events is very slow having a huge amount of registrations. Can this be fixed?
Short answer: No, not really. For TCA inline fields, TYPO3 will load all data before opening the records
in the backend. So having an event with 1500 registrations will actually load all registrations before
showing the edit form for the event in the TYPO3 backend. Note, that just disabling the field "registration"
by TCA will not work, since TYPO3 will load the data anyway.
In order to make it at least possible to edit the event data, the extension makes it possible to hide all
registration inline fields and prevent TYPO3 from loading all data when a configurable limit of registrations
is reached per event.
How can I show and browse the event calendar by weeks?
The calendar view is able to show events by week or by month. The default template
contains the markup for the month view including links to browse to the previous
and next month.
In order to show events by week, it is recommended to create a new template layout
for the calendar view and next to use the fluid variable
{weekConfig} to
show events for the current week and to create previous and next week links. The
default template includes an example, which is surrounded by
<f:comment>
How can I preview event records while editing?
It is possible to activate the View Button for event records.
Add the following page TSconfig to your root page. It is recommended to use
a site package extension, see
Official Tutorial: Site Package for this purpose.
By using the given example, a link will be generated which leads to the
page with the id 91.
If a event detail plugin is placed on this page, the event will be shown.
If hidden events should be shown, make sure to activate the
Allow preview of hidden event records setting in the detail plugin.
Note
Be aware to secure the page (e.g. set page visibility to "hidden") as this page could be called by anyone
using any event record uid to see its content.
Note
For security reasons, please always use a dedicated page with a dedicated event detail plugin for event preview.
Registrations get confirmed and/or cancelled by Email Security Gateways
Some Email Security Gateways or Antivirus/Anti-Malware Software may follow links in emails. This can lead to the
situation, that event registrations get confirmed and/or cancelled automatically.
The TypoScript settings
settings.confirmation.additionalVerificationStep and
settings.cancellation.additionalVerificationStep can be activated to avoid this problem. When active,
links in emails will refer to a page, where an confirmation- or cancellation-link has to be clicked manually
by the user.
The registration form does not submit
If the registration form does not submit, it is likely, that a validation error
occured. It is recommended to check all validation errors by adding the
following fluid code to the registration template.
In this version, to PiEventPluginUpdater introduced in version 6.0.0 has been
removed, because it is not compatible with TYPO3 13.4. User of the extension
updating to version 8.x must ensure to update from at least version 6.0.0 or above.
Updating from version 5.x or below to version 8.x is not supported due to several changes
in the TYPO3 plugin structure. Make sure to update to at least version 6.x of the extension
before updating to version 8.x.
Additionally, the database type for price fields has changed. Make sure to apply database
changes. Note, that due to field change from "double" to "numeric", rounding errors may
accur in very rare scenarios, where the price contains many digits after the comma.
This change is however optional, but it is recommended to apply it.
8.0.0
This version contains several breaking changes. The most relevant changes are:
All plugins have been migrated to content elements. It is required to execute
the included update wizard. Possible content element restrictions in backend
layouts or container elements must be adapted manually.
All existing links sent via email to registered users (e.g. confirmation- or
cancellation links) have become invalid.
A price option must now be submitted on registration, if at least one price
options has been defined in the event record.
Default CSV export format has changed
PageViewHelper (optionally used in backend context for custom
notifications) has now different arguments.
This version contains some minor breaking changes. The most relevant is a change
to the user registration plugin, where settings.detailPid and settings.registrationPid
must manually be migrated.
It is at least required to execute the "Migrate plugins and settings" update wizard
and to apply database migrations.
Note, that manual changes (at least to existing templates) is required. For further
information please refer to the change log.
5.1.0
This version contains a breaking change which might affect users who either extended the notification module with custom
code (e.g. by xclass) or who use
NotificationService::sendUserMessage() in own code.
If you have restricted the events in the plugin by category, you need to define the "category mode" by opening the
plugin settings and configuring the category mode. The default value of the "category mode" is to ignore the
category selection, so a category selection from a previous version of the extension would be ignored now!
Youtube embed field
The Youtube embed field has been removed. If you want to add a Youtube video to an event, use the TYPO3 core
functionality to add media items to the "files" field of an event.
2.0.0
Flexform restructuring
Due to restructuring of the Flexform settings of the event plugin, it is required to run the update
script of the extension, so existing Flexform settings (e.g. listPid, detailPid, ...) will be migrated
to the new structure. Please use the update script in the extension manager to process the
migration as shown below.
Please click on the update-icon to start the category migration.
Detail-page image-width and height
The following TypoScript needs to be migrated manually.
Please also update your Fluid templates, if you use the variables that changed.
1.5.0
The removal of the local category system requires the execution of a migration script, so existing
categories will get migrated to sys_category entries. Please use the update script in the extension
manager to process the migration as shown below.
Please click on the update-icon to start the category migration.
1.2.0
Due to the new cancellation-option for registrations, you need update all plugins, which are
configured to display "Registration" in the "What to display" section. Just open the plugin for edit
and select "Registration" in the "What to display"-selectbox.
It is not possible to translate emails sent by the extension
Prior to version 4.1.0 of the extension, the iCal download does not work, when
$TYPO3_CONF_VARS['FE']['compressionLevel'] is set to a value > 0 - https://forge.typo3.org/issues/69223
We migrated an instance from EXT:seminars v2.1 to EXT:sf_event_mgt v4.3
What's included?
Events
Registrations
Categories
Locations (multiple => single)
Organizers (multiple => single)
Speaker
We also migrated event types and target groups. The sql queries are basically the same like the category queries. You will need two more category fields in tx_sfeventmgt_domain_model_event for them.
SQL queries
We are starting with a fresh install of sf_event_mgt so we can use ids mostly 1 to 1.
/* Organizers */INSERTINTO tx_sfeventmgt_domain_model_organisator (uid,pid,name,email,email_signature)
SELECT
uid,
pid,
title,
email,
email_footer,
FROM
tx_seminars_organizers
WHERE
deleted = 0;
/* Locations */INSERTINTO tx_sfeventmgt_domain_model_location (uid,pid,title,address,city,description)
SELECT
uid,
pid,
title,
address,
city,
directions
FROM
tx_seminars_sites
WHERE
deleted = 0;
/* Speakers */INSERTINTO tx_sfeventmgt_domain_model_speaker (uid,pid,name,description)
SELECT
uid,
pid,
title,
description
FROM
tx_seminars_speakers
WHERE
deleted = 0;
/* Description of speakers */UPDATE tx_sfeventmgt_domain_model_speaker
SET
description = (
SELECTCONCAT(
IF (organization!='', CONCAT(organization, '<br>'), ''),
IF (homepage!='', CONCAT('<a href="', homepage,'">', homepage, '</a><br>'), ''),
IF (email !='', CONCAT('<a href="mailto:', email, '">', email, '</a><br>'), ''),
description
)
FROM
tx_seminars_speakers
WHERE
tx_sfeventmgt_domain_model_speaker.uid = tx_seminars_speakers.uid
);
/* Events */INSERTINTO tx_sfeventmgt_domain_model_event (
uid,
pid,
hidden,
title,
teaser,
description,
startdate,
enddate,
registration_deadline,
cancel_deadline,
enable_cancel,
location,
room,
speaker,
price,
enable_registration,
unique_email_check,
max_participants,
registration,
enable_autoconfirm,
enable_waitlist,
notify_organisator
)
SELECT
uid,
pid,
hidden,
title,
teaser,
CONCAT(
IF (
subtitle!='',
CONCAT(
'<h2>',
subtitle,
'</h2>'
),
''
),
description,
additional_information
),
begin_date,
end_date,
deadline_registration,
deadline_unregistration,
1, /* Enable cancellation */
place,
room,
speakers,
price_regular,
needs_registration,
IF(
allows_multiple_registrations = 1,
'0',
'1'
),
attendees_max,
registrations,
1, /* auto confirm registration */
queue_size,
1/* notify organisator on new registration */FROM tx_seminars_seminars
WHERE
deleted = 0AND
(end_date = 0OR end_date >= UNIX_TIMESTAMP()); /* filter out past events *//* Events <=> Locations */UPDATE tx_sfeventmgt_domain_model_event
SET location = (
SELECT
uid_foreign
FROM
tx_seminars_seminars_place_mm
WHERE
tx_sfeventmgt_domain_model_event.uid = tx_seminars_seminars_place_mm.uid_local
LIMIT1/* seminars has multiple locations, this extension has only a single location */
);
/* Events <=> Speaker */INSERTINTO tx_sfeventmgt_event_speaker_mm (uid_local,uid_foreign,sorting)
SELECT
uid_local,
uid_foreign,
sorting
FROM tx_seminars_seminars_speakers_mm
WHERE
uid_local IN (SELECT uid FROM tx_sfeventmgt_domain_model_event);
/* Events <=> Organizers */UPDATE tx_sfeventmgt_domain_model_event
SET organisator = (
SELECT
uid
FROM tx_seminars_organizers
LEFTJOIN tx_seminars_seminars_organizers_mm
ON
tx_seminars_seminars_organizers_mm.uid_foreign = tx_seminars_organizers.uid
WHERE
tx_seminars_seminars_organizers_mm.uid_local = tx_sfeventmgt_domain_model_event.uid AND
tx_seminars_organizers.deleted = 0ORDERBY
sorting ASCLIMIT1/* seminars has multiple organizers, this extension only a single organizer */
);
/* Categories */INSERTINTO sys_category (uid,pid,title,parent)
SELECT
uid + 10000, /* bigger than your highest category uid */
pid,
title,
823/* Parent category for our event categories */FROM
tx_seminars_categories
WHERE
deleted = 0;
/* Events <=> Categories */INSERTINTO sys_category_record_mm (uid_local,uid_foreign,tablenames,fieldname)
SELECT
uid_foreign + 10000,
uid_local,
'tx_sfeventmgt_domain_model_event',
'category'FROM tx_seminars_seminars_categories_mm
WHERE
tx_seminars_seminars_categories_mm.uid_local IN (SELECT uid FROM tx_sfeventmgt_domain_model_event);
/* Registrations */INSERTINTO tx_sfeventmgt_domain_model_registration (
uid,
pid,
hidden,
tstamp,
crdate,
fe_user,
`event`,
waitlist,
notes,
firstname,
lastname,
email,
confirmed,
amount_of_registrations
)
SELECT
uid,
pid, /* Your need to make sure registrations the same pid as event records (Inline relation) */
hidden,
tstamp,
crdate,
`user`,
seminar,
registration_queue,
CONCAT(
IF (attendees_names!='', CONCAT('Weitere Namen:\n',attendees_names,'\n\n'), ''),
IF (interests!='', CONCAT('Interessen:\n',interests,'\n\n'), ''),
IF (expectations!='', CONCAT('Erwartungen:\n',expectations,'\n\n'), ''),
IF (background_knowledge!='', CONCAT('Vorkenntnisse:\n',background_knowledge,'\n\n'), ''),
IF (known_from!='', CONCAT('Wie haben Sie von dieser Veranstaltung erfahren?\n',known_from,'\n\n'), ''),
IF (notes!='', CONCAT('Sonstiges:\n',notes,'\n\n'), '')
),
fe_users.first_name,
fe_users.last_name,
fe_users.email,
1,
seats
FROM tx_seminars_attendances
LEFTJOIN fe_users
ON fe_users.uid=tx_seminars_attendances.user
LEFTJOIN tx_seminars_seminars ON
tx_seminars_seminars.uid = tx_seminars_attendances.seminar
WHERE
tx_seminars_attendances.deleted = 0AND
tx_seminars_seminars.deleted = 0AND
tx_seminars_attendances.seminar IN (
SELECT
uid
FROM
tx_sfeventmgt_domain_model_event
);
Event management and registration - Content elements
This extensions adds a relation field for content elements to events.
The extension does not extend the event domain model and does not use xclass,
so it can safely be used with additional extensions extending sf_event_mgt
Event management and registration - Multi Registration
The TYPO3 extension sf_event_mgt_multireg is an additional extension
for sf_event_mgt, which allows for the simultaneous registration of multiple
individuals for an event. The extension also supports custom registration
fields for each event, making it possible to collect detailed participant
data. This extension builds upon the extensibility of sf_event_mgt and only
requires a bit of JavaScript to show or hide additional fields.
Allows to add multiple individuals in the registration form
Works with configured registration fields
First individual is the main registrant who must confirm the registration
Integrates smoothly with the sf_event_mgt extension
Requires minimal JavaScript for showing or hiding fields (vanilla JS version included)
Note
This extension uses xclass to extend the EventController and should
therefore be the only extension in a TYPO3 project extending sf_event_mgt.
Pricing
640,- € (excluding VAT)
The price is for the development of a custom version of sf_event_mgt_multireg
with an extension key and a PHP namespace of your choice.
Please contact me by email at torben@derhansen.com for inquiry, questions
and/or additional requirements.
Event management and registration - PayPal
The TYPO3 extension sf_event_mgt_paypal is an additional extension for sf_event_mgt, which seamlessly
integrates PayPal as payment method for event registrations.
Configurable behavior when registration is cancelled during payment
Pricing
360,- € (excluding VAT)
The price is for the development of a custom version of sf_event_mgt_paypal
with an extension key and a PHP namespace of your choice.
Please contact me by email at torben@derhansen.com for inquiry, questions
and/or additional requirements.
Event management and registration - Stripe
The TYPO3 extension sf_event_mgt_stripe is an additional extension for sf_event_mgt, which seamlessly
integrates Stripe as payment method for event registrations.
