Upgrade 

System Requirements 

The minimum requirements have been raised:

• PHP: 8.2 or higher (previously 8.1)
• TYPO3: ^14.0 (previously ^13.4)
• Symfony: ^7.0 (previously ^6.4 or ^7.0)
• New PHP extension required: ext-fileinfo (used for MIME-type validation of file uploads)

Database Update 

After updating, run the database analyser in the TYPO3 Install Tool to apply the required schema changes.

A new field tx_femanager_confirmation_required is added to the fe_users table. It stores a bitmask value for confirmation workflows:

• 0 — No confirmation required (User::CONFIRMATION_REQUIRED_NONE)
• 1 — User confirmation required (User::CONFIRMATION_REQUIRED_USER)
• 2 — Admin confirmation required (User::CONFIRMATION_REQUIRED_ADMIN)

Security: registration confirmation bypass 

This version closes a registration confirmation bypass via the "Resend Confirmation Mail" plugin. The resend plugin is a separate content element without the registration plugin's flexform, so the required confirmation can no longer be derived from the ambient settings at resend time. The workflow now reads the requirement persisted on the user in tx_femanager_confirmation_required:

• The resend action only (re)sends the user confirmation mail when the account still has an outstanding user confirmation (User::isUserConfirmationResendable()). Sites that only use admin confirmation no longer hand out a valid user confirmation link, and the user confirmation step can no longer enable an account that still needs admin approval (User::isAdminConfirmationMissing()).
• To avoid disclosing whether an account exists for a given email address, the resend form shows the same neutral message for every valid address - regardless of whether a mail was sent, nothing was pending, or no such account exists.

The same hardening applies to the profile change confirmation (Edit controller, processUpdateWorkflow): confirming, refusing or silently refusing a pending profile change is an admin action and now always requires a valid admin hash. The pre-built workflow URLs ({confirmUrl}, {refuseUrl}, {refuseSilentUrl}) already carry it, so customised UpdateRequest.html templates that use those variables need no change; only templates that build the link manually must pass the admin hash in the hash argument.

Security: usergroup privilege escalation 

This version closes a privilege escalation in the frontend usergroup selection. The registration, edit and invitation forms can render a usergroup <select>, but the frontend template is not a security boundary: a crafted request can submit any usergroup uid regardless of what the form offers, so a logged-in frontend user could assign any frontend usergroup - including privileged ones - to their own account.

The submitted usergroup relation is now validated on the server before the user is persisted, in a single place (UserGroupSanitizationService). The form is secure by default / fail closed:

• Forced groups - if settings.<form>.overrideUserGroup is set, the configured group(s) win and the submitted value is ignored (unchanged behaviour).
• Field not editable - if usergroup is not part of the configured fields, any submitted usergroup change is reverted.
• Allowlist - if settings.<form>.validation.usergroup.inList is set, the submitted uids are reduced to that list. This is the recommended way to let users choose a group.
• Opt-in for unrestricted selection - if no allowlist is configured but settings.<form>.misc.allowUnrestrictedUserGroupSelection = 1 is set, every offered group may be selected (legacy behaviour).
• Fail closed - if neither an allowlist nor the opt-in is configured, the submitted usergroup change is ignored and a log entry (Profile update not authorized) is written.

If you override Resources/Private/Partials/Fields/Usergroup.html, note that the field is now rendered depending on the new usergroupFieldMode variable (select / hidden / notice). See Securing the usergroup selection for the full description of the feature.

Custom E-Mail Templates 

Mail templates now receive pre-built absolute URLs as template variables instead of constructing action links inline. If you have customised any of the mail templates listed below, you must update them accordingly.

CreateAdminConfirmation.html

New variables: {confirmUrl}, {refuseUrl}, {refuseSilentUrl}

Old (custom template):

<f:link.action action="confirmCreateRequest" controller="New" absolute="1"
    arguments="{user:user, hash:hash, adminHash:adminHash, status:'adminConfirmation'}">

New:

<a href="{confirmUrl}">Confirm</a>

CreateUserConfirmation.html

New variables: {confirmByUserUrl}, {refuseByUserUrl}

UpdateRequest.html

New variables: {confirmUrl}, {refuseUrl}, {refuseSilentUrl}

CreateNotify.html

New variables: {refuseUrl}, {refuseSilentUrl}

<f:link.action action="registrationWorkflowDialog" controller="New" absolute="1"
    arguments="{user:user, hash:hash, workflowAction:'adminConfirmation'}">
    Confirm registration
</f:link.action>

Breaking: Confirmation Links Now Expire 

