TYPO3 extension sf_event_mgt version 3.0 released

Today I finally released the new version 3.0 of my TYPO3 extension sf_event_mgt - Event management and registration. The new version comes with tons of new features, bugfixes and improvements and also contains 2 breaking changes, so make sure to read the release notes.

Thanks to everyone, who contributed to the extension over the last few months. Also a special thanks to Alex Kellner for his extension powermail, from which I adapted ideas and some code for the registration fields feature.

New features 

Below follows some of the new features of sf_event_mgt 3.0.

Registration fields

Im order to make the extension more easy to use for non-programmers, I added the possibility for editors add additional registration fields to the default registration form on event basis.

Registration fields

Creating of registration fields works basically as in powermail. The user can add registrations fields in a new tab as shown in the screenshot above and choose one of the following field types: input, textarea, radio and checkbox.  When a participant registers to an event, all filled out registration fields are saved to the registration record in the TYPO3 backend.

allowLanguageSynchronization for TYPO3 8.7

The TCA settings allowLanguageSynchronization has been introduced in TYPO3 8.6 and is the successor for "l10n_mode=mergeIfNotBlank". Note, that sf_event_mgt did not use "l10n_mode=mergeIfNotBlank", so the language synchronization feature is only available in TYPO3 8.7

Signals

Finally, I also added signals in various actions, so it is now easily possible to modify/extend variables given to the desired views.

TYPO3 - Using Fluid StandaloneView to render localized templates in a scheduler task (part 2)

Today I found, that the technique I described in my blogpost about rendering localized Fluid templates in a scheduler task does not work as expected. As long as you want to switch the language used to render the templates only one time, then you're fine. But as soon as you want to switch the language several times (e.g. sending multiple localized e-mails in one request), then you experience that only the first language switch is respected.

The root cause for this is the TYPO3 LocalizationUtility, which includes the static translate() method that is used return translated language labels from XLF/XML language files. The LocalizationUtility is not designed to handle multiple language switches in one request, so at this point I'm stuck.

I order to keep things simple for the integrator (use one e-mail template with language labels to send out localized e-mails in a scheduler task), I decided to create an own viewHelper which uses a modified version of the LocalizationUtility. The modified version of the LocalizationUtility does not contain any static variables or methods and can be used with dependency injection. You can find the code in this GitHub repository.

Usage

In my Fluid StandaloneView templates I now use my own translate viewHelper as shown below.

The viewHelper uses the LocalizationService (which is the TYPO3 LocalizationUtility with some small modifications - e.g. removed all "static" declarations). As a result of this, all functionality of the original viewHelper / TranslationUtility are remained (e.g. overwriting language labels with TypoScript)

I extended the original demo extension from my first blogpost so it makes use of the new viewHelper / LocalizationService. The Extension now includes a form, which renders multiple Fluid StandaloneViews in one request and the language is switched for each individual StandaloneView (see result-section in the screenshot below)

The demo extension also includes a command controller, which includes a command that also renders multiple standaloneViews in one request (see screenshot below)

If I don't find any major problems, I will make use of this technique to send out multilingual e-mails in a scheduler task in my Event Management Extension.

Final notice

The technique shown should only be used in the backend context of TYPO3 when you want to render multilingual Fluid StandaloneViews in one request. I'm not very happy with the approach of "just" taking some code from the TYPO3 core and adapting it to my needs, since this is not always a clean solution and it may include some drawbacks.

TYPO3 - Using Fluid StandaloneView to render localized templates in a scheduler task (part 1)

tl;dr: If you want to use Fluid StandaloneView to render a template in a given language from the backend context (e.g. scheduler task), make sure you set the language in $GLOBALS['BE_USER']->uc['lang']

If you want to switch the language several times in one request, please read on in part 2 of this blogpost.

Problem description

