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

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.

Breaking Changes 

Features 

Deprecations 

Important notes 

Also available 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

The profile synchronization (profile update command) previously skipped frontend users that were disabled or whose profile was hidden. Such records were neither selected by \FGTCLB\AcademicPersons\Provider\FrontendUserProvider::getUsersWithProfileResult() (the automatic hidden restriction excluded them) nor resolved by \FGTCLB\AcademicPersons\Domain\Repository\ProfileRepository::findByFrontendUser().

The synchronization now processes hidden profiles and disabled frontend users as well and keeps their data up to date, without changing their visibility.

The same applies to the profile creation (profile create command): \FGTCLB\AcademicPersons\Provider\FrontendUserProvider::getUsersWithoutProfileResult() now also returns disabled frontend users and \FGTCLB\AcademicPersons\Profile\AbstractProfileFactory::createProfileForUser() resolves the frontend user ignoring its visibility, so a profile is created for a disabled frontend user as well.

Impact 

A hidden profile or a profile of a disabled frontend user that was relying on being skipped by the synchronization is now updated again on the next synchronization run. Its data (name, contact records, ...) is overwritten with the current frontend user data, while the hidden state itself is kept untouched.

A disabled frontend user without a profile now also receives a newly created profile on the next profile create run.

Only the deleted state is still respected; both the frontend user visibility (fe_users.disable) and the profile hidden field are ignored for the profile synchronization and creation.

Affected Installations 

All installations using the profile synchronization (EXT:academic_persons create/update profile commands) together with manually hidden profiles or disabled frontend users.

Migration 

If a profile should be excluded from the synchronization, use the dedicated skip_sync flag of the profile instead of hiding the profile or disabling the frontend user. Hiding a profile now only controls its frontend visibility, not whether it is synchronized.

Description 

While introducing the shared PSR-14 event \FGTCLB\AcademicBase\Event\ModifyTcaSelectFieldItemsEvent to allow modifying the select items of fields populated by an itemsProcFunc, the two itemsProcFunc handler classes shipped by EXT:academic_persons received a proper namespace and class names suitable for classes providing itemsProcFunc implementations.

The following classes have been renamed and moved:

• \FGTCLB\AcademicPersons\Backend\Form\ContractItemsProcFunc is now \FGTCLB\AcademicPersons\Backend\FormEngine\ContractItems.
• \FGTCLB\AcademicPersons\Backend\Form\ProfileShowFieldsItemProcFunc is now \FGTCLB\AcademicPersons\Backend\FormEngine\ProfileShowFieldsItems.

Additionally the entry method of the profile show fields handler has been streamlined from showFields() to itemsProcFunc() to match the other handlers.

The references to these classes in the shipped plugin FlexForms have been adjusted accordingly.

Impact 

Referencing the old class names or the old showFields() method throws a PHP error. This affects TCA/FlexForm itemsProcFunc configurations, projects extending or replacing these classes and any code instantiating them directly.

Affected Installations 

Installations that reference the old classes in own TCA/FlexForm configuration, extend or replace them, or call them directly.

Migration 

Replace all usages of the old class names with the new ones and use the itemsProcFunc() method for both handlers:

FGTCLB\AcademicPersons\Backend\Form\ContractItemsProcFunc->itemsProcFunc
=> FGTCLB\AcademicPersons\Backend\FormEngine\ContractItems->itemsProcFunc

FGTCLB\AcademicPersons\Backend\Form\ProfileShowFieldsItemProcFunc->showFields
=> FGTCLB\AcademicPersons\Backend\FormEngine\ProfileShowFieldsItems->itemsProcFunc

Projects that only replaced the shipped items should consider using the new \FGTCLB\AcademicBase\Event\ModifyTcaSelectFieldItemsEvent event listener instead of a custom itemsProcFunc.

Description 

The following itemsProcFunc handlers provided by EXT:academic_persons now dispatch the shared PSR-14 event \FGTCLB\AcademicBase\Event\ModifyTcaSelectFieldItemsEvent:

• \FGTCLB\AcademicPersons\Backend\FormEngine\ContractItems
• \FGTCLB\AcademicPersons\Backend\FormEngine\ProfileShowFieldsItems