Up to femanager 13 the hash in a confirmation link was derived from the username alone, so every link sent by email stayed valid forever and could be used again at any time. The hash now carries a signed expiration date and has the format <expirationTimestamp>-<hmac>. The timestamp 0 marks a link that never expires.

The signed value is the uid of the user, the workflow step and the expiration date. Signing the uid instead of the username closes a gap: every workflow link addresses its user by uid, while usernames are not unique in TYPO3 - uniqueInDb is a femanager validation that can be switched off and that backend editors, imports and other extensions bypass. A link of one user was therefore usable for the record of a namesake. As a side effect a rename no longer invalidates the links already sent to that user; their lifetime does.

This affects the double-opt-in link, the admin confirmation and refusal links for registrations, the admin confirmation links for profile changes, and the invitation link.

The same hash format is used for the hash parameter that authorises the user detail view of the List plugin. That hash is rendered into the list view instead of being sent by mail, so it is created without a lifetime and never expires. Links to a detail view that were bookmarked or published before the update stop working, because they carry the old hash format; opening the list view again yields a working link.

Links sent before the update stop working. They use the old format and are rejected. Only registrations, profile changes and invitations that were still unconfirmed at the moment of the update are affected. Those users can request a new link themselves through the ResendConfirmationMail plugin, an administrator can resend the confirmation from the backend module, and femanager:sendUserConfirmationReminder sends a new link to everyone whose registration is still unconfirmed.

The lifetime is configured per workflow, in seconds. The default is one day:

plugin.tx_femanager {
    settings {
        new.confirmationLinkLifetime = 86400
        edit.confirmationLinkLifetime = 86400
        invitation.confirmationLinkLifetime = 86400
    }
}

Set a value to 0 to restore the previous behaviour of links that never expire.

Visitors who open an expired link get one of the new labels confirmationLinkExpired, confirmationLinkExpiredUpdate or confirmationLinkExpiredInvitation, and are guided to the resend dialog where the workflow allows it. See Expiring Confirmation Links for the full description.

Mail templates that contain a workflow link additionally receive {linkValidUntil}, so they can state how long the link works. Existing templates keep working unchanged.

Removed: In2code\Femanager\Utility\HashUtility. Use the injectable In2code\Femanager\Domain\Service\Workflow\ConfirmationHashService instead:

The suffix 'admin' is now ConfirmationHashService::SCOPE_ADMIN, the empty suffix is ConfirmationHashService::SCOPE_USER and the suffix 'show' of the user detail view is ConfirmationHashService::SCOPE_SHOW.

Unlike the removed utility the service can only sign a user that has been persisted; it throws an InvalidConfirmationHashException for a user without a uid.

AbstractFrontendController and UserBackendController take the new service as an additional constructor argument. If you extend one of them, add the argument to your constructor.

Renamed template: Resources/Private/Templates/Edit/ConfirmUpdateRequest.html is now ProcessUpdateWorkflow.html, matching the renamed action below. Without the rename the action cannot render its response.

Renamed Controller Actions 

Several controller actions involved in confirmation workflows have been renamed or replaced. If you have customised templates that use f:link.action to build workflow links, update the action and workflowAction argument values accordingly.

NewController (plugin tx_femanager_registration)

The single confirmCreateRequest action has been split into two actions to support an optional intermediate confirmation dialog:

The status argument has been replaced by workflowAction. The following values are accepted:

EditController (plugin tx_femanager_edit)

The workflowAction parameter values for update workflows are: adminConfirmation, adminConfirmationRefused, adminConfirmationRefusedSilent.

Workflow Architecture Refactoring 

The confirmation and update workflow logic has been extracted from the controllers into dedicated, injectable service classes:

• RegistrationWorkflowService — handles new user registration confirmation flows (user and admin)
• UpdateWorkflowService — handles profile update confirmation flows
• InvitationWorkflowService — handles invitation flows
• MailWorkflowLinkService — builds absolute workflow URLs using TYPO3's SiteFinder and site router

The MailWorkflowLinkService generates all workflow action URLs server-side. This is what enables femanager to build correct URLs outside of a frontend context (e.g. from the backend module or a CLI command). The plugin namespaces used for URL generation are:

• Registration: tx_femanager_registration
• Edit / update: tx_femanager_edit
• Invitation: tx_femanager_invitation

If you have extended or decorated any of these services, register the overrides in your Services.yaml.

TypoScript: New Backend Settings 

When confirmation mails are generated outside of a frontend request (e.g. from the backend module or via CLI), femanager requires explicit page UIDs to build the correct action URLs. Add the following to your TypoScript setup:

plugin.tx_femanager {
    settings {
        backend {
            workflow {
                registrationPageUid = [uid of the page containing the registration plugin]
                updatePageUid = [uid of the page containing the edit plugin]
                invitationPageUid = [uid of the page containing the invitation plugin]
            }
            pagination {
                itemsPerPage = 50
            }
        }
    }
}

JavaScript: Build process removed 

femanager now ships plain JavaScript and CSS files instead of building them with an NPM tool chain, in order to avoid the security issues that come with it.

The default TypoScript includes the files as shown below. If you include the assets yourself, use these paths:

page {
    includeCSS {
        femanagerMain = EXT:femanager/Resources/Public/Css/Main.css
    }
    includeJSFooter {
        femanagerValidation = EXT:femanager/Resources/Public/JavaScript/Validation.js
        femanager = EXT:femanager/Resources/Public/JavaScript/Femanager.js
    }
}

Removed and Deprecated TypoScript / TSconfig Options 

Removed TSconfig keys

The file Configuration/UserTsConfig/BackendModule.typoscript and its TSconfig namespace have been removed entirely. The following keys no longer have any effect:

Removed TypoScript settings

Deprecated TypoScript settings

The following setting is deprecated and will be removed in v15:

Custom Finishers 

If you have implemented custom finishers, the FinisherInterface has changed as follows:

Custom DataProcessors 

The process() method in DataProcessorInterface now requires an explicit array return type:

// Old
public function process(array $data, array $settings);

// New
public function process(array $data, array $settings): array;

Removed PHP Classes and Static Methods 

UserUtility has been removed entirely. Replace all usages with the corresponding injectable services:

BackendUtility — numerous static methods have been removed (including loadTS(), isConfirmationModuleActive(), isEnableLoginAsActive(), getConfiguration(), and others). Replace these with the corresponding TYPO3 Core APIs or injectable services.

Renamed Mail Service Classes 

The mail services have been moved into Domain/Service/Mail/ and renamed:

In addition, send() no longer takes a RequestInterface as its last argument:

// Old
public function send(string $template, array $receiver, array $sender, string $subject,
    array $variables = [], array $typoScript = [], ?RequestInterface $request = null): bool;

// New
public function send(string $template, array $receiver, array $sender, string $subject,
    array $variables = [], array $typoScript = []): bool;

If you inject one of these services, extend AbstractFluidMailService or implement MailServiceInterface, adjust the class names and the method signature accordingly.

Removed ViewHelpers 

The following ViewHelpers have been removed. If you use them in customised templates, replace them:

Changed Method Visibility 

The following methods of AbstractFrontendController are protected now and can no longer be called from outside the controller hierarchy: createAllConfirmed(), updateAllConfirmed(), updateRequest(), finalCreate() and sendCreateUserConfirmationMail().

Removed PSR-14 Event 

BeforeMailBodyRenderEvent has been removed. It was already deprecated in v13.

New Feature: Confirmation Reminder Command 

A new CLI command is available to send reminder mails to users who have not yet confirmed their registration:

vendor/bin/typo3 femanager:sendUserConfirmationReminder

The number of days before a reminder is sent can be configured (default: 7 days).

New Feature: Unified Backend Module 

The previously separate backend views have been consolidated into a single list view. Filters for confirmation status, login status, search term, and page tree depth, as well as pagination, are now integrated directly into this view.

New Feature: Custom Backend Permissions 

The backend module now supports fine-grained access control via TYPO3's custom permissions system. Four permission options are available and can be assigned per backend user group under Backend User Groups > Custom Permissions > Permissions for Backend Module "Frontend Users":

Backend admins always have access to all actions regardless of these permission settings.

Deprecation: MailServiceInterface::sendSimple() 

MailServiceInterface::sendSimple() (and its implementation in MailService) is deprecated and will be removed with femanager v15. It still works as before in v14, but triggers a deprecation notice. Use send() instead.

Note the behaviour difference: send() applies the TypoScript overrides for receiver, sender, subject, cc, replyTo, priority and attachments. If the passed values should be used as they are, do not pass these keys in the TypoScript configuration.

Custom implementations of MailServiceInterface can drop sendSimple() with v15.

Deprecation: FluidMailService and AbstractFluidMailService 

The mail logic of FluidMailService has been merged into MailService. FluidMailService and AbstractFluidMailService are no longer used by femanager, are deprecated and will be removed with femanager v15. They still work in v14, but trigger a deprecation notice when instantiated.

MailServiceInterface is now registered as an alias of MailService in the dependency injection container and the workflow services inject the interface. Migration:

• Inject In2code\Femanager\Domain\Service\Mail\MailServiceInterface instead of FluidMailService.

• Instead of extending FluidMailService or AbstractFluidMailService, implement MailServiceInterface (or extend MailService) and register your class as alias in the Services.yaml of your extension:

  In2code\Femanager\Domain\Service\Mail\MailServiceInterface:
    alias: Vendor\MyExtension\Service\MyMailService

  Copied!
• To modify the mail only, listen to BeforeMailSendEvent instead.

The $mailService property of DataController and UserBackendController is not used anymore. It is deprecated and will be removed together with the constructor argument with femanager v15. If you extend one of these controllers and use $this->mailService, inject MailServiceInterface in your own controller instead.

Deprecation: TypoScript option embedImage 

The TypoScript option embedImage of the mail configuration (e.g. plugin.tx_femanager.settings.new.email.createAdminConfirmation.embedImage) and the template variable {embedImages} are deprecated and will be removed with femanager v15.

In v14 nothing changes: the default configuration still embeds the user image into the mails createAdminConfirmation and createAdminNotify, and {embedImages.0} keeps working in own templates.

Migration: show images with <f:image>

The partial UserProperties shows the user image with <f:image> as soon as embedImage is not configured. Remove the option to switch to the new behaviour already in v14:

plugin.tx_femanager.settings.new.email.createAdminConfirmation.embedImage >
plugin.tx_femanager.settings.new.email.createAdminNotify.embedImage >

Additional images are added directly to an own mail template:

<f:image src="fileadmin/image.jpg" maxWidth="200" absolute="1" alt="" />

Note that <f:image> links the image instead of embedding it: the image must be publicly accessible, the URL must be absolute (absolute="1") and many mail clients only show external images after a confirmation of the recipient.

Migration: embed images with the BeforeMailSendEvent

Embedding images into the mail is still possible with the BeforeMailSendEvent. The mail body is rendered when the mail is sent, so a listener can embed an image and assign its cid to the template:

use In2code\Femanager\Event\BeforeMailSendEvent;
use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Core\Core\Environment;
use TYPO3\CMS\Core\Mail\FluidEmail;

#[AsEventListener(identifier: 'my-extension/mail-logo')]
final class EmbedLogoEventListener
{
    public function __invoke(BeforeMailSendEvent $event): void
    {
        $email = $event->getEmail();
        if ($email instanceof FluidEmail) {
            $email->embedFromPath(Environment::getPublicPath() . '/fileadmin/logo.png', 'logo.png', 'image/png');
            $email->assign('logo', 'cid:logo.png');
        }
    }
}

<img src="{logo}" alt="" />

Confirmation links 

New TypoScript options are added for this: new.email.createUserConfirmation.confirmUserConfirmation When enabled, a user confirming their profile creation via the email link will show a confirmation dialog beforehand. This prevents unexpected execution f.e. via Virus Scanners new.email.createUserConfirmation.confirmAdminConfirmation When enabled, an admin confirming/refusing/silently refusing someones profile creation via the email link will show a confirmation dialog beforehand This PR also includes adjustments to HashUtility allowing to specify more data while hashing a user, so that another hash can be created to prevent meddling with the admin actions (which by default is already prevented using cHashes).

For new.email.createUserConfirmation.confirmAdminConfirmation, this technically is a breaking change as template adjustments were required to pass the admin hash to the email links. If you have customized templates, please add the variable "adminHash:adminHash" to all action links in Resources/Private/Templates/Email/CreateAdminConfirmation.html

Example: old: <f:link.action action="confirmCreateRequest" controller="New" absolute="1" arguments="{user:user, hash:hash, status:'adminConfirmation'}"> new <f:link.action action="confirmCreateRequest" controller="New" absolute="1" arguments="{user:user, hash:hash, adminHash:adminHash, status:'adminConfirmation'}">

These settings are getting the default settings for V14!

Upgrade Plugins 

All Plugins used in your pages must be updated. The Updater is located in Admin Tools > Upgrade > Run Upgrade Wizard > "EXT:femanager: Migrate plugins"

TypoScript Changes 

If you use the uploading feature for avatar images, the configuration has to be changed to the combined identifier

Constants:

plugin.tx_femanager {
   settings {
      uploadFolder = 1:users/
   }
}

DataProcessors 

The DataProcessors configured under plugin.tx_femanager.settings.dataProcessors are now without a return value, if you need to change data in the request use PSR-15 Middlewares

Autologin 

Currently the AutoLogin feature does not work. When we have found a solution the feature will be enabled again, until then a link to the login page could be inserted.