Formlog for TYPO3

Why contact inquiries in TYPO3 can be lost without logging

Contact forms are the most important lead channel on corporate websites. But TYPO3’s Form Framework does not store submissions in the database by default - it only sends emails. If the mail server fails, the SPF record is misconfigured or the SMTP timeout triggers, the inquiry is lost. No backup, no tracking, no analysis. Formlog closes this gap by logging every form submission in the TYPO3 database - regardless of whether email delivery was successful.

In practice, this affects more companies than expected: email delivery rates from web servers are between 85% and 95% according to studies. With 100 contact inquiries per month, that means 5 to 15 lost leads. At an average lead value of 500 EUR in B2B, this adds up to 2,500 to 7,500 EUR in lost revenue per month.

Typical use cases

Insurance against email outages. A mid-market company operates 3 contact forms on its TYPO3 website. The hoster’s SMTP server has a 6-hour timeout over the weekend. Without Formlog, all inquiries during that period are lost. With Formlog, the marketing team finds all submissions in the TYPO3 backend on Monday morning and can follow up manually.

Compliance documentation for GDPR and ISO 27001. Companies must be able to demonstrate that they keep personal data only as long as necessary (Art. 5 GDPR). Formlog stores submissions with timestamps and offers configurable automatic deletion after X days. For ISO 27001 audits, this shows which form data arrived when.

Analysis of input behavior. Which fields are frequently left empty? Formlog makes the submitted entries visible in the backend; it does not record drop-offs before submission. A TYPO3 integrator can derive optimizations from this without deploying an external analytics tool for forms.

Technical architecture

Formlog integrates as a finisher in the TYPO3 Form Framework (EXT:form). Every form that has a Formlog finisher configured writes its submissions after submit into a dedicated database table (tx_formlog_entries).

The architecture in detail:

• Finisher integration: Formlog registers its own finisher type that is added in the Form Framework’s YAML configuration. The finisher runs where it sits in the finisher list; placed before the email finisher, it also logs when sending fails.
• Database schema: each submission is stored as a JSON-serialized array along with metadata (timestamp, form identifier, language, page).
• Backend module: Formlog provides a dedicated backend module where editors and administrators can filter, search and export logged submissions as CSV or Excel (XLSX).
• GDPR deletion: via the Core scheduler task “Table garbage collection”, entries are automatically deleted after a configurable number of days. Default: 180 days.

Dependencies: Formlog requires the TYPO3 Form Framework (EXT:form), which has been part of the Core since TYPO3 v8. Older form extensions like Powermail or Formhandler are not supported - they have logging integrated natively. The database table requires little storage depending on form volume: 1,000 entries with an average of 10 fields occupy about 5 MB. Automatic deletion prevents uncontrolled table growth.

Common problems and solutions

Formlog does not log all form fields. Cause: the Formlog finisher must be configured after the validation step but before the redirect finisher. If the redirect fires first, the Formlog finisher is no longer executed. Solution: check the finisher order in the YAML configuration - Formlog should be at position 1, before email and redirect.

Backend module shows no entries. Frequently a permissions issue: the backend user or backend group does not have access to the Formlog module. Solution: enable the formlog module under “Allowed modules” in the backend group settings. No SysFolder is involved, as Formlog stores the entries at root level.

Automatic deletion does not work. The TYPO3 Scheduler must be correctly set up and running regularly (cronjob every 5 to 15 minutes). Without a functioning scheduler, the cleanup task is never triggered. On shared hosting environments, the cronjob is frequently not or incorrectly configured. Check in the TYPO3 backend under System > Scheduler: the “Table garbage collection” task for tx_formlog_entries must be listed as active and the “Last execution” date must not be older than 24 hours.

Migration and version compatibility

Formlog was developed by Pagemachine AG, based in Frankfurt, and is available as a Composer package (pagemachine/typo3-formlog). The current version 2.6.0 supports TYPO3 v13 and v14; older series go back to v8. The codebase is built on stable TYPO3 APIs (Form Framework Finisher, Extbase Repository Pattern), so compatibility can be established with manageable effort.

During a TYPO3 upgrade from v10 to v12, the Formlog configuration in the YAML form definitions must be reviewed. The Form Framework changed finishers slightly in v11 (dependency injection in finisher classes, FluidEmail in the email finisher). From Formlog 2.3.0 on, the upgrade wizard “Form Log Entry Page Update” should also run; it moves the page information of the entries into a dedicated field.

For those migrating from Powermail to the TYPO3 Form Framework, the built-in Powermail logging is lost in the process. Formlog is the recommended replacement. Gosign migrates forms including logging configuration and ensures existing data is not lost.

An aspect many project teams overlook: Formlog is not just a backup tool but also an audit instrument. When a customer claims they sent an inquiry 3 weeks ago that was never answered, Formlog provides the evidence - either the inquiry exists with a timestamp, or it was never submitted. For companies with service level agreements and complaint management, this is a measurable advantage that justifies the 10-minute installation.