Previously the shipped select items could only be adjusted by adding items directly (without influence on the ordering) or by implementing a custom itemsProcFunc replacing the shipped one. Both ways were neither convenient nor testable.

With the dispatched event, projects can modify the available select items for the backend (FormEngine) - and, where the handler is reused, for the frontend - through a single PSR-14 event listener, instead of dealing with a dozen dedicatedly named events for the same purpose.

Example 

<?php

declare(strict_types=1);

namespace MyVendor\MyExt\EventListener;

use FGTCLB\AcademicBase\Event\ModifyTcaSelectFieldItemsEvent;
use TYPO3\CMS\Backend\Utility\BackendUtility;
use TYPO3\CMS\Core\Attribute\AsEventListener;

#[AsEventListener(identifier: 'my-ext/modify-academic-persons-tca-select-items')]
final class ModifyTcaSelectFieldItemsEventListener
{
    public function __invoke(ModifyTcaSelectFieldItemsEvent $event): void
    {
        $tableName = $event->getParameters()['table'];
        $fieldName = $event->getParameters()['field'];
        if ($tableName !== 'tt_content') {
            // Not the table we want to handle. Skip.
            return;
        }
        if ($fieldName === 'settings.showFields') {
            $this->modifyPersonsShowFieldsSelectItems($event);
        }
        if ($fieldName === 'settings.selectedContracts') {
            $this->modifyPersonsContractSelectItems($event);
        }
    }

    private function modifyPersonsShowFieldsSelectItems(
        ModifyTcaSelectFieldItemsEvent $event,
    ): void {
        $parameters = $event->getParameters();
        $parameters['items'][] = [
            'label' => BackendUtility::getItemLabel('tx_academicpersons_domain_model_contract', 'position'),
            'value' => 'contracts.position',
            'group' => 'contracts',
        ];
        $event->setParameters($parameters);
    }

    private function modifyPersonsContractSelectItems(
        ModifyTcaSelectFieldItemsEvent $event,
    ): void {
        $parameters = $event->getParameters();
        $parameters['items'][] = [
            'label' => 'LLL:EXT:my_ext/Resources/Private/Language/locallang_be.xlf:custom_contract',
            'value' => 10,
        ];
        $event->setParameters($parameters);
    }
}

Description 

A new boolean plugin option Show hidden records ( settings.showHiddenRecords, checkbox/toggle, default off) was added to the following plugins:

• List ( academicpersons_list)
• List and detail ( academicpersons_listanddetail)
• Card ( academicpersons_card)
• Selected profiles ( academicpersons_selectedprofiles)
• Selected contracts ( academicpersons_selectedcontracts)
• Detail ( academicpersons_detail)

The List, List and detail and Card plugins share the core-version-aware List.xml flexform; Selected profiles, Selected contracts and Detail use their own SelectedProfiles.xml, SelectedContracts.xml and Detail.xml flexforms. All are provided for both the TYPO3 v12 and v13 flexform data structures.

When the option is enabled, the affected frontend listing includes hidden (disabled) records, independent of the Context API visibility settings. Only the hidden enable column (disabled) is ignored; the deleted, starttime/endtime and fe_group restrictions stay in effect.

The single-profile Detail plugin resolves its profile through Extbase argument mapping, which normally respects enable fields. When the option is enabled, the detail view re-resolves the referenced profile including hidden records, so a hidden profile can be displayed on its detail page.

Impact 

Editors can now opt in per plugin instance to display hidden profiles or contracts in the frontend, for example to preview intentionally hidden records without changing the global preview settings. The option is off by default, so existing plugin instances keep their current behaviour.

Affected Installations 

All installations using the EXT:academic_persons extension starting with version 2.4. No action is required for existing installations.

Description 

The profile synchronization (profile update command, \FGTCLB\AcademicPersons\Service\ProfileUpdateCommandService) now also keeps hidden profiles and profiles of disabled frontend users up to date. Previously a frontend user that was disabled or whose profile was hidden was excluded from the synchronization completely, so the profile was never updated and no synchronization events were dispatched for it.

