Which fields can be edited 

Which profile fields the editing forms offer, which are mandatory and which are locked is not configured in this extension. It comes from the validation settings shipped by academic_persons, in Configuration/AcademicPersons/Settings.yaml, which the editing forms read directly.

Consequences worth knowing before reporting a problem:

• A field configured disabled or readonly is rendered locked, and a value submitted for it anyway is discarded rather than stored. This is deliberate and protects already stored data.
• First name, Middle name and Last name are locked by default, because profile names are usually owned by the connected frontend user record and synchronised from elsewhere. They are therefore not editable in the frontend form — and, since the same configuration also drives the backend, not in the TYPO3 record editor either.
• Because both editing contexts share one configuration, unlocking a field for the frontend form also unlocks it in the backend.

See Validation settings in the academic_persons manual for the available flags, the shipped defaults and how to override them.

Image processing: WebP 

The profile detail view of the profile editing plugin offers the profile image as WebP through the <picture> candidates, with the <img> fallback in the source format. TYPO3 has to be allowed to produce WebP, otherwise rendering a profile that has an image fails with:

Unable to render image uri in "tt_content:1": The extension webp is not
specified in $GLOBALS['TYPO3_CONF_VARS']['GFX']['imagefile_ext'] as a valid
image file extension and can not be processed.

On TYPO3 v13 and v14 webp is part of the default value of $GLOBALS['TYPO3_CONF_VARS']['GFX']['imagefile_ext'] , so nothing has to be done. An installation that removes it from that list - some restrict the allowed formats deliberately - has to put it back, either in Admin Tools > Settings > Configure Installation-Wide Options > [GFX][imagefile_ext] or in config/system/settings.php.

Permitting the format is not the same as being able to produce it: the configured image processor, GraphicsMagick or ImageMagick, has to be built with WebP support.

Change the templates using TypoScript constants 

As any Extbase based extension, you can find the templates in the directory Resources/Private/.

If you want to change a template, copy the desired files to the directory where you store the templates.

We suggest that you use a sitepackage extension. Learn how to Create a sitepackage extension.

# TypoScript constants
plugin.tx_academicpersonsedit {
    view {
        templateRootPath = EXT:mysitepackage/Resources/Private/Extensions/myextension/Templates/
        partialRootPath = EXT:mysitepackage/Resources/Private/Extensions/myextension/Partials/
        layoutRootPath = EXT:mysitepackage/Resources/Private/Extensions/myextension/Layouts/
    }
}

Also available 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

Version 3.0 changes Fluid templates and partials that EXT:academic_persons_edit ships for its frontend editing plugin. They are shipped files, not API, and an installation that overrides one of them keeps its own copy — and therefore does not receive the change.

This page collects all of those changes for 3.0 in one place. It is extended whenever another shipped Fluid file is adapted.

<f:if condition="{image.properties.show_copyright} && {image.properties.copyright}">
    <span class="copyright">&copy; {image.properties.copyright}</span>
</f:if>

Impact 

Installations that override any of the listed Fluid files keep the behaviour of their own copy:

• an overridden Profile/Show.html continues to offer no replace link, so the replacement handling of addImageAction() stays unreachable through the user interface,
• an overridden Profile/EditImage.html does not show the image being replaced,
• an overridden Profile/Show/Image.html continues to offer no format fallback for the profile image, and keeps its copy of the copyright block — which renders nothing there either.

Nothing breaks at runtime — the overrides keep working. What is lost is the new behaviour.

Affected Installations 

All installations using the EXT:academic_persons_edit extension that override the profile detail template, the profile image form template or the profile image partial.

Migration 

Re-apply the project specific overrides on top of the updated files.

Description 

The script configuring the CKEditor instances of the frontend form is now compiled from a TypeScript source and is an ES module:

EXT:academic_persons_edit/Resources/Public/JavaScript/CKEditor.js
->  EXT:academic_persons_edit/Resources/Public/JavaScript/frontend/ckeditor.js

It is registered in Configuration/JavaScriptModules.php and addressed by the bare specifier @fgtclb/academic-persons-edit/frontend/ckeditor.js.

CKEditor itself is still loaded from a content delivery network by the same template, unchanged.

Impact 

An installation that uses the shipped template needs to do nothing.

An installation that references the old path loads a file that no longer exists, and the rich text fields fall back to plain textareas.

