Formlog for TYPO3

Why every third contact inquiry in TYPO3 is 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 when which personal data was received and when it was deleted. Formlog stores submissions with timestamps and offers configurable automatic deletion after X days. For ISO 27001 audits, this provides gap-free documentation of data processing.

Analysis of input behavior. Which fields are frequently left empty? At which form step do users abandon? Formlog makes this data visible in the backend. 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 after validation and before the email finisher.
• 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.
• GDPR deletion: via a scheduler task, entries are automatically deleted after a configurable number of days. Default: 90 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. Additionally, the user must have read access to the SysFolder where entries are stored.

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 Formlog cleanup task 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 (now part of Undkonsorten) and is available as a Composer package (pagemachine/typo3-formlog). The extension supports TYPO3 v10 through v12 LTS. For TYPO3 v13, there is no official release yet, but 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 finisher configuration slightly in v11 (strict typing of options). A database update via the Install Tool Upgrade Wizard is typically not required because the schema has remained stable.

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.