What does it do? 

Screenshots 

Changing sorting of fields 

To change the order of fields its not necessary to edit the html template. It could be either done via TypoScript (which needs administrativ rights) or by the editor alone.

For an editor its as easy as selecting the fields in the plugin and then order them in the field selection. The screenshot below shows the select field.

Screenshots 

More complex configuration 

Table of content 

Notify admin create properties 

Notify admin edit properties 

Notify user create properties 

Notify user edit properties 

Address and subject properties 

Purpose of Validators 

Validators are a mechanism to ensure that all information given by the user meet your expectation as an admin. Either if the values make sense in terms of format like emails oder in required information value like age verification.

If values need to be enforce your should use the RequiredValidator because this validator does not only check if the value of the configured field is filled but it also serves as a signal for the Required Partial to render the corresponding flag.

All validators are optional, could be set single or may be even assigned multiple times to a field. Despite the concept of extbase you are free to choose how many validators should take care of a value.

Changes since version 9.0.0 

Since version 9 validators are only used for selected fields, it's not necessary to remove validation configuration only because certain fields should not be present in the form.

In general the pattern for a validation rule is

"name", options={"parameter1": valueA, "parameter2": valueB}

The name needs to be quoted followed with a comma if options are following. Then the options with an equal sign and json notated properties and values.

Different possibilities of assigning validators 

In case you want to have no validation at all for a field was was configured by default as required you need to empty the associated validators. Look at the example given where the validators of the email gets removed.

plugin.tx_sfregister.settings.validation.create.email >

plugin.tx_sfregister.settings.validation.create.passwordRepeat = "Evoweb\SfRegister\Validation\Validator\RepeatValidator"

plugin.tx_sfregister.settings.validation.create.password {
    1 = "Evoweb\SfRegister\Validation\Validator\RequiredValidator"
    2 = "Evoweb\SfRegister\Validation\Validator\BadWordValidator"
}

plugin.tx_sfregister.settings.validation.create.password {
    1 = "Evoweb\SfRegister\Validation\Validator\RequiredValidator"
    2 = "StringLength", options={"minimum": 4, "maximum": 8}
}

plugin.tx_sfregister.settings.validation.create.password {
    1 = "Evoweb\SfRegister\Validation\Validator\RequiredValidator"
    2 = "StringLength", options={"minimum": 8, "maximum": 40}
    3 = "Evoweb\SfRegister\Validation\Validator\BadWordValidator"
}

Separate validators per process 

Each process has its own needs. While you want to have the username validated on creation, this is not needed in the edit or password change form. This could be achieved by separating the TypoScript settings in different conditions per page. But this is mostly inconvenient as you don't see what settings is met until the condition. Because of this the validation settings are split for any process.

plugin.tx_sfregister.settings.validation {
    create {
        [...]
    }
    edit {
        [...]
    }
    password {
        [...]
    }
    invite {
        [...]
    }
}

Special validators 

The UserValidator is not meant to be used for field validation. This validator is a special construct to make the configuration via TypoScript possible. All others are free to combine. If a validator is only suited for a certain field it will be mentioned in the detail configuration.

Custom validators 

You can use your own validators. Just code your validator and make it available for auto loading (either in an extbase standard path or via ext_autoload.php). Afterwards you are ready to use your validator like in the following example.

plugin.tx_sfregister.settings.validation.create.password = "Evoweb\SfRegister\Validation\Validator\RequiredValidator"

Available validators 

Beside the validators that come with extbase and which are although available in the different processes, the registration come with a set of specific ones that are tailored to the special need. The following lists all validators which are suited for the usage on fields.

Special fields Validators 

Use your own flavor of fields 

Since version 8.8.0 its easier then ever to user your own fields. Just add your partial folder via typoscript and register your own field configuration. After that you need to tell the user ts config that the new type is available to be selected in the plugin too.

plugin.tx_sfregister.view.partialRootPaths.50 = EXT:your_extension/Resources/Private/Partials/
plugin.tx_sfregister.settings.fields.configuration {
    your_field_key {
        partial = YourFieldKey
        # @see Feature: #93334 - Translation Domain Mapping
        backendLabel = your_extension.be:your_field_key
    }
}

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addUserTSConfig(
    '@import \'EXT:sf_register/Configuration/TypoScript/Fields.typoscript\''
);

@import 'EXT:sf_register/Configuration/TypoScript/Fields.typoscript'

By using the same fields file both in typoscript as well as in user ts config. No additional configuration is needed.

In your partials there are the following information available

