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 

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 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 

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 

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