sf_register for TYPO3

Why TYPO3 cannot become a user portal without a registration extension

The TYPO3 core knows fe_users as a database table and a standard login form, but it has no built-in way for a new user to register themselves or maintain their data; password reset is already part of the felogin login form. Every website that is more than a pure publication platform needs that capability: communities, member areas, protected downloads, personalised newsletters, paid content. sf_register fills this gap with a lean Extbase-based approach that focuses specifically on registration, profile and password change and deliberately skips features that the all-in-one solution femanager brings along.

Typical use cases

A specialist publisher with 3,500 subscribers offers online access to journal articles and studies. Each subscriber gets an account tied to their subscription number. sf_register handles the initial registration with double opt-in confirmation via email, creates the user automatically in the “subscriber” group and unlocks access to the protected pages. When the subscription expires, a TYPO3 scheduler task removes the group membership without deleting the account, so that the user regains access after renewing the contract.

A second case is a professional association with around 7,000 member companies running a protected members’ portal with conference documentation, standards previews and discussion forums. sf_register handles initial registration but simultaneously triggers a manual approval process in which an association employee verifies the affiliation with the member company before activating the account. The workflow combines double opt-in with admin approval; sf_register provides both as settings.

The third context is public institutions such as adult education centres or city libraries that want to tie course bookings or catalogue wish lists to a user account. What matters most here is a lightweight setup with low complexity: the extension does not need to manage twenty profile fields, just name, email, password and a library customer number. That is all, and sf_register delivers exactly that.

Technical architecture: Extbase, TCA and events

sf_register is cleanly built on the Extbase model. A dedicated FrontendUser model extends the core user, controller actions handle create, edit, confirm, delete and password changes, and templating runs through Fluid layouts. Required fields are controlled via TypoScript validators and can be extended there per field. Custom fields such as company, position or membership number need a small TCA entry, a model property and an addition to the Fluid template, which gives developers a clear structure but also means that every tweak requires code work.

The double opt-in process relies on hash-based confirmation links whose hash the extension recalculates on click from the action and user ID instead of storing it; it then resets the disable flag. Emails are sent via the TYPO3 mailer interface, which internally sits on top of Symfony Mailer, so that more complex setups with SMTP proxies or mailing services such as SendGrid work without problems. Password hashing uses TYPO3’s own password hash services and is therefore automatically in sync with every core update.

Common problems and solutions

The first problem is spam registrations. Every public registration page attracts bots that automatically create accounts to send emails to third parties via the password reset form or to place trackback spam in community features. A clean solution combines sf_register with a CAPTCHA extension such as sr_freecap or a honeypot field, complemented by rate limiting on the registration URL in the reverse proxy.

The second problem concerns email deliverability. Confirmation emails regularly end up in the spam folder if the TYPO3 server runs without an SPF record, DKIM signature or reverse DNS. The extension sends the mail correctly, but the receiving server silently drops it. The solution does not lie in sf_register but in the mail infrastructure: a dedicated sending service with an established domain reputation noticeably reduces the bounce rate.

The third topic is data protection. Registered users must be able to view, correct and delete their data at any time, and deletion has to cascade, which means downloads and other linked records have to be covered as well; orders may be kept as long as retention obligations apply. sf_register provides edit forms and a plugin for deleting one’s own account, but no deletion process for dependent data. That has to be added as a separate workflow in which the account deletion anonymises dependent data either immediately or after a retention period.

A fourth typical problem concerns password policies. By default, sf_register also accepts weak passwords, and users tend to pick short or trivial combinations. sf_register does not apply the TYPO3 password policies; its own validators check minimum length and banned words and can be extended via TypoScript with rules such as character classes, without any need to modify the extension itself.

Migration and version compatibility

sf_register comes with its own release line for each TYPO3 version, currently 13.2.4 for v13 and 14.0.2 for v14, and has a reputation in the community as a solid, maintainable alternative to femanager. Support for new versions is usually available shortly after the release of a new TYPO3 core, although custom extensions then require a review of the Extbase annotation syntax, which has seen minor adjustments between versions.

Anyone migrating from femanager to sf_register saves complexity but should check which features were actually used: femanager additionally offers backend moderation out of the box, which sf_register only replicates through additional code; both come with admin confirmation and profile picture upload. Conversely, the migration path from sf_register to femanager is easier because the data structure is largely compatible. Gosign handles these migrations including mail template porting and reconciliation of user groups, so that existing users can still log in after the switch.

Anyone setting up a new project should think through the real requirements of the portal before choosing: does the operator need backend moderation or complex role assignments? Then femanager is the faster path. Is a lean self-service registration with a clean Extbase foundation and little overhead enough? Then sf_register is the right choice. The decision is rarely close once you have gone through the catalogue of required functions once, and it saves significant rework later on.