Affected installations 

Installations that override Templates/Profile/Edit.html or reference CKEditor.js from their own site package.

Migration 

In an overridden template, replace the reference:

<f:asset.module identifier="@fgtclb/academic-persons-edit/frontend/ckeditor.js" />

<f:asset.script> cannot be used any more, because a classic script tag does not execute an ES module. The ckeditor-config identifier and the async / defer attributes are gone with it: a module is deferred by definition.

Description 

TYPO3 v14 removed the tt_content sub-type feature (the list_type column) and changed ExtensionManagementUtility::addPlugin() accordingly. The academic plugins have been registered as first-class content elements (CType) since the 2.1 version line (see the 2.1 breaking note about migrating from list_type to CType); for TYPO3 v14 support the internal registration was adapted to the new addPlugin() signature and the vestigial list_type handling was dropped.

Impact 

On TYPO3 v14 the tt_content.list_type column no longer exists. Any content records still stored as CType=list with a list_type of one of the plugins below will no longer resolve, and custom TypoScript, TSconfig, page TSconfig or SQL that references list_type for these plugins stops working.

The change relates to the following plugins:

• academicpersonsedit_profileediting
• academicpersonsedit_profileswitcher

Affected Installations 

Installations that upgrade to TYPO3 v14 and still hold content elements stored as CType=list + list_type=<plugin>, or that reference list_type for these plugins in their own configuration.

Migration 

Run the provided upgrade wizard academicPersonsEdit_pluginContent before upgrading to TYPO3 v14 (it requires the list_type column, which v14 removes) to migrate the tt_content records to the dedicated CType values. Update any custom configuration referencing list_type to match on CType instead.

Description 

Support for TYPO3 v12 has been removed for the 3.x version line, based on the dual TYPO3 core version support per major version of the academic extensions support matrix.

This includes removing build, test and configuration parts only required for TYPO3 v12. Version specific code paths are dropped in a dedicated step.

Impact 

TYPO3 v12 or older instances can no longer install or update to the 3.x version of the academic extensions and are required to upgrade TYPO3 first.

The extension cannot be installed on TYPO3 v12 anymore but does not break otherwise.

Affected installations 

All installations using an academic extension on TYPO3 v12 that want to upgrade to the 3.x version line.

Migration 

Upgrade the TYPO3 installation to a supported version (TYPO3 v13) beforehand or within the same upgrade step.

Description 

The profile detail view of the frontend editing plugin of EXT:academic_persons_edit now offers a "Replace" action for a profile that already has an image, next to the existing "Delete" action.

Replacing an image previously meant deleting it first and uploading a new one afterwards. Between those two steps the profile had no image at all, and the old file was already gone before the replacement was known to be valid — an upload rejected by the file size or mime type validation left the profile without an image.

The replacement itself is not new. The migration to the native Extbase file upload handling (Important: Profile image upload uses native Extbase upload handling) already implemented it completely: the upload configuration permits the already referenced file plus the upload, the previously referenced file is determined before the upload rewires the relation, and it is deleted afterwards — but only when no other record still references it. None of that could be reached from the shipped templates, because the link to the upload form was rendered only while the profile had no image.

The form the "Replace" action leads to now also renders the image that is about to be replaced.

Impact 

Profile owners using the EXT:academic_persons_edit frontend editing can exchange a profile image in a single step. The profile keeps its current image until the replacement passed validation, and the replaced file is removed from the storage unless another record still uses it.

Affected Installations 

All installations using the EXT:academic_persons_edit extension starting with version 3.0.

Migration 

No migration is required for installations using the shipped templates.

Installations overriding Resources/Private/Templates/Profile/Show.html have to re-apply their override on top of the updated template to offer the action, see Breaking: Adapted frontend editing Fluid files.

Description 