The \FGTCLB\AcademicPersons\Domain\Repository\ProfileRepository method findByFrontendUser() gained an optional argument to include hidden profiles:

• findByFrontendUser(int $frontendUserUid, bool $showHidden = false): QueryResultInterface

The synchronization calls it with $showHidden = true, while the frontend display keeps the default ( $showHidden = false) and therefore continues to respect the visibility.

The visibility itself is never changed by the synchronization — that stays the responsibility of the \FGTCLB\AcademicPersons\Profile\ProfileFactoryInterface implementation — so a manually hidden profile stays hidden while its data is kept in sync.

The profile create command keeps skipping frontend users that already have a profile, including a hidden one, so no duplicate profiles are created for them. It now also creates a profile for a disabled frontend user that does not have one yet: \FGTCLB\AcademicPersons\Provider\FrontendUserProvider::getUsersWithoutProfileResult() returns disabled frontend users and \FGTCLB\AcademicPersons\Profile\AbstractProfileFactory::createProfileForUser() resolves the frontend user ignoring its visibility.

Impact 

Hidden profiles and profiles of disabled frontend users are no longer silently excluded from the synchronization. To exclude a profile from synchronization, use the dedicated skip_sync flag of the profile instead of hiding it or disabling the frontend user.

Affected Installations 

All installations using the profile synchronization (EXT:academic_persons create/update profile commands) starting with version 2.4.

Description 

The contact record models gained access to the hidden enable field that already exists on their database tables:

• \FGTCLB\AcademicPersons\Domain\Model\Address
• \FGTCLB\AcademicPersons\Domain\Model\Email
• \FGTCLB\AcademicPersons\Domain\Model\PhoneNumber

Each of them now provides:

• getHidden(): bool
• setHidden(bool $hidden): self

To work with hidden records the matching repositories ( AddressRepository, EmailRepository, PhoneNumberRepository) provide two new methods that ignore the disabled enable field:

• findByContractIncludingHidden(int $contractUid): QueryResultInterface
• findByUidIncludingHidden(int $uid): ?<Model>

These are used by EXT:academic_persons_edit (optional) to let profile owners show and hide their contact records in the frontend, while the public profile display keeps excluding hidden records via the default Extbase enable field handling.

Impact 

The profile synchronization keeps matching and updating existing contact records even when they are hidden, and no longer resets their visibility. Integrators can use the new model accessors and repository methods to handle contact record visibility programmatically.

Affected Installations 

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

Migration 

No migration is required, except you extended and replaced the extbase model in projects - then you need to adopt the newly added properties and setter/getter methods with the same signatures.

Description 

To support the new "Show hidden records" plugin option, the person demand and repository layer gained the following additions. All of them are non-breaking (new optional parameter / new transport flag with defaults):

• \FGTCLB\AcademicPersons\Domain\Model\Dto\ProfileDemand has a new showHiddenRecords transport flag with getShowHiddenRecords(): bool and setShowHiddenRecords(bool): ProfileDemand accessors (default false). It mirrors the existing transport-only properties ( storagePages, fallbackForNonTranslated) and is likewise announced as a future addition to \FGTCLB\AcademicPersons\Domain\Model\Dto\DemandInterface (the interface carries the commented signatures and the repository guards the call with method_exists()).
• \FGTCLB\AcademicPersons\Domain\Repository\ProfileRepository::findByDemand() honours ProfileDemand::getShowHiddenRecords() via applyDemandSettings().
• \FGTCLB\AcademicPersons\Domain\Repository\ProfileRepository::findByUids() and \FGTCLB\AcademicPersons\Domain\Repository\ContractRepository::findByUids() gained an appended optional bool $showHidden = false parameter.
• \FGTCLB\AcademicPersons\Domain\Repository\ProfileRepository::findByUidIncludingHidden(int $uid): ?Profile is a new method that resolves a single profile by uid including hidden (disabled) records. It is used by the detail view.
• \FGTCLB\AcademicPersons\Controller\ProfileController reads $this->settings['showHiddenRecords'] in adoptSettings(), cardAction(), selectedProfilesAction() and selectedContractsAction() and threads it into the repositories. The new initializeDetailAction() re-resolves the profile argument via findByUidIncludingHidden() when the option is enabled, because the default Extbase argument mapping respects enable fields.