• {user} the user object with previous entered values
• {fieldName} the name of the field in the user object
• {options} every value that is inside of the field config {partial, backendLabel, etc}
• {settings} the general plugin settings

Adding custom properties 

Since late the frontend user domain model can be extended. This can be done the extension evoweb/extender which sole purpose is to extend extbase domain models. There is an example on how to use the extender.

If you run into problems extending please be aware that the only solution supported is by the use of 'extender'.

In this example its noteworthy that the last array key is not required but advised. The path to the file matches extension key and extbase compatible path to the domain model.

For highlighting purpose its advised to let the domain model extend from \Evoweb\SfRegister\Domain\Model\FrontendUser

$GLOBALS['TYPO3_CONF_VARS']['EXTENSIONS']['sf_register']['extender'][
    \Evoweb\SfRegister\Domain\Model\FrontendUser::class
]['site-package'] = 'EXT:site_package/Classes/Domain/Model/FrontendUser.php';

Beside extending the domain model with property and get-/set-method a field needs to be created for sql and registered in TCA.

#
# Table structure for table 'fe_users'
#
CREATE TABLE fe_users (
    extending varchar(60) DEFAULT ''
);

$temporaryColumns = [
    'extending' => [
        'exclude' => 1,
        'label' => 'extending',
        'config' => [
            'type' => 'input',
            'readOnly' => TRUE,
        ],
    ],
];

\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTCAcolumns('fe_users', $temporaryColumns, 1);
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addToAllTCAtypes('fe_users', 'extending');

Bring in your own captcha 

By implementing a adapter which is extending the \Evoweb\SfRegister\Services\Captcha\AbstractAdapter you are able to add an own captcha. The adapter now then has to be configured to be usable by adding typoscript settings like the following taken from recaptcha:

plugin.tx_sfregister.settings {
    # register recaptcha as captcha possibility
    captcha.recaptcha = Evoweb\Recaptcha\Adapter\SfRegisterAdapter

    fields {
        configuration {
            # change captcha field type to recaptcha
            captcha.type = Recaptcha
        }
    }

    validation.create {
        # tell validation to use recaptcha adapter
        captcha = Evoweb\SfRegister\Validation\Validator\CaptchaValidator(type = recaptcha)
    }
}

PSR-14 Events 

This kind of event is superseding Hooks and Signal-Slots in TYPO3 and are the way to go. That's why all signals are replaced with their event counterparts.

How to implement a slot 

An overview on how to configure and interact with events was given on the Developer Days in 2019. The detailed example shows how to configure them in the Services.yaml:

use Evoweb\SfRegister\Controller\Event\ProcessInitializeActionEvent;
use TYPO3\CMS\Core\Attribute\AsEventListener;

class YourEventListener
{
    #[AsEventListener('your-extension-identifier', ProcessInitializeActionEvent::class)]
    public function __invoke(ProcessInitializeActionEvent $event): void
    {
    }
}

The code above shows how to get an event listener is registered to an event.

Available events 

Template for dynamic fields 

Since version 8.8.0 the forms are rendered by partials. Create and Edit form fields are defined in typoscript or selected in the plugin and then rendered by a loop which calls the configured partial per field.

This was made to be able to only change one field alone through modifying the partial.

Additionally its now possible to select the fields needed in the content instead the need to add typoscript for the one page where the registration should be different.

As its not always needed to define your field selection there are some defaults configured out of the box.

plugin.tx_sfregister.settings.fields.defaultSelected {
    create { }
    edit { }
}

Word of advise to those that upgrade an existing installation. To make use of this feature in your old templates you need to replace all <div> tags between the form tags with the loop.

<f:for each="{settings.fields.selected}" as="selectedField">
    <f:alias map="{options: '{settings.fields.configuration.{selectedField}}'}">
        <f:render
            partial="Form/{options.partial}"
            arguments="{
                user: user,
                fieldName: selectedField,
                options: options,
                settings: settings
            }"/>
    </f:alias>
</f:for>

Customize the output 

Per default, all templates are stored in typo3conf/ext/sf_register/Resources/Private/

Copy files you want to modify of the folder into the fileadmin. Don't forget to set the path to this new templates folder with.

Since TYPO3 6.2 its possible to have so called fallback paths for template, partial and layout root paths. By this its not necessary to copy all files of given path any more.

plugin.tx_sfregister.view.templateRootPaths.0 = EXT:sf_register/Resources/Private/Templates/
plugin.tx_sfregister.view.templateRootPaths.1 = EXT:example/Resources/Private/Templates/sf_register/