For my Event Management TYPO3 Extension I am developing a feature, where I need to send out localized e-mails to users. The e-mail content is created using a Fluid StandanloneView in a TYPO3 scheduler task. Actually, this doesn't work out of the box.

In TYPO3 you can use Fluid StandaloneView to render HTML based content, which e.g. can be added to body field of an HTML e-mail. The TYPO3 Wiki contains some code snippets on how this can be processed. If you use the provided code snippets in your ExtBase extension, it works fine for localized content as long as you use it in the frontend context of TYPO3 (e.g. website user requests an action). 

When you use Fluid StandaloneView from the backend context to generate localized content, the output differs from what you would expect. When you are logged in as a TYPO3 backend user, then the localized content is rendered with the language the backend user has chosen in the user setup. In addition, if you render a Fluid StandaloneView from a commandController, then the language is ignored completely.

Solution

After digging into the problem, I found a simple way to control the language which is used during the rendering process of the Fluid StandaloneView. For the backend context, you just need to set a language (ISO2 code, lowercase) in the $GLOBALS['BE_USER']->uc['lang'] setting. Below follows a code example which shows how this is done (see line 12).



Note, that you also have to make sure, that the Fluid StandaloneView knows, from which extension the localizations get loaded. This is set in line 24.

The shown method works in both TYPO3 6.2 and the current TYPO3 master. I provided a little demo extension, which I used for testing purposes. It contains a backend module and a command controller which renders a Fluid StandaloneView with a given language.

Technical background

The f:translate viewHelper uses the TYPO3 LocalizationUtility to render localized content. For the frontend context, all labels are translated depending on the language set in $GLOBALS['TSFE']->config['config']['language']. For the backend context, the language set in $GLOBALS['BE_USER']->uc['lang'] is used.

TYPO3 CMS - Event management extension with registration option

Today I've published the first release of my latest extension "Event management and registration" (sf_event_mgt) for TYPO3 CMS. The extension enables TYPO3 editors to manage events in the TYPO3 backend and can show a list- and a detail-view for upcoming, past or all events in the frontend. The list-view can be extended by individual layouts as known from the TYPO3 news extension (tx_news), so it should for example be possible to create a nice image slider for all upcoming top-events.

As events also could require a registration process (e.g. if the number of participants is limited), I added a registration option, so users can register for an event. TYPO3 editors can assign a maximun value for participants to each individual event, so it can not be over-booked. The registration contains a double opt in process, so users must confirm, that they actually have registered for the event. To ensure, that new registrations are processed in time by the registering user, a validity for confirmation-links can be configured.

Event record in TYPO3 backend

The extension also comes with a backend module, which enables TYPO3 editors to get an overview of all available events. Also the backend module contains a CSV-Export option for events where registration is enabled, so a list of registered participants easily can be exported.

Event backend administration module

The backend module also contains a notification module, where TYPO3 editors can send e-mail notifications to all participants of an event (e.g. if the event has been cancelled). Notification templates can be configured individually with some lines of TypoScript and with a Fluid template.

Notification module to send notifications to participants

Finally, the extension has some nice features, which are more technical, but makes the extension very flexible and extendible. Of course, the extension comes with a documentation ReST format which explains all features in detail.

I've tried to keep the code quality at a high level, respected the TYPO3 CGL as much as possible and also "Event management and registration" is fully covered by tests (which does not mean it is bug-free).

The extension is available on TER and bugs as well as feature requests can be reported on GitHub, where also the source code of the extension is hosted.

Asynchronous banner management for TYPO3

Today I published my banner management extension sf_banners for TYPO3. It is able to show image, flash and HTML banners on a TYPO3 website. Each banner contains a statistic which shows the banners' impressions and clicks. The banners can be limited to an maximum amount of clicks/impressions and you can control the date on which the banners are shown by using the TYPO3 start- and stop function.


One of the main features of the extension is the ability to load banners asynchronously, so the main load time af a page is not being affected by the plugins rendering process.

The extension has been developed using Extbase and Fluid to ensure compatibility to existing and future TYPO3 versions. Also test driven development was one of the main aspects in the development process to ensure, that new features and code changes do not break existing functionality. The extension has been tested with all current versions of TYPO3 from 4.5.x to 6.0.x

If you have any comments or suggestions, feel free to post them on the extensions GitHub projectpage.

Development process

Below follows a short summary about the development process of the extension.

The first approach of the extension was to use pure Extbase/Fluid functionality to display the banners on a page. Since the extension has to update impressions and also has to select the banners from the repository on each request, the plugin has to be non-cached. After having finished this approach, I was disappointed by the performance of the page rendering time. As I tested the extension on several TYPO3 versions, I also found out, that the page rendering time decreased the higher the TYPO3 version got.

So I read a lot of discussions on the TYPO3 mailinglists and the internet about Extbase and performance tuning and ended up with the solution to load all banners asynchronously by Ajax. To do so, I implemented JQuery and added an action to the controller which delivered the banners content as pure HTML. After that, everything seemed to run fine. Since the plugin now was cached and content fetched by Ajax, the page load time was'nt mainly affected by the extension. Sadly my integration tests showed, that there were problems with HTML/JS banners containing document.write JavaScript code. As the banners HTML/JS code was loaded asynchronously, a document.write statement would be executed after the page DOM is loaded. The result was, that the main page was loaded and shortly after that, the HTML/JS banner was shown and the formerly rendered page output was completely removed.

The solution to get rid of the document.write problem was postscribe. This standalone JS library overrides document.write and enables the usage of document.write after the DOM is ready.

All development steps are filed on GitHub and you can look at each of the approaches described above, as the different steps have been tagged.

TYPO3 Flow / Fluid - translating select fields

In a TYPO3 Flow project, I had to create a select box with countries, from which the user could select one. This task is really easy with TYPO3 Flow. Just create a domain and repository for the countries, add the necessary templates and create the country-records. Now you are ready to create a relation from a existing domain (e.g. a domain with some address-fields) to the country domain. No problems here. But what, if you want to translate the country-names in different languages?

The Fluid viewhelper "f:form.select" seems to have an argument called "translate" which can handle translation of select fields labels. I could'nt find a tutorial how to use this argument and finally found out, that everything was described directly in the viewhelpers class.

Here is a short summary on how to use the f:form.select viewhelper together with the "translate" argument.

Assume you have an domain called "country". It only has one property called "alpha2", which is a string representing the country's ISO-3166 alpha2-code. You create some records in the new domain like "DE" for Germany, "DK" for Denmark and so on. You also have an domain called "address", where you have a relation to the country domain.

The first thing to do is to create the translation files. In this example I create one for english and one for german.

<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
    <file original="" source-language="en"  datatype="plaintext">
        <body>
            <trans-unit id="DE">
                <source>Germany</source>
            </trans-unit>
            <trans-unit id="DK">
                <source>Denmark</source>
            </trans-unit>
        </body>
    </file>
</xliff>

<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
    <file original="" source-language="en" target-language="de"  datatype="plaintext">
        <body>
            <trans-unit id="DE">
                <source>Germany</source>
                <target>Deutschland</target>
            </trans-unit>
            <trans-unit id="DK">
                <source>Denmark</source>
                <target>Dänemark</target>
            </trans-unit>
        </body>
    </file>
</xliff>

Next you should configure your f:form.select viewhelper, so it uses the translations.

<f:form.select property="country" id="country" options="{countries}" optionLabelField="alpha2" translate="{using: 'label'}"/>

The viewhelper is configured to use "alpha2" as a label field and to use the label field for translation. There are several other options for the translate argument (e.g. the "source" attribute which enables you to select a different localization file), which are described directly in the class.

Now you just have to assign the object "countries" (containing all countries from the country-repository) through the controller to the corresponding view and you're done.