When the flag/parameter is set, the query ignores only the disabled (hidden) enable field via the Extbase query settings; the deleted, starttime/endtime and fe_group restrictions stay in effect.

Impact 

The change is non-breaking: the new demand flag defaults to false, the new findByUids() parameter has a default value, and no existing method signature changed in an incompatible way. Projects that build a ProfileDemand or call findByUids() themselves can opt in via setShowHiddenRecords(true) respectively the new parameter.

Affected Installations 

Only installations that extend or replace the ProfileDemand DTO, the ProfileRepository, the ContractRepository or the ProfileController need to take the additions into account. All other installations are unaffected.

Description 

EXT:academic_persons now depends on the standalone extension fgtclb/environment-state-manager and declares it consistently in both composer.json ( "fgtclb/environment-state-manager": "^1.0") and ext_emconf.php ( 'environment_state_manager' => '1.0.0-1.99.99').

The extension was switched from the internal, now deprecated \FGTCLB\AcademicBase\Environment subsystem to the extracted fgtclb/environment-state-manager extension (namespace \FGTCLB\EnvironmentStateManager), which it uses in its profile command services. The dependency is therefore required at runtime.

Impact 

Composer-managed installations pull fgtclb/environment-state-manager in automatically when EXT:academic_persons is updated to 2.4; no action is required.

Classic, non-composer installations (TER / extension manager) must install the environment_state_manager extension in addition to EXT:academic_persons, otherwise the extension cannot be activated.

Affected Installations 

Only non-composer installations updating to EXT:academic_persons 2.4 need to install the additional extension manually. Composer-managed installations are unaffected.

Breaking Changes 

Features 

Deprecation 

Important 

Description 

PSR-14 Event \FGTCLB\AcademicPersons\Event\ModifyListProfilesEvent got following new methods:

• getProfileDemand(): ProfileDemand
• setProfileDemand(ProfileDemand $profileDemand): void

This gives event listeners the ability to redo a query with the same or further enriched demand object to replace the retrieved profiles result already existing in the event and/or enrich data in the view.

Breaking Changes 

Features 

Deprecation 

Important 

Description 

EXT:academic_persons provided the academic:createprofiles for quite a long time now to create profile automatically for frontend users taking data from TYPO3 fe_users records. That can be extended by extension or projects to get import data from other sources like LDAP or other external identity providers.

To further improve that handling the academic:updateprofiles is now added in a similar way to handle updates of profile data based on the source using the scheduler, for example to update data imported from external LDAP.

import_identifier varchar(170) DEFAULT '' NOT NULL is added to all extension tables and all domain models got extended to have that property along with setter und getter in place. Existing imported profile data needs to be updated in the project to have the identifier in place and custom create/update profile implementation can use that field to flag it with their data.

Further a skip_sync field is added to tx_academicpersons_domain_model_profile defaulting to false ((INT)0). If this field is set to true/1 the update command excludes these records in a early stage and do not call or dispatch any further methods or events.

Breaking Changes 

Features 

Deprecation 

Important 

Description 

ProfilesController::selectedProfilesAction() dispatched the ModifyListProfilesEvent PSR14 event accidentally due to copy&paste when introducing the new plugin and action for 2.0.x. This event is no longer dispatched for this action, instead the new and correct event ModifySelectedProfilesEvent is now dispatched.

Affected Installations 

EXT:academic_partners installations listening to the ModifyListProfilesEvent event.

Migration 

Adapt any listeners/subscribers accordingly to the correct event.

Description 

Some partials got removed as the templating structure has changed.

Impact 

Those partials include:

• Resources/Private/Partials/List/AlphabetPagination.html
• Resources/Private/Partials/List/ListItem.html
• Resources/Private/Partials/List/Pagination.html
• Resources/Private/Partials/SelectedContracts/ListItem.html

Affected Installations 

EXT:academic_partners installations overriding those partials.

Migration 

Adapt overrides accordingly to the new templating structure.

Description 