plugin.tx_sfregister.view.partialRootPaths.0 = EXT:sf_register/Resources/Private/Partials/
plugin.tx_sfregister.view.partialRootPaths.1 = EXT:example/Resources/Private/Templates/sf_register/Partials/

plugin.tx_sfregister.view.layoutRootPaths.0 = EXT:sf_register/Resources/Private/Layouts/
plugin.tx_sfregister.view.layoutRootPaths.1 = EXT:example/Resources/Private/Templates/sf_register/Layouts/

In pre and post TYPO3 6.2 version its possible to define a template rootpath in the registration plugin. This gets add/set to the view and used for rendering.

Viewhelper for templates 

Birthdate with three select boxes 

<register:form.rangeSelect start="1" end="31" property="dateOfBirthDay"/>
-
<register:form.rangeSelect start="1" end="12" property="dateOfBirthMonth"/>
-
<register:form.rangeSelect start="1960" end="2011" property="dateOfBirthYear"/>

Copied!

Single select with radio buttons 

<f:form.radio property="gender" value="1"/> <f:translate key="gender_1"/>
<f:form.radio property="gender" value="2"/> <f:translate key="gender_2"/>

Copied!

Single select as select box 

<f:form.select property="gender" options="{
    1: '{f:translate(key: \'gender_1\')}',
    2: '{f:translate(key: \'gender_2\')}'
}"/>

Copied!

<f:render partial="required" arguments="{field: 'gender'}"/>

How to setup different registration processes? 

It is possible to have simple registrations like directly activated user accounts as well as complex ones like double optin confirmations with admin acceptance. So if its possible to have different approaches how to set them up?

Possible actions 

The following diagram displays which actions are necessary for a successful registration. Some of them are optional like the confirmation and activation. Some are mandatory to get a valid user to login with.

Screenshots: 

2025.12.09 

With version 13 site sets with own settings $evoweb.sf-register.settings.* were introduced. These should have override TypoScript constants.

This concept is now discarded in favor for $plugin.tx_sfregister.settings.* which is now also used in the siteSets. Please be aware and migrate them. Most likely its replacing evoweb.sf-register with plugin.tx_sfregister.

2025.01.10 

The breaking change of 2019.01.13 is reverted. Since commit d10e1bc the shorthand notation for validators got deprecated and will be removed in 14.0. So now you need to use the fully qualified classname again.

Required validator:

"Evoweb.SfRegister:Required"

Evoweb\SfRegister\Validation\Validator\RequiredValidator

2024.10.24 

Replace TypoScript condition and plugin.tx_sfregister.settings.minified value with \Evoweb\SfRegister\ViewHelpers\ApplicationContextViewHelper.

Environments are matched with Expression Languages and allow values like:

• Development
• Testing
• Production
• Production/*
• Production/Staging

By this one TypoScript condition less gets used, which improves cacheability of pages.

2024.10.23 

The new content element wizards are now not auto registered. If you use one of the two provided SiteSets, the wizards are available in the related tree.

If you use a page tree without a SiteSet, the wizards can be included in the the root page with the page field "Page TSconfig" by selecting the "[Frontend user registration] New content element wizards".

2024.10.22 

Since TYPO3 13.x list_type is deprecated. A upgrade task is provided to convert the plugins from list_type to CType rendering.

2024.10.18 

• Rename password meter with ID sfrpassword to sfrPassword
• Fallback for password element <meter> is not supported anymore.

2024.08.31 

• Extract the modification of the validators to ModifyValidator service. It's still configured the same (via TypoScript) but is handled via service outside of the controller.
• Replace $controller->controller with $controller->getControllerName()
• Move change usergroup to FrontendUserGroup service
• Without injecting FrontenUserGroup into other controller, changing usergroup is only supported in FeuserCreateController.
• Move getLoggedInUserId, getLoggedInUser, determineFrontendUser, userIsLoggedIn, autoLogin and redirectToPage to FrontendUser service
• Remove access on context in controller and move it to FrontendUser service

2024.08.26 

Replace SelectStaticCountriesViewHelper with f:form.countrySelect to decouple from EXT:static_info_tables if you only relay on selecting countries.

2024.05.13 

The registration of fields for the field selection in the content elements was moved from ext_localconf.php to user.tsconfig. The consequence is, that extending/overriding fields requires to order the loading of extensions. To achieve this, you need to require sf_register in your composer.json and ext_emconf.php

2022.01.01 

Interface EvowebSfRegisterInterfaceFrontendUserInterface is renamed to EvowebSfRegisterDomainModelFrontendUserInterface

2021.12.31 

Validator configuration is changed. As long as your custom validator has no injected classes like repository or likewise, you do not need to change anything.

If you need something in your validator, you need to use to constructor injection, add an implements of InjectableInterface, make the validator a public service via Services.yaml and need have a way to get the options set. Options can be set by your own method or by using the AbstractValidator of sf_register.

So if you need a class in your validator in code this changes are needed: Add your validator to Services.yaml: Add implements InjectableInterface to your validator Use `\Evoweb\SfRegister\Validation\Validator\AbstractValidator` as validator base Add the repository in constructor

Evoweb\SfRegister\Validation\Validator\UniqueValidator:
  public: true

use Evoweb\SfRegister\Validation\Validator\AbstractValidator;
use Evoweb\SfRegister\Validation\Validator\InjectableInterface;

class UniqueValidator extends AbstractValidator implements InjectableInterface, ...

public function __construct(FrontendUserRepository $userRepository)
{
   $this->userRepository = $userRepository;
}

2020.04.29 

The hole extension was refactored to make best usage of TYPO3 10 changes. Namely

• constructor DI
• exchange Signal/Slot dispatcher with PSR-14 events, have a look in extendability at PSR-14 events
• refactor to fully match the PSR-12 standard
• rename TypoScript setting processInitializeActionSignal to processInitializeActionEvent
• rename TypoScript setting redirectSignal. to redirectEvent.
• reorganize TypoScript setting createDefaultSelected etc to defaultSelected.create etc
• reorganize TypoScript notifyUser and notifyAdmin setup and constants to notifyUser. and notifyAdmin.
• modify Mail service to have better controller and action assignment
• replace switchableControllerActions with individual plugin per controller check what elements with list_type sfregister_form are present in table tt_content and replace them with their corresponding new plugin
• change how TS names, templates, mail subject and PSR-14 event name are build based on controller and action name in combination with notifyAdmin and notifyUser TS name is build notifyAdmin.{ControllerName}{ActionName} notifyAdmin.createSave Template name is build NotifyAdmin{ControllerName}{ActionName} NotifyAdminCreateSave Mail subject is build subjectNotifyAdmin{ControllerName}{ActionName} subjectNotifyAdminCreateSave Event name is build NotifyAdmin{ControllerName}{ActionName}Event NotifyAdminCreateSaveEvent PostCreateSave replaced with CreateSave PostCreateConfirm replaced with CreateConfirm PostCreateRefuse replaced with CreateRefuse PostCreateAccept replaced with CreateAccept PostCreateDecline replaced with CreateDecline PostDeleteSave replaced with DeleteSave PostDeleteConfirm replaced with DeleteConfirm PostEditSave replaced with EditSave PostEditConfirm replaced with EditConfirm PostEditAccept replaced with EditAccept SendInvitation replaced with InviteInvite PostResendMail replaced with ResendMail

2019.02.03 

Drop custom form styles in favor for Bootstrap 4.2 styles. Be aware, to get the styles.css from older releases if you depend on it. If you use the Bootstrap 4.2 form styles you are good to go.

2019.02.02 

The password strength meter got replaced with the <meter> element. If you still need the old iframe variant for old browser or for the looks, please override the file EXT:sf_register/Resources/Private/Partials/Form/Password.html in your sitepackage and replace

<iframe id="bargraph" frameborder="none" scrolling="no"
    src="/typo3conf/ext/sf_register/Resources/Public/Images/progressbar.svg"></iframe>

<meter min="0" low="20" optimum="30" high="40" max="50" id="bargraph"></meter>

2019.01.17 

The core changed away from saltedpasswords towards integrated passwordHashing in EXT:Core (see Deprecation: #85804 - Salted password hash class deprecations)

By this its always possible to properly hash passwords.

Due to this shift the support for md5 and sha1 configuration is dropped in EqualCurrentPasswordValidator::isValid and FeuserController::encryptPassword.

2015.11.15 

• Method changeUsergroup got pulled up from FeuserCreateController to FeuserController. If a controller extends FeuserCreateController the change in changeUsergroup needs to be copied.
• Method changeUsergroup got the parameter $usergroupIdToBeRemoved removed. This is because all known usergroups previously set get removed now. So only the $user and $usergroupIdToAdd need to be provided. All usage of this method needs to be changed accordingly.
• Drop mailhash, setMailhash() and getMailhash() from frontend user model as it was deprecated since 2014.