The profile image upload of the academicpersonsedit_profileediting plugin was handled by the custom type converter FGTCLB\AcademicBase\Extbase\Property\TypeConverter\FileUploadConverter (EXT:academic_base). It has been replaced with the native Extbase file upload handling introduced in TYPO3 v13.3 (FileUploadConfiguration, see TYPO3 feature forge#103511).

The TypoScript configuration is unchanged. settings.editForm.profileImage.targetFolder, settings.editForm.profileImage.validation.maxFileSize and settings.editForm.profileImage.validation.allowedMimeTypes keep their names and meaning and are now mapped onto the core FileSizeValidator and MimeTypeValidator. The form template, the Profile domain model and the plugin itself are untouched, so no integration or template change is required.

Impact 

The upload behaves differently in four ways:

• Stored file names change. The custom converter built the file name from the profile data as <firstname>-<lastname>-<uid>.<extension> and replaced an existing file of that name. The native handling keeps the name supplied by the client, appends a random suffix and renames on conflict instead. Stored names therefore no longer contain the name of the person, which is an improvement for a folder that is usually reachable over the web.
• The previous image is deleted on re-upload. Because the generated name changed on every upload, replacing an image would leave the previous file behind. Uploading a new profile image now deletes the file the profile referenced before, unless it is still referenced by another record.
• The mime type is detected from the file content. The custom converter trusted the media type sent by the browser, which can be spoofed. The core MimeTypeValidator inspects the uploaded file itself and additionally cross-checks the file extension. An upload whose real content does not match an allowed mime type is now rejected, even if the browser announced an allowed one. Uploads that only passed because of a faked header stop working — this is intended.
• The file is only stored once the whole model validates. Previously the file was imported into FAL while mapping the request, so an upload that failed validation afterwards left an unreferenced file behind in the upload folder. The file is now imported after successful validation, which avoids those orphaned files but requires the editor to select the file again when the form is redisplayed with validation errors.

An empty allowedMimeTypes setting continues to mean "no mime type restriction".

Affected Installations 

Installations using the profile editing plugin (academicpersonsedit_profileediting) with profile image uploads. Installations that rely on the stored file name — for example when referencing those files by a fixed path outside of FAL, or when addressing them by the person's name — need to review that assumption.

Migration 

No configuration change is required. Files uploaded before this change keep their existing names and references, and are deleted as soon as the corresponding profile image is replaced.

Description 

TYPO3 v14 rewrote the header partial of EXT:fluid_styled_content. Where v13 Header/All.html reads {data.header}, the v14 Header/All.fluid.html renders header and subheader with {record -> f:render.text(...)}, and that ViewHelper requires a record object.

Content elements based on lib.contentElement receive that record from the record-transformation data processor, but an Extbase plugin view assigns only the data array. Templates of this extension render the shared header partial, so on TYPO3 v14 they aborted with

The record argument must be an instance of ... Given: null

The plugin controllers now assign an additional record view variable, built from the tt_content row of the current content element. TYPO3 v13 ignores it, its header partial keeps reading data, so one implementation serves both core versions.

Impact 

The affected plugins render again on TYPO3 v14. Nothing was removed or renamed, so no configuration or template override needs to be adapted.

Custom templates and template overrides may use the new {record} variable, for example with <f:render.text record="{record}" field="header" />.

Affected Installations 

Installations running the plugins of this extension on TYPO3 v14. TYPO3 v13 installations are unaffected.

Migration 

None required.

Description 

Removing the profile image in the academicpersonsedit_profileediting plugin deleted the image file, but never wrote the profile record afterwards. TYPO3 removes the file index entry and its file references when a file is deleted, so the reference itself disappeared — but the reference count stored in tx_academicpersons_domain_model_profile.image kept its previous value.

FGTCLB\AcademicPersonsEdit\Controller\ProfileController::removeImageAction() now drops the relation through Extbase before touching the file, so the record and its references stay consistent.

The same action deleted the file unconditionally. It now checks whether any other record still references the file and keeps it in that case, which is how addImageAction() has treated the file it replaces since the migration to the native Extbase upload handling.

Impact 

• The profile record no longer reports a profile image after the image was removed. Code reading the column directly instead of resolving the relation — raw queries, exports, integrity checks — saw a profile image that did not exist. The frontend was not affected, because it resolves the relation.
• A file that another record still references is no longer deleted. Removing a profile image previously deleted the file for every record using it, leaving those records pointing at a missing file.

Affected Installations 

Installations using the profile editing plugin (academicpersonsedit_profileediting) whose editors remove profile images.

Migration 

No configuration change is required.

Profile records that were left with a stale image count keep it until the record is written again — editing and saving the profile in the backend or through the plugin recalculates the value. The stale count has no effect on rendering.

Breaking Changes 

Features 

Deprecations 

Important notes 

Also available 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

To support showing and hiding contact records in the frontend (see Feature: Show and hide contact records in the frontend editing), the frontend editing templates and partials rendering the contact records of a contract were changed.

The following Fluid files were modified:

• Resources/Private/Templates/Contract/Show.html
• Resources/Private/Partials/Profile/List/PhysicalAddresses.html
• Resources/Private/Partials/Profile/List/EmailAddresses.html
• Resources/Private/Partials/Profile/List/PhoneNumbers.html

The relevant changes are:

• The list partials no longer iterate the contract relation ({contract.physicalAddresses}, {contract.emailAddresses}, {contract.phoneNumbers}). They now iterate dedicated variables ({physicalAddresses}, {emailAddresses}, {phoneNumbers}) assigned by the controller, which also contain hidden records.
• Contract/Show.html passes these new variables to the partials.
• Each row gained a show/hide toggle and a "Hidden" badge, and the remaining row actions are only rendered for visible records.

Impact 

Installations that override or extend any of these templates or partials for project specific styling will not show the new show/hide functionality and may not list hidden records, until the overrides are adapted.

Affected Installations 

All installations using the EXT:academic_persons_edit extension that override the contract show template or the contact record list partials.

Migration 

Re-apply the project specific overrides on top of the updated templates and partials: switch the list iterations to the new {physicalAddresses}, {emailAddresses} and {phoneNumbers} variables and integrate the new show/hide toggle column.

Description 

The content element academicpersonsedit_profileswitcher is no longer registered. It cannot be selected any more, and the content elements that still use it are removed by an upgrade wizard.

This is a cleanup that was missed in 2.1, not a change of behaviour.

Impact 

The content element cannot be selected any more, and existing elements of it are deleted by the upgrade wizard.

No rendered output changes. These elements have rendered nothing since 2.1, on every page they sit on, so removing them cannot change what a visitor sees. What changes is the backend: the type is gone from the content element type list, and any element the wizard has not deleted yet is shown with an "INVALID VALUE" badge in the page module instead of looking like a working plugin.

Affected Installations 

All installations using the EXT:academic_persons_edit extension that still have content elements of the profile switcher plugin — either as CType or as a legacy list_type record.

Installations that never used the plugin are not affected. The upgrade wizard reports nothing to do for them.

Migration 

Run the upgrade wizard in the Install Tool, or on the command line:

vendor/bin/typo3 upgrade:run academicPersonsEdit_removeProfileSwitcherContent

To see which records are affected before running it:

SELECT uid, pid, header, CType FROM tt_content
 WHERE deleted = 0 AND CType = 'academicpersonsedit_profileswitcher';

-- TYPO3 v13 and below, for records that were never migrated:
SELECT uid, pid, header, CType, list_type FROM tt_content
 WHERE deleted = 0 AND CType = 'list'
   AND list_type = 'academicpersonsedit_profileswitcher';

There is no replacement to migrate to. The profile editing plugin lists all profiles of the logged in user by itself, which is what the switcher was there for.

Description 

Profile owners can now control which of their contact records are displayed on the public profile directly from the frontend editing plugin of EXT:academic_persons_edit.

For each physical address, email address and phone number a new "show"/"hide" toggle is available in the contract editing view. Hiding a record sets the standard TYPO3 hidden enable field on the record, which removes it from the public profile display while keeping the data intact.

The frontend editing list always shows hidden records (marked with a "Hidden" badge) so that they can be made visible again at any time. The other actions (view, edit, sort, delete) are only offered for visible records — a hidden record has to be shown again before it can be edited.

Records created and updated by the profile synchronization (EXT:academic_persons create/update profile commands) can be hidden as well: the synchronization keeps updating their data, but no longer changes their visibility once a profile owner has decided to hide them.

Impact 

Profile owners using the EXT:academic_persons_edit frontend editing gain fine-grained control over the visibility of their:

• physical addresses
• email addresses
• phone numbers

without having to delete records they only want to hide temporarily.

Affected Installations 

All installations using the EXT:academic_persons_edit extension starting with version 2.4.

Migration 

No migration is required. Existing records keep their current visibility (they are visible unless they were already hidden in the backend). The new toggle can be used immediately.

Description 

Resources/Private/Partials/Profile/Show/Image.html read the image metadata from a view variable image that is never assigned. The profile detail view of the academicpersonsedit_profileediting plugin therefore never rendered the caption, and it emitted an empty alt and title attribute even when the file carried that metadata.

The profile carries a TYPO3CMSExtbaseDomainModelFileReference, and that class exposes nothing but getOriginalResource(). Every other property path on it resolves to null — which is why {profile.image.alternative} was as empty as {image.description}. All values are now read through originalResource:

<!-- before -->
<img alt="{profile.image.alternative}" title="{profile.image.title}">
<f:if condition="{image.description}">
    <figcaption class="visually-hidden">{image.description}</figcaption>
</f:if>

<!-- after -->
<img alt="{profile.image.originalResource.alternative}"
     title="{profile.image.originalResource.title}">
<f:if condition="{profile.image.originalResource.description}">
    <figcaption class="visually-hidden">{profile.image.originalResource.description}</figcaption>
</f:if>

The same partial rendered a copyright, which never worked either and was removed instead of repaired — see Breaking: Adapted frontend editing Fluid files.

Impact 

The profile detail view of the frontend editing plugin now renders

• the alt and title attribute of the profile image from the file metadata instead of always empty,
• a figcaption when the image has a description.

Note that nothing in this extension writes image metadata — an image uploaded through the plugin has none until it is maintained in the backend. Installations that never maintained the metadata of their profile images therefore see no change in the rendered output.

Affected Installations 

Installations using the academicpersonsedit_profileediting plugin, and any installation overriding Partials/Profile/Show/Image.html.

Migration 

No configuration change is required.

Installations that override the partial keep their own copy and stay unaffected — including its defect. Adopt the property paths above to render the metadata.

Description 

The frontend editing of EXT:academic_persons_edit maps submitted form data transfer objects ( \FGTCLB\AcademicPersonsEdit\Domain\Model\Dto\AbstractFormData descendants) onto the domain models through the per-property factory classes in \FGTCLB\AcademicPersonsEdit\Domain\Factory\* .

Until now these factories wrote every property on each request, so a field that was not part of the submitted form was silently overwritten with the empty default of the form data object, wiping already persisted data. This is corrected: a property is now only applied when it was actually sent within the current request.

To make this possible the following additions were made (all of them on @internal classes that are not part of the public API):

• \FGTCLB\AcademicPersonsEdit\Domain\Model\Dto\AbstractFormData carries the current request and the mapped argument name and exposes wasPropertySentInRequest(string $propertyName): bool to detect which properties were part of the submission. The request and argument name are provided by the new \FGTCLB\AcademicPersonsEdit\Property\TypeConverter\AbstractFormDataConverter , which is registered for all AbstractFormData based arguments in \FGTCLB\AcademicPersonsEdit\Controller\AbstractActionController::initializeAction() .
• All factory classes (Profile, ProfileInformation, Contract, Address, Email, PhoneNumber) skip properties that were neither sent within the request nor registered as override. The existing readOnly / disabled validation configuration keeps precedence and continues to protect persisted data.
• For the case where a property is not part of the request but still has to be written - for example when a PSR-14 event fills up data from another source before the transformation runs - AbstractFormData gained a per-property override store via setPropertyOverride(string $propertyName, mixed $value) , hasPropertyOverride(string $propertyName) and getPropertyOverride(string $propertyName) . Registered overrides are applied even when the property was not submitted.

Additionally \FGTCLB\AcademicPersonsEdit\Domain\Factory\ContractFactory::setValidTo() was fixed to evaluate the validation configuration of validTo instead of validFrom.

Impact 

The runtime behaviour of the frontend edit forms changes: submitting a form no longer resets fields that are not contained in that form. Fields are only written when they were part of the request or were explicitly registered as override on the form data object. No public method signature changed in an incompatible way.

Affected Installations 

Only installations that extend or replace the internal form data factory classes or AbstractFormData , or that relied on the previous "always overwrite" behaviour of the transformation, need to take the changed behaviour into account. All other installations benefit from the fix without any action required.

Migration 

No explicit migration is required. Custom code that populates a form data object outside of the request (e.g. within a PSR-14 event) and expects the value to be persisted must register it via AbstractFormData::setPropertyOverride() so the transformation applies it despite the property not being part of the request.

Breaking Changes 

Features 

Deprecation 

Important 

Description 

Profile related lists now provide additional actions to quickly move entries directly to the first or last position without having to step through them item by item. This applies to contracts and profile information on a profile as well as email addresses, phone numbers and physical addresses on a contract.

Instead of only being able to move an item one step up or down, editors can now use dedicated "move to top" and "move to bottom" actions to rearrange the order of items more efficiently. The sorting values of affected records are normalized while reordering to keep a clean, strictly increasing sorting sequence.

Impact 

Editors working with the EXT:academic_persons_edit extension gain more convenient tools for managing the order of:

• profile contracts
• profile information
• contract email addresses
• contract phone numbers
• contract physical addresses

The new options reduce the number of clicks required to bring a record to the top or bottom of a list and make it easier to maintain a stable and predictable display order.

Affected Installations 

All installations using the EXT:academic_persons_edit extension starting with version 2.3.

Migration 

No explicit migration is required. Existing records keep their current order and sorting values. The new actions can be used immediately to rearrange items as needed and will normalize sorting values on change.

Description 

Profile related lists now provide additional actions to quickly move entries directly to the first or last position without having to step through them item by item. This applies to contracts and profile information on a profile as well as email addresses, phone numbers and physical addresses on a contract.

Instead of only being able to move an item one step up or down, editors can now use dedicated "move to top" and "move to bottom" actions to rearrange the order of items more efficiently. The sorting values of affected records are normalized while reordering to keep a clean, strictly increasing sorting sequence.

Impact 

Editors working with the EXT:academic_persons_edit extension gain more convenient tools for managing the order of:

• profile contracts
• profile information
• contract email addresses
• contract phone numbers
• contract physical addresses

The new options reduce the number of clicks required to bring a record to the top or bottom of a list and make it easier to maintain a stable and predictable display order.

Affected Installations 

All installations using the EXT:academic_persons_edit extension starting with version 2.3.

Migration 

No explicit migration is required. Existing records keep their current order and sorting values. The new actions can be used immediately to rearrange items as needed and will normalize sorting values on change.

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

TYPO3 v13 deprecated the tt_content sub-type feature, only used for CType=list sub-typing also known as list_type and mostly used based on old times for extbase based plugins. It has been possible since the very beginning to register Extbase Plugins directly as CType instead of CType=list sub-type, which has now done.

Technically this is a breaking change, and instances upgrading from 1.x version of the plugin needs to update corresponding tt_content records in the database and eventually adopt addition, adjustments or overrides requiring to use the correct CType.

Impact 

The change relates to following plugins:

• academicpersonsedit_profileediting
• academicpersonsedit_profileswitcher
• academicpersons_listanddetail
• academicpersons_selectedcontracts
• academicpersons_selectedprofiles

Affected Installations 

All installations using the above listed plugins prior V2.0.

Migration 

A TYPO3 UpgradeWizard academicPersonsEdit_pluginUpgradeWizard is provided to migrate plugins from CType=list to dedicated CTypes matching the new registration.

Description 

The newAction() of the EXT:academic_persons_edit controllers only displays the initial form for create a new entity submitting data submission to the createAction() [POST] and never handles the form again. Following that, there is no need to have form data as optional argument for the newAction() and beside that this would allow to prefill data used for the form using link manipulations as the action is a GET action, which we do not want to work.

Not verified if having the form object as nullable for action in place has been required in earlier extbase days, but today that is absolutely not the case and could only be uses to prefill form data calling that action with corresponding get arguments, which can be considered dangerous and needs to be omitted in the first place.

In case the validation for the createAction() is invalid extbase calls the errorAction() of the controller forwarding the request internally to the newAction() along with the validationResult, already omitting to send the form data argument and being null in any-case. Using the <f:form.* /> fluid ViewHelpers to render the form elements takes care of this and keep the entered values as values even if the form dto object is initialized with empty values, which means that we do not have to take care of that ourself.

Impact 

The optional (nullable) form arguments are removed from following actions:

• ContractController->newAction()
• EmailAdressController->newAction()
• PhoneNumberController->newAction()
• PhysicalAddressController->newAction()
• ProfileInformationController->newAction()

Affected Installations 

All installations using the EXT:academic_persons_edit extension version prior V2.1.

Migration 

Making this visible, for example this

public function newAction(
    Profile $profile,
    ?ContractFormData $contractFormData = null,
): ResponseInterface { /* ... */ }

to

public function newAction(
    Profile $profile,
): ResponseInterface { /* ... */ }

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecations 

Important notes