Using constructor dependency injection in abstract classes defines the constructor as API, which should be avoided by using the inject-method approach and allows to implement classes using constructor DI without the requirement to deal and align with parent (abstract) class constructor and passing it down.

AbstractProfileFactory used constructor DI and therefore violated the above described design pattern.

Constructor DI arguments are now replaced with inject-methods in the abstract FGTCLBAcademicPersonsProfileAbstractProfileFactory.

See Autowiring other Methods (e.g. Setters and Public Typed Properties)

Impact 

AbstractProfileFactory used constructor DI and therefore violated the above described design pattern.

Constructor DI arguments are now replaced with inject-methods in the abstract FGTCLBAcademicPersonsProfileAbstractProfileFactory.

Affected Installations 

Installations using the abstract and defining own constructor DI arguments.

Migration 

Implementation using the abstract and defining own constructor DI arguments needs to remove the removed parent arguments and avoid calling the parent constructor.

Additionally, the SymfonyContractsServiceAttributeRequired attribute is used for the inject methods to tell symfony DI that these inject methods needs to be called and are mandatory - beside having a visually glue for developers.

Description 

EXT:academic_persons provides a command to create profiles for frontend users, extendable by dispatching events to allow devs customizing the profile creation in projects, for example to base it on special needs like retrieving updated user data from LDAP oder other services.

Until now, all frontend users without profiles on any pid has been fetched, which does not respect use-cases where frontend users for dedicated logins are required and profile creation is not wanted, needed or suitable.

This change adds following new options to the provided command vendor/bin/typo3 academic:createprofiles:

• --include-pids: comma-separated list of storage pid's from which frontend users should be fetched (only).
• --exclude-pids: comma-separated list of storage pid's from which frontend users should be ignored (skipped).

Description 

It's possible to set a pageTitleFormat in the plugin settings for plugins using the ProfileController::detailAction(), which is used in ProfileTitleProvider to set the HTML page title for the person profile pages.

This change extends the existing ModifyDetailProfileEvent, which is dispatched in the ProfileController::detailAction(), to make the default and the setting pageTitleFormat changeable using an PSR-14 event listener.

This gives developers the ability to implement a wide range of use-cases in projects, for example adding a prefix to the format based on the site configuration or similar.

New ModifyDetailProfileEvent methods:

• getDefaultPageTitleFormat(): string
• setDefaultPageTitleFormat(string $defaultPageTitleFormat): void
• getSettingsPageTitleFormat(): string
• setSettingsPageTitleFormat(string $settingsPageTitleFormat): void
• getPageTitleFormatToUse(): string

The getPageTitleFormatToUse(): string is a calculated function to get the aggregated format to use, which allows checking the result in event listeners and determine the format finally used as detail view page title.

The original default pageTitleFormat is ProfileTitleProvider::DETAIL_PAGE_TITLE_FORMAT.

Description 

ProfileController::selectedContractsAction() dispatches now the new PSR-14 ModifySelectedContractsEvent.

The event provides following methods:

• getContracts(): QueryResultInterface return current result set.
• setContracts(QueryResultInterface $contracts): void to allow setting a custom resultset.
• getView(): FluidViewInterface|CoreViewInterface return the current view to allow assigning custom values to the view.
• getPluginControllerActionContext(): PluginControllerActionContextInterface to provide more context information

Description 

ProfileController::selectedProfilesAction() dispatches now the new PSR-14 ModifySelectedProfilesEvent instead of erroneous copied listAction event ModifyListProfilesEvent, which is no longer dispatched. That should not be that of an issue for most implementations.

The event provides following methods:

• getProfiles(): QueryResultInterface return current result set.
• setProfiles(QueryResultInterface $profiles): void to allow setting a custom resultset.
• getView(): FluidViewInterface|CoreViewInterface return the current view to allow assigning custom values to the view.
• getPluginControllerActionContext(): PluginControllerActionContextInterface to provide more context information

Description 

It's a valid use-case to use a pageTitleFormat for the person profile detail page view as HTML page title including localized text as placeholders and could be implemented using the PSR-14 event ModifyProfileTitlePlaceholderReplacementEvent dispatched in the ProfileTitleProvider.

Localization is a generic feature and it's most likely that it's use-full for a broader audience this change adds now support for localization placeholder in the format:

%%LLL:EXT:<extension-key>/Resources/.../locallang.xlf:identifier%%

Note that no context fallback detection is made like within fluid templates or extbase context areas and a valid relative path for the default language file within a extension needs to be provided.

Functional tests are added to cover the new feature basically and provide some examples, using a dedicated test fixture extension.

Description 

A new readonly DTO object PluginControllerActionContext is introduced and is attached to dispatched PSR-14 events in ProfileController actions.

Impact 

Following main getters are provided:

• getApplicationType(): ApplicationType to return the TYPO3 application type

for the current request. `getExtbaseRequestParameters(): ?ExtbaseRequestParameters` to retrieve extbase attribute from request as a simple accessor. getRequest(): ServerRequestInterface to return the current request. `getSettings(): array` to retrieve raw plugin settings (TypoScript, FlexForm). getSite(): ?Site to retrieve resolved site configuration. * getLanguage(): ?SiteLanguage to retrieve resolves site language.

Following getters dispatches to ExtbaseRequestParameters methods and returning null in case the request attribute is not set in the request:

• getActionName(): ?string
• getControllerName(): ?string
• getControllerObjectName(): ?string
• getControllerExtensionKey(): ?string
• getControllerExtensionName(): ?string
• getPluginName(): ?string

Description 

With recent changes a series of features has been implemented to make the HTML title tag for person profile pages more flexible, with a placeholder based FlexForm options and also allowing to influence the default and the setting pageTitleFormat.

The used ProfileTitleProvider already looks into the format string and provides the ability to replace placeholders, which matches getters in the profile.

To provide even more flexibility, this change introduces a new PSR-14 Event ModifyProfileTitlePlaceholderReplacementEvent, which is dispatched for each placeholder enriched with quite a handfull of use-full context information.

Following methods are available on the event:

• getPluginControllerActionContext(): PluginControllerActionContextInterface containing the request along with easy access methods to site, siteLanguage and extbase plugin information and the plugin settings.
• getProfile(): Profile the current person profile to display.
• getPlaceholder() the original/raw placeholder identifier.
• getReplacement() the value to replace the placeholder with, which may differ already if a earlier event listener changed the value using setReplacement().
• setReplacement(string $replacement): void to set the value used to replace the placeholder.

This event allows project to implement custom placeholders and the replacement without using old-school xclassing technique.

Description 

It's now possible to define the format used to generate the HTML PageTitle for the detail view of persons in the frontend, using the TYPO3 PageTitle API.

The default format used based on Profile extbase model data is:

%%TITLE%% %%FIRST_NAME%% %%MIDDLE_NAME%% %%LAST_NAME%%

To allow easier customization in project, a new FlexForm option pageTitleFormat has been added to listanddetail plugin and as single new option for the detail plugin, which uses TCA type=input combined with a ValuePicker to allow picking from a list of pre-defined formats while still making it possible to define own custom format directly on plugin usage.

The mapping from placeholder to extbase model is based on transforming the placeholder to camelcase using first character after separators and prefix it with get, and if the getter exists it is called to retrieve the value.

For example:

which calls Profile->getFirstName() to retrieve the replacement value from the detail view profile.

The whole process contains some behaviour, which needs to be kept in mind:

• Leading and trailing spaces are trimmed from each value(placeholder).
• Multiple spaces are removed from the whole format string.
• Leading and trailing spaces are trimmed from the whole format pattern, after placeholder resolving has been processed.

Example for allowed characters as placeholder identifier:

Note that most of them has no handling for matching person profile getters, but are use-full for advanced replacement using the experimental PSR-14 event.

Description 

The default templating now supports basic bootstrap styling and is semantically optimized to also not lack any major accessibility.

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:

• academicpersons_detail
• academicpersons_list
• academicpersons_listanddetail
• academicpersons_selectedcontracts
• academicpersons_selectedprofiles

Affected Installations 

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

Migration 

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

Breaking Changes 

Features 

Deprecations 

Important notes