Choose a login box extension and a front-end user registration extension, install and configure them. On my site, I use newloginbox and sr_feuser_register, but you may want to use others. You can leave out the  front-end user registration extension if you don't want front-end users to be able to create their own accounts.

If you use the extension sr_feuser_register, make sure that the salutation modes of that extension and the seminars extension are the same so that your users get a consistent experience.

Make sure that you make the following fields required, or this extension won't work properly: name, email, username

If you like, you can install the extension erotea_date2cal to add a nice calendar widget to date and time fields on the back end (e.g. the start date and time of a seminar).

This extension uses two different HTML templates:

Note: Do not change the HTML templates directly in the extension directory as then your changes will be overwritten when you upgrade the extension to a new version. Make a copy and modify the copy instead:

First, include the Seminars template in your site template under “Include static (from extensions)”.

Then configure the plug-in in your TS template setup or the plug-in flexforms. The properties are listed in the reference.

Please note than when using flexforms, you need to set the corresponding values at all relevant instances of the plug-in: It doesn't do to specify the fields for the online registration in the seminar list front-end plug-in—you need to set these fields in the online registration front-end plug-in.

These are the variables you absolutely need to set to get this extension up and running:

Note that the notification e-mail to the organizer and the list view show the headings even for empty fields, while the single view and the notification e-mail to the participant remove the headings for some seminar properties (not all, just where it makes sense).

You can set up to two different prices for each event: a “standard price” and a “special” price, e.g. for students and people on the job. In the single view, the standard price always gets displayed (even if it is 0), while the special price only gets displayed if it is not 0.

If you have only one price per seminar, you can configure the list view to not display the special price column (look in the reference for details). In addition, you might want to set some of the following options to just display “price” instead of “standard price”:

If you have two prices for some or all seminars, you can change the default labels “regular price” and “special price”, e.g. to “Adults” and “Children”. You can change them using these variables:

Replace “language” with your two-letter language code if you use a language other than English, e.g. “de” for German. Use “default” as language code for English.

You can change most of the localized strings that are used on the front end and for the e-mails. (The localized strings for the back end and the input form labels for the online registration currently cannot be changed.)

When you want to change some strings, please don't change locallang.xml or pi1/locallang.xml directly as these changes would get overwritten on the next update. Instead, do it like this:

The extension provides its own basic set of CSS styles (which work best with a white background and if you're already using a CSS-based design and css_styled_content). These stylesheets usually get included automatically. However, if your have set disableAllHeaderCode = 1 and want to use the provided stylesheet, you need to include the stylesheet typo3conf/ext/seminars/pi1/seminars_pi1.css manually into your page header.

When looking to the source of the HTML output of this extension, you will see that there are some parts of the output (for example table cells) marked to belong to a certain class. But not every part has as 'class=”xyz”'—we have only those classes that are actually used in the CSS file so that the HTML code stays lean. If needed, you can add classes to these parts by adding them to your TypoScript setup (in the template):

By default, the organizer field in the ListView has no class added to keep the HTML-Output as clean as possible. It looks like this:

[...]<td>[name of the organizer]<td>[...]

If you add the following line to your setup,

plugin.tx_seminars_pi1.class_listorganizers  = organizers

the output shows us the following:

[...]<td class="tx-seminars-pi1-organizers">[name of the organizer]</td>[...]

So the resulting class name will be tx-seminars-pi1 and the value from the corresponding TS rule appended. Please not that the last part of the name in the TS setup (“class_listorganizers”) needs to match the string in the HTML template (“###CLASS_LISTORGANIZERS###”). The only difference lies in the capitalization and the “###”.

Then you can add a rule like this to your CSS file:

.tx-seminars-pi1-organizers { ...;}

Configuring the colored square for the number of vacancies

In the list view, the color of the squares in the vacancies column is configured using CSS. The table cell for the vacancies has three CSS classes:

The square itself also has a CSS class:

This allows you to configure the color of the square in detail, depending on the number of vacancies. The default stylesheet uses:

The corresponding part of the default CSS file looks like this. You can do this likewise in your own style sheet:

.tx-seminars-pi1-vacancies-available .tx-seminars-pi1-square {

  background-color: #00a500;

  color: inherit;

}

.tx-seminars-pi1-vacancies-2 .tx-seminars-pi1-square, .tx-seminars-pi1-vacancies-1 .tx-seminars-pi1-square {

  background-color: #ffff3c;

  color: inherit;

}

.tx-seminars-pi1-vacancies-0 .tx-seminars-pi1-square, .tx-seminars-pi1-cancelled .tx-seminars-pi1-square {

  background-color: #c30000;

  color: inherit;

}

In addition to the website_users_folder, you need to create one or more system folders that will contain records of the following types:

Technically, it is possible store these records on regular pages instead of on system folders—they just help in keeping everything sorted. In addition, you can put records of more than one type on the same page or even scatter records of the same type on several pages.

This needs a little planning as you should consider the following:

If you create these folders outside of the site root page with the template, you still need to create a template for them and “include static (from extensions)” in that template, or else the back-end module will not be able to use the extension's default configuration (e.g. the date and time format, so that date won't get displayed in the back-end module).

Example: In my case, we have a handful of organizing teams. They shouldn't be able to modify each other's seminar records, but all of them should be able to manage speakers (some speakers work for more than one team), seminar sites(the sites are used by all teams) and registrations (we share one office and accept manual registrations for other teams' seminars). There are two seminar lists on the page: One list containing seminars by all organizers, and one list containing seminars by one particular organizer.

So we've set it up like this:

All in all, our folder hierarchy currently looks like this:

Please note that this is just an example. Your mileage may vary greatly.

The user groups who should be able to manage seminars should have:

If you want to enter registrations manually for participants who don't have a front-end user account yet, or if you want to be able to edit the front-end user data, you need to set the following access rights as well:

In the default configuration, this extension allows each user to register only one seat per event. This can be changed if you need users to register more than one seat per registration (e.g. when you use this extension for a theater, or you would like companies to register all their attendees in one go).

Please note that this doesn't enable users to register multiple times—it just allows them to enter the number of seats for their registration.

This is what needs to be changed:

If the field seats is not filled in (ie. the registration is for 0 seats), the registration is counted as 1 seat.

Please note the the number of seats currently is not included in the automated e-mail to the user. This will be implemented in a later version of this extension.

This feature allows front-end users who have signed up for an event to see who has signed up for that event as well, eg. for forming car pools or for coordination before the event takes place. In addition, this allows so-called VIPs (eg. speakers or organizers for that event) to see that list as well. Both features are disabled by default. When using this feature, make sure that this complies with your privacy policy!

Both lists are set up separately. Even if you use both lists, they need to be set up separately.

You can enter a list of FE user field names that will be displayed in the registration lists using the TS setup variable plugin.tx_seminars_pi1.showFeUserFieldsInRegistrationsList. The default is to only display the attendee's names.

Setting up the front-end registration lists for attendees

Please note that there is no fine-grained access rights system: Either you allow all attendees to view the registration lists for all events for which they have signed up, or you don't.

Setting up the front-end registration lists for VIPs

Please note that this feature has a rather fine-grained access right system: For each event, you can specify which FE users should be allowed to view the registration lists of that particular event.