---
title: "Upgrade"
manual: "Femanager"
version: "14.0"
permalink: "https://docs.typo3.org/permalink/in2code/femanager:upgrade@14.0"
source: "Upgrade/Index.rst"
rendered: "2026-11-12T07:32:53+00:00"
---

# Upgrade {#upgrade}

<!-- TODO: no Markdown rendering for "only" -->

[to version 14.0.0](https://docs.typo3.org/permalink/in2code/femanager:v14-0@14.0) | [to version 13.0.0](https://docs.typo3.org/permalink/in2code/femanager:v13-0@14.0) | [to version 8.0.0](https://docs.typo3.org/permalink/in2code/femanager:v8-0@14.0) | [to version 7.1.0](https://docs.typo3.org/permalink/in2code/femanager:v7-1@14.0) | [to version 6.0.0](https://docs.typo3.org/permalink/in2code/femanager:v6-0@14.0) | [to version 5.2.0](https://docs.typo3.org/permalink/in2code/femanager:v5-2@14.0) | [to version 5](https://docs.typo3.org/permalink/in2code/femanager:v5-0@14.0) | [to version 4.2.3 / 4.2.4 / 4.2.5](https://docs.typo3.org/permalink/in2code/femanager:v4-0@14.0) |

## to version 14.0.0 {#v14-0}

### System Requirements {#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 {#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 {#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.

> [!IMPORTANT]
> After updating, run the upgrade wizard
> **Admin Tools > Upgrade > Run Upgrade Wizard > "EXT:femanager: Migrate required confirmation for pending users"**.
> It populates `tx_femanager_confirmation_required` for accounts that were still pending at the time of
> the update. The fix does not depend on the wizard for its security: for accounts that still carry the
> default value `0` the requirement is inferred at runtime from the confirmation state
> (`User::getEffectiveConfirmationRequired()`). For the ambiguous case (a disabled account confirmed by
> neither the user nor an admin) the safe option is chosen and an admin confirmation is required; such
> accounts can always be released from the femanager backend module.

### Security: usergroup privilege escalation {#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.

> [!IMPORTANT]
> Installations that previously relied on an **unconfigured** usergroup selection (no
> `validation.usergroup.inList`) will no longer accept user-submitted usergroups by default. This is
> intentional. To keep offering a usergroup selection, configure an allowlist per form
> (`plugin.tx_femanager.settings.<new|edit|invitation>.validation.usergroup.inList = 1,2,3`) or, to
> restore the former unrestricted behaviour, set
> `plugin.tx_femanager.settings.<form>.misc.allowUnrestrictedUserGroupSelection = 1`.

If you override [`Resources/Private/Partials/Fields/Usergroup.html`](https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ExtensionArchitecture/FileStructure/Resources/Private/Index.html#file-extension-resources-private-partials-somepartials-fluid-html), note that the field is now
rendered depending on the new `usergroupFieldMode` variable (`select` / `hidden` / `notice`).
See [Securing the usergroup selection](https://docs.typo3.org/permalink/in2code/femanager:usergroupsecurity@14.0) for the full description of the feature.

### Custom E-Mail Templates {#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):

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

New:

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

**CreateUserConfirmation.html**

New variables: `{confirmByUserUrl}`, `{refuseByUserUrl}`

**UpdateRequest.html**

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

**CreateNotify.html**

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

> [!NOTE]
> You may still build workflow links manually using `f:link.action`. Use the updated action names and
> `workflowAction` parameter values described in the *Renamed Controller Actions* section below.
> Example for an admin confirmation link in `CreateAdminConfirmation.html`:
>
> ```html
> <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 {#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:

```typoscript
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](https://docs.typo3.org/permalink/in2code/femanager:confirmationlinkexpiry@14.0) 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:

| Old static method | New service method |
| --- | --- |
| `HashUtility::createHashForUser($user, $suffix)` | `ConfirmationHashService::create($user, $scope, $lifetime)` |
| `HashUtility::validHash($hash, $user, $suffix)` | `ConfirmationHashService::isValid($hash, $user, $scope)` or `validate()`, which throws `InvalidConfirmationHashException` and `ExpiredConfirmationHashException` |

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`](https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ExtensionArchitecture/FileStructure/Resources/Private/Index.html#file-extension-resources-private-templates-controllername-actionname-fluid-html) is now
`ProcessUpdateWorkflow.html`, matching the renamed action below. Without the rename the action cannot
render its response.

### Renamed Controller Actions {#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:

| Old action | New action | Purpose |
| --- | --- | --- |
| `confirmCreateRequest` | `registrationWorkflowDialog` | Shows an optional confirmation dialog before executing the workflow step (rendered when the corresponding TypoScript option is enabled) |
| `confirmCreateRequest` | `processRegistrationWorkflow` | Executes the workflow step directly, without a confirmation dialog |

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

| Workflow step | `workflowAction` value |
| --- | --- |
| User confirms registration | `userConfirmation` |
| User refuses registration | `userConfirmationRefused` |
| Admin confirms registration | `adminConfirmation` |
| Admin refuses registration | `adminConfirmationRefused` |
| Admin refuses registration silently | `adminConfirmationRefusedSilent` |

**EditController** (plugin `tx_femanager_edit`)

| Old action | New action |
| --- | --- |
| `confirmUpdateRequest` | `processUpdateWorkflow` |

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

### Workflow Architecture Refactoring {#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 {#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:

```typoscript
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 {#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:

```typoscript
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-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 TSconfig key | Replacement |
| --- | --- |
| `tx_femanager.UserBackend.confirmation.filter.userConfirmation` | No longer needed. The separate *Confirmation* backend view has been removed. Users pending confirmation are shown inline in the unified list view and can be filtered there. |
| `tx_femanager.UserBackend.confirmation.ResendUserConfirmationRequest` | Replaced by the `tx_femanager:userConfirmationReminder` backend user group permission. |
| `tx_femanager.UserBackend.enableLoginAs` | Replaced by the `tx_femanager:loginAs` backend user group permission. |

**Removed TypoScript settings**

| Removed setting | Replacement |
| --- | --- |
| `module.tx_femanager.settings.configPID` | Use `plugin.tx_femanager.settings.backend.workflow.registrationPageUid` instead. |

**Deprecated TypoScript settings**

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

| Deprecated setting | Replacement |
| --- | --- |
| `plugin.tx_femanager.settings.showResendUserConfirmationRequestView` | Use `plugin.tx_femanager.settings.backend.workflow.registrationPageUid` instead. |

### Custom Finishers {#custom-finishers}

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

| Old method signature | New method signature |
| --- | --- |
| `getSettings(): mixed` | `getTypoScriptSettings(): array` |
| `setSettings($settings)` | `setTypoScriptSettings(array $typoScriptSettings): FinisherInterface` |
| `setUser($user)` | `setUser(User $user): FinisherInterface` |
| `initializeFinisher()` | `initializeFinisher(): void` |

### Custom DataProcessors {#custom-dataprocessors}

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

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

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

### Removed PHP Classes and Static Methods {#removed-php-classes-and-static-methods}

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

| Old static method | New injectable service |
| --- | --- |
| `UserUtility::getCurrentUser()` | `UserSessionService::getCurrentUser()` |
| `UserUtility::login()` | `UserSessionService::login()` |
| `UserUtility::removeSession()` | `UserSessionService::removeSession()` |
| `UserUtility::convertPassword()` | `PasswordHashingService::convertPassword()` |
| `UserUtility::hashPassword()` | `PasswordHashingService::hashPassword()` |
| `UserUtility::getDirtyPropertiesFromUser()` | `UserDirtyPropertiesService::getDirtyPropertiesFromUser()` |
| `UserUtility::forceValues()` | `FrontendUserService::forceValues()` |
| `UserUtility::overrideUserGroup()` | `FrontendUserService::overrideUserGroup()` |
| `UserUtility::fallbackUsernameAndPassword()` | `FrontendUserService::fallbackUsernameAndPassword()` |

**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 {#renamed-mail-service-classes}

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

| Old class | New class |
| --- | --- |
| `In2code\Femanager\Domain\Service\SendMailService` | `In2code\Femanager\Domain\Service\Mail\MailService` |
| `In2code\Femanager\Domain\Service\Mail\AbstractMailService` | `In2code\Femanager\Domain\Service\Mail\AbstractFluidMailService` |
| `In2code\Femanager\Domain\Service\Mail\MailMessageService` | Removed, `FluidMailService` is the only implementation (see *drop sendMail* above) |

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

```php
// 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 {#removed-viewhelpers}

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

| Removed ViewHelper | Replacement |
| --- | --- |
| `In2code\Femanager\ViewHelpers\Condition\IsBackendAdministratorAuthenticationViewHelper` | Use the template variable `{isAdmin}`, which the backend module assigns |
| `In2code\Femanager\ViewHelpers\Be\GetClassNameOnActionViewHelper` | No replacement, the unified backend list does not need it any more |
| `In2code\Femanager\ViewHelpers\Misc\BackendEditLinkViewHelper` | Use TYPO3's `<be:uri.editRecord>` / `<be:link.editRecord>` |
| `In2code\Femanager\ViewHelpers\Misc\BackendNewLinkViewHelper` | Use TYPO3's `<be:uri.newRecord>` / `<be:link.newRecord>` |
| `In2code\Femanager\ViewHelpers\Misc\GetFirstViewHelper` | Access the first object directly (`{objects.0}`) or use `<f:first>` |
| `In2code\Femanager\ViewHelpers\Misc\RequestViewHelper` | No replacement, workflow URLs are built server-side by `MailWorkflowLinkService` |

### Changed Method Visibility {#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 {#removed-psr-14-event}

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

### New Feature: Confirmation Reminder Command {#new-feature-confirmation-reminder-command}

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

```bash
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 {#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 {#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"**:

| Permission key | Effect when granted |
| --- | --- |
| `tx_femanager:loginAs` | Shows the *Login as frontend user* button in the list view |
| `tx_femanager:logoutUser` | Shows the *Logout frontend user* button in the list view |
| `tx_femanager:adminConfirmation` | Shows the *Confirm* and *Refuse* buttons for pending admin confirmations |
| `tx_femanager:userConfirmationReminder` | Shows the *Resend confirmation reminder* button for users awaiting e-mail confirmation |

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

## to version 13.0.0 {#v13-0}

Deprecations

### Confirmation links {#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!

## to version 8.0.0 {#v8-0}

### Upgrade Plugins {#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 {#typoscript-changes}

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

**Constants:**

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

### DataProcessors {#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 {#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.

## to version 7.1.0 {#v7-1}

**Invitation Template**

If you are using customized templates for the invitation function, please check the Resources/Private/Templates/Invitation/Edit.html

You need to add

```html
<f:form.hidden name="hash" value="{hash}"/>
```

in order,that the function is working.

## to version 6.0.0 {#v6-0}

Version 6.0 support TYPO3 9 LTS and 10 LTS. The support for TYPO3 8 was dropped. No changes on Templates are needed.

**Backend Module "Frontend User" - View User Confirmation**

If you want to use the Backend Module to confirm or refuse Frontend User, you need to setup the configPID. The extension
uses now a frontend call out of the backend, to organise these actions.

```typoscript
module.tx_femanager {
    settings {
        configPID = 1
    }
}
```

## to version 5.2.0 {#v5-2}

The edit template has to be adjusted, as there is a new parameter 'token' is introduced.

Please update these partials:

`/Partials/Misc/DeleteLink.html`

The argument token was introduced.

**old:**

```html
<f:link.action
   action="delete"
   arguments="{user:user}"
   class="btn btn-warning btn-large"
   additionalAttributes="{data-confirm:'{f:translate(key:\'UserDeleteConfirmation\')}'}">
   <i class="icon-trash icon-white"></i>
   <f:translate key="deleteProfile" />
</f:link.action>
```

**new:**

```html
<f:link.action
   action="delete"
   arguments="{user:user, token:token}"
   class="btn btn-warning btn-large"
   additionalAttributes="{data-confirm:'{f:translate(key:\'UserDeleteConfirmation\')}'}">
   <i class="icon-trash icon-white"></i>
   <f:translate key="deleteProfile" />
</f:link.action>
```

`/Templates/Edit/Edit.html`

You need to add: `<f:form.hidden name="token" value="{token}" />` between the form tag.

Example:

```html
<f:form
	name="user"
	object="{user}"
	action="update"
	enctype="multipart/form-data"
	additionalAttributes="{data-femanager-plugin:data.uid}"
	class="form-horizontal {f:if(condition:'{settings.edit.validation._enable.client}',then:'feManagerValidation',else:'')}">
<fieldset>
	<legend>
		<f:translate key="titleUpdateProfile" />
	</legend>

	<f:form.hidden name="token" value="{token}" />

	more stuff here in the template file…

</f:form>
```

## to version 5 {#v5-0}

There are minor breaking changes include. Main change is, that all eid scripts were replace, by a page num approach.

In order that the js validation works, you need to take care, that you these page typenums are available:

1.  Backend Module: Login as User feature

```
feManagerLoginAs.typeNum = 1548943013

```

see the complete config in file ext_typoscript_setup.txt

1.  Frontend Validation via JS

```
feManagerLoginAs.typeNum = 1548935210

```

see the complete config in file Configuration/TypoScript/setup.ext

## to version 4.2.3 / 4.2.4 / 4.2.5 {#v4-0}

If you use your own HTML templates of new/edit/invitation-templates you should compare them with the one from
EXT:femanager. There is a new additional attribute inside the form viewhelper: data-femanager-plugin, which contains
the content element id.

If you use a modified version of the Validation.js, there are also changes: plugin and action parameter is send to
the eID-Script now