sg_forms for TYPO3

Three form systems in TYPO3 create more confusion than choice

When it comes to forms, TYPO3 projects face an unusual luxury problem: there are three serious options. The native TYPO3 Form Framework (ext:form), powermail by in2code and sg_forms by SGalinski. Each has its own strengths and its own limits. sg_forms positions itself as the middle ground: lighter than powermail, but with more backend convenience than ext:form. The extension comes from the TYPO3 service provider SGalinski and is actively used in its client projects.

If you already run SGalinski extensions (sgalinski_base, sg_cookie_optin), sg_forms fits seamlessly into that ecosystem.

Typical use cases are contact forms, inquiries and simple job application forms

The standard scenario is the contact form on a corporate website: name, email, subject, message, GDPR consent checkbox, submit. sg_forms delivers this setup as a preconfigured template that editors activate and adapt in the backend. Fields can be added, removed and reordered, marked as required and given validation rules. The email goes to one or more configurable recipient addresses.

A second scenario is multi-page inquiry forms. A skilled trades business asks for contact details on page 1, the type of service (dropdown) on page 2 and photos of the property (file upload) on page 3. sg_forms supports multi-step forms with a progress indicator and back navigation. After submission, the data is sent as an email and optionally stored as a database record.

The third scenario is simple job application forms. An SME with three open positions does not need an applicant tracking system, just a form that accepts a CV and cover letter as PDF uploads and forwards them to HR. sg_forms provides file uploads with type and size validation for this, combined with a confirmation email to the applicant.

The technical architecture is based on Extbase with YAML-based form definitions

sg_forms registers an Extbase plugin that renders forms from a configuration. The form definition is created in the backend through a graphical interface or, alternatively, defined as a YAML file. Each field has a type (text, email, textarea, select, radio, checkbox, file, hidden), validation rules and optional conditions.

The finisher architecture follows the same pattern as powermail: after submission, actions run one after another. The standard finishers are sending the email, saving to the database and redirecting to a thank-you page. Custom finishers can be implemented as PHP classes, for example for CRM connections or webhook calls.

Frontend rendering runs through Fluid templates that can be overridden via a site set or TypoScript. The extension ships a default template that works without adjustments but is typically adapted to the corporate design for production websites. Spam protection is available through honeypot fields and optional CAPTCHA integration.

Common problems involve the choice between sg_forms and powermail, and SGalinski’s licensing

The most frequent question is: sg_forms or powermail? The answer depends on the size of the project. powermail has the larger community, more documentation, more third-party finishers and a broader feature set (PDF export, multi-step logic of any complexity). sg_forms is leaner, carries less overhead and is the standard in SGalinski projects. For most corporate websites, powermail is the safer choice. For SGalinski clients who are already in the ecosystem, sg_forms is the more consistent one.

The second topic is licensing. sg_forms is not available as a free extension in the TER (TYPO3 Extension Repository) but is delivered through SGalinski projects. Teams that want to use the extension without a relationship with SGalinski therefore have to clarify availability and license terms directly with SGalinski.

The third problem is migration. Anyone switching from powermail to sg_forms (or the other way around) has to recreate all existing form definitions, because the data structures are incompatible. Existing form submissions in the database cannot be migrated automatically.

sg_forms follows SGalinski’s release cycle, and v14 is already supported

SGalinski maintains sg_forms on its own release cycle, which is tied to the TYPO3 LTS versions. Version series 6 covers TYPO3 v12, series 7 covers v13 and series 8 already covers v14 (as of September 2026). When choosing a form system, Gosign recommends giving real weight to long-term maintenance and community size: powermail, with more than 2.7 million Composer installs on Packagist, has a much broader base than sg_forms.