Following a call for contributors from Björn Jacob, CEO of TRITUM GmbH, a new TYPO3 Form Initiative Code Sprint was held in Jena from April 25th to 28th. This should be the first bigger chunk of changes which will eventually end up in TYPO3 v10, currently scheduled to be released in April 2020.
A few numbers first:
- 11 contributors joined the code sprint
- 36 tickets were resolved (Forge)
- 32 changes were merged, of these 16 were bugfixes, 3 were new features
- 1185 files were changed with 34415 lines added and 30089 lines removed
- ∞ party parrots were posted
Since changes to the wonderful TYPO3 form extension were rare these days, the TYPO3 Form Initiative set up a Code Sprint at the TRITUM office in Jena. Anyone interested in squashing bugs, adding frequently requested features and improving the documentation was invited to join. Many hackers from anywhere in Germany followed the call. After a move, the new TRITUM office can be found right in the middle of a „Neubaugebiet“ in the city district Winzerla, aka „Winzer L.A.“
As usual a sprint board was prepared which gave a good overview of all tickets and pending reviews, which could be done during the sprint. For some reason I ended up working on three tickets about „multiple“ things during this sprint.
Allow multiple recipients in email finisher
One major feature missing in the form extension so far was a way to set multiple recipients for forms. Only a single recipient with a name could be set, multiple recipients were unofficially permitted for Reply-To, CC and BCC. For the latter no names could be set and there was no UI to set these in the form editor backend module.
All of this is solved now and editors will be glad to set multiple recipients in the form editor now:
If you don’t want to use the editor, the YAML syntax is straightforward, too, and is the same for Reply-To, CC and BCC:
recipients: email@example.com: CEO firstname.lastname@example.org: First email@example.com: Second
Also the finisher overrides in the form plugin allow for setting recipients different from the form definition:
Send plaintext and HTML (multipart) mails in email finisher
Sending plaintext or HTML mails was possible with the form extension since its inception. So far you had to choose between one of these two formats. Since you can expect mails to contain both plaintext and HTML parts, I tackled and implemented this for the email finisher.
The plaintext part will now always be sent as a body since it can be processed by humans and machines just fine. The HTML part will be added to each mail by default but an option has been added to disable this. This can increase reception of mails since there is no rich content which can be used to inject malicious code or misleading content like phishing links.
Use multiple translation files by default
A minor annoyance reared its ugly head once custom translations should be added to form elements, the form editor or finisher overrides. In all of these cases not adding the default translation files of the form extension led to missing labels.
I fixed this by turning the
translationFile option into
translationFiles which now must always be a list. All
translationFiles options contain the default translation files of the form extension and thus can be extended safely now.
There is no migration at runtime for this compared to the other two changes above, so updating form definitions (manually or by saving in the form editor) and form setup customizations is mandatory.
See the changelog entry for details.
Review all the things!
Aside from these changes I tried to review as much as possible, which is a lot easier if you can focus on a topic during a sprint. Compared to that daily work rarely leaves any time for thorough reviews and discussions. For this reason alone I strongly recommend anyone to join a code sprint!
During the sprint there were long-deserved updates for the form documentation. Given that currently, all form setup changes need to be copied to multiple locations in the docs, updates like these are rare. We still need to come up with a good concept how to keep the docs updated with reasonable effort.
And last but not least a good amount of bugs were squished and the UX was improved in many subtle ways.
Time to Relax
Of course a code sprint is not only coding from 8 AM to 12 PM (although there are people who prefer to do this) and we had our fair share of great meals and a lot of fun with great people. Jena is a medium-sized city where it is easy to get from A to B quickly, even just by walking. And especially the inner city around the market is full of life at friday night with students meeting up at various restaurants and bars and a nice scenery in between.
And if we did not get outside there were always the good and reliable delivery services, be it for pizza or Indian food. All in all we were well nourished to put everything into the form extension.
Thank you, next
The Form code sprint was well received by all participants and we were able to complete a lot in just a few days. There will be more sprints during the year, so watch out for announcements on the TYPO3 Slack #ext-form channel or check the eventpage of the TYPO3 Codesprint Orga Team.