Contact records 

A contact is a record of its own, maintained either in the Contacts tab of a page or in the Linked pages tab of a contract. Both edit the same record, so a person can be added from the page it belongs on as well as from the person itself.

A contact record consists of:

Page

The page the person is a contact of. Filled automatically when the record is created from a page.

Contract

The contract of the person to display. Filled automatically when the record is created from a contract.

Role

An optional role, for example Dean's office or Student advisors. Contacts sharing a role are rendered as a group below the name of that role, contacts without a role are rendered below the grouped ones. Roles are records of their own and are usually kept in a storage folder.

Frontend output 

The contacts of a page are rendered either with the content element Contacts for this page, which can be placed anywhere on the page, or directly in a page template through the data processor \FGTCLB\AcademicContacts4pages\DataProcessing\ContactsProcessor , which adds the contacts and their roles to the page rendering. Both display the person through the Profile/Item partial of EXT:academic_persons, so contacts look like the profiles rendered by that extension.

A contact is only shown while the person behind it is visible in the frontend. A contact whose contract is hidden, or whose profile is hidden, outside its start and end time or restricted to a frontend user group the visitor is not in, is left out of both — together with its role, if it is the only contact holding it. Hiding a profile therefore removes the person from every page it is a contact of, without editing a single contact record.

Contacts and page translations 

The Page field of a contact always stores the uid of the default-language page — that is how TYPO3 models references to pages, and it does not change when the contact is translated.

Since version 3.0 a contact follows its page's translations: localizing a contact — directly, by translating the contract or profile above it, or through the translation synchronisation of EXT:academic_persons — only yields a translated contact when the page it points at is translated into that language. For an untranslated page the freshly localized contact is removed again immediately (in the live workspace as a regular soft delete, in a workspace the new record is discarded), because such a translation carries no content of its own and would only make the contact appear twice on the page.

The frontend shows each contact exactly once per language: where a translation exists it represents the contact, otherwise the default-language record is shown. Translated contact duplicates created by versions before 3.0 therefore stop rendering without any database cleanup; the rows themselves are left untouched. Contacts copied into a language without a connection to a default-language record (free mode) are independent records and are exempt from all of this.

What the sets contain 

The extension ships one content element, so it ships one component set and one aggregate set that depends on it.

Both depend on fgtclb/academic-base-ctype-group, the set of EXT:academic_base that labels the content element group all academic extensions sort their elements into.

The content element is hidden by default 

EXT:academic_contacts4pages hides its content element for the whole installation and brings it back per component. Whichever of the two mechanisms below you use, it is what makes Contact list selectable in the backend again — without one of them the content element is not offered, and existing records keep rendering.

Include the site set 

Add the set to the config.yaml of the site that should offer the content element:

 base: 'https://example.com/'
 rootPageId: 1
+dependencies:
+  - fgtclb/academic-contacts4pages

See also TYPO3 Explained, Using a site set as dependency in a site.

Include static templates 

For an installation that still configures its frontend through sys_template records, the same files are registered as static templates and as selectable page TSconfig files.

Do not combine both 

A site that uses the site set and the static template reads the shipped files twice. The site set is applied before the sys_template record, so the second read happens after the site settings and after config/sites/<site>/constants.typoscript — and it resets every constant the extension ships a default for back to that default. For this extension those are the three Fluid root paths of the plugin.

Nothing else is damaged: the Constants and Setup fields of the sys_template record, the page TSconfig of a page and the page TSconfig files selected on a page are all applied afterwards and still win. Use one mechanism per site and the question does not arise.

Also available 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

The contacts content element renders every contact through the profile card of EXT:academic_persons, Partials/Profile/Item.html, which renders the profile image through the responsive image partial of EXT:academic_base from 3.0 on. The image of a contact is therefore a <picture> with WebP sources and a fallback <img> with the classes card-img-top img-fluid, and a contact whose profile has no image shows the placeholder of the persons plugins.

The plugin view registers EXT:academic_base/Resources/Private/Partials/ with the partial root path key -1, below the keys 5 and 10 it uses already, and its settings take the placeholder from the constant plugin.tx_academicpersons.image.placeholder.default, the same one the persons plugins read.

Impact 

• CSS that selects the image as a direct child of the card no longer matches.
• Contacts without a profile image show the placeholder where they showed nothing.
• A project that replaces the partial root paths of the plugin completely, and a page template that renders the contacts of the \FGTCLB\AcademicContacts4pages\DataProcessing\ContactsProcessor through Profile/Item in a view of its own, fail with an exception on the partial Academic/Image that the view cannot resolve.

Affected Installations 

Every installation that renders the contacts content element, or the contacts of the data processor through the profile card.

Migration 

1. Adjust CSS that addresses the contact image.
2. To keep contacts without a profile image empty, set plugin.tx_academicpersons.image.placeholder.default to an empty value.

3. A view that renders Profile/Item - the plugin view with replaced partial root paths, or the page view of a page template - lists the path of EXT:academic_base below the others:

   plugin.tx_academiccontacts4pages.view.partialRootPaths {
       -1 = EXT:academic_base/Resources/Private/Partials/
   }

   Copied!
4. Flush the TYPO3 caches, so the Fluid template cache is rebuilt.

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 or v14 - beforehand or within the same upgrade step.

Description 

tx_academiccontacts4pages_domain_model_contact has always declared 'versioningWS' => true , while the table it is attached to as an inline child — tx_academicpersons_domain_model_contract , extended in Configuration/TCA/Overrides/tx_academicpersons_domain_model_contract.php - did not.

That is the direction TYPO3 does not repair. TcaMigration::addWorkspaceAwarenessToInlineChildren() only ever adds the flag to a child whose parent already carries it, and TYPO3 v13 ships no such migration at all, so a workspace aware child below a live-only parent went unreported on both supported core versions. The TYPO3 documentation calls the combination unsupported.

academic_persons 3.0 declares all of its record tables workspace aware, which resolves it: parent and child now agree.

Impact 

Nothing changes in this extension itself. Its contact records were already versionable and keep their t3ver_* columns.

What changes is that the parent record can now be versioned as well, so a contact and the contract it belongs to are drafted and published together rather than the contact alone being versionable below a record that was not.

The parent table gains four columns and an index in the process. Run the database analyzer once after updating — see Breaking: Person records are workspace aware in the 3.0 changelog of academic_persons , which also documents the SQLite defect that affects the command line path.

Affected Installations 

Every installation of this extension, because it depends on academic_persons and the schema of tx_academicpersons_domain_model_contract changes there.

Description 

A contact record points at a page through its page column - a plain group relation holding the default-language page uid, which the TYPO3 DataHandler copies verbatim when a contact is localized. Localizing a contract or a profile cascades into the contacts below it, so every localization - a plain backend "Translate", the translation synchronization of EXT:academic_persons, or an inline synchronize - used to create translated contacts pointing at pages that do not exist in the target language. Such a translated contact carries no content of its own (every column except page is l10n_mode=exclude) and made the contact appear twice on the page.

The extension now registers a DataHandler hook ( \FGTCLB\AcademicContacts4pages\Hook\DataHandlerHooks ) that removes a freshly localized contact again when the page it points at has no translation in the contact's language. The check is workspace aware: a page translated only in the acting workspace counts as translated there, and a contact localized in a workspace is discarded rather than deleted, so nothing leaks into the live state. A contact whose page is translated keeps its translation, still pointing at the default-language page uid - that is how TYPO3 models page references.

Impact 

Localizing a contract, profile or contact no longer produces contact translations for pages that are not translated into the target language. In the live workspace the removal is a regular soft delete (the row remains in the database with deleted=1 and can be restored through the recycler); in a workspace the new record is discarded entirely.

The guard only acts on connected translations. Contacts copied to a language without a connection to a default-language record (free mode, copyToLanguage) are left alone, as are contacts created directly in a target language.

Translated contacts that already exist in the database are not touched by the hook. They stop rendering as duplicates because ContactRepository::findByPid() now resolves each contact exactly once per language - see the companion changelog entry. Installations that want to clean such legacy rows up can delete the translated contact records whose page has no translation in their language; no upgrade wizard ships for this yet.

Affected Installations 

Every installation that localizes contracts, profiles or contacts into languages in which the referenced pages are not (all) translated - through the backend or through the translation synchronization of EXT:academic_persons.

Description 

A contact of a page points at a contract of EXT:academic_persons, and that contract points at a profile. Both are relations, and Extbase resolves a relation with fresh query settings: a hidden contract, or a profile that is hidden, outside its start and end time or restricted to a frontend user group the visitor does not belong to, resolved to nothing instead of raising an error. The contact record itself was still visible, so the contacts of a page rendered an empty card below its role heading - a person who had left the institution kept a slot on the page.

The contacts content element and the data processor \FGTCLB\AcademicContacts4pages\DataProcessing\ContactsProcessor now leave such a contact out. Both ask the same service for the contacts of a page, so they cannot drift apart, and a page template of a project no longer needs a guard of its own.

Impact 

• A contact whose contract or profile is not visible to the visitor is not rendered, in the content element and in the page data processor alike.
• A role heading is rendered only while at least one shown contact carries that role. The role of a single hidden person disappears with that person, instead of heading an empty group.
• The plugin option Show hidden records is unchanged in meaning: it shows hidden contact records, and never a hidden contract or profile. A hidden contact pointing at a visible person is still shown with the option enabled; a visible contact pointing at a hidden person is not.
• The view variable {contacts} and the processed key contacts are now a plain list instead of a query result. Fluid is unaffected - <f:for> and <f:count> behave identically - but PHP reading either as a query result has to accept a list.
• ContactsProcessor is published as a service and takes its collaborator through the constructor. A project that subclasses the processor and names the subclass in TypoScript has to let its own Services.yaml autowire that subclass; otherwise TYPO3 instantiates it without arguments.

Nothing has to be configured, and no data is migrated. Making a person visible again restores every contact pointing at it.

Affected Installations 

Every installation rendering page contacts whose database holds a hidden contract, or a profile that is hidden, timed or restricted to a frontend user group. Installations that carry a patch or a template guard against empty contact cards can drop it.

Description 

\FGTCLB\AcademicContacts4pages\Domain\Repository\ContactRepository::findByPid() used to lift respectSysLanguage while matching page = <uid> across all language rows. Under a translated language a contact with a translation matched twice - once through its default-language record and once through the translation - and rendered twice in the contacts plugin. Language-only records leaked into the default language, and TYPO3 v13 and v14 disagreed about which rows survived the overlay.

The method now resolves the matching rows per language first - records of the requested language (connected translations and language-only records alike), default-language records without a translation in that language, and records in language "all" - and then fetches exactly those rows, with the overlay pinned to OVERLAYS_MIXED so a translated row maps onto its default record's identity. The behaviour is identical on TYPO3 v13 and v14 and independent of the site's fallback configuration.

Impact 

Each contact arrives exactly once per language context:

• a default-language contact without a translation is returned as-is,
• a translated contact is returned once, represented by its translation,
• legacy duplicated contact translations already present in the database (created by the former synchronization recursion) collapse to a single result row without any database cleanup,
• language-only contacts no longer appear in the default language, and languages without any translation no longer receive foreign-language rows,
• count() on the result now agrees with the number of iterated objects.

The hidden-record handling is unchanged: $showHidden continues to lift only the disabled enable field.

Affected Installations 

Every installation rendering the contacts plugin or data processor on a site with more than one language - in particular installations whose database still holds duplicated contact translations from the former synchronization.

Description 

The extensions of this set spelled their page TSconfig directory in three different ways — TsConfig, TSconfig and TSConfig. They now all use TSconfig, which is how TYPO3 spells the term and what the core documentation uses.

In this extension the directory was Configuration/TsConfig.

Nothing was broken before, because every import matched the directory it pointed at. The reason to change it is that a filesystem is case sensitive on Linux and case insensitive on macOS and Windows, so a path copied between two of these extensions resolved on one machine and silently not on another — and a page TSconfig @import that does not resolve raises no error, the configuration is simply absent.

Impact 

Every file this extension ships moved with the directory. The imports inside the extension were updated in the same change, so an installation that only installs the extension has nothing to do.

An integrator who references these paths from their own configuration has to update them, because the old path no longer exists. The files below the directory were reorganised in the same release, so the new path is not the old one with the spelling corrected — take it from the table in Breaking: Site sets and static templates have been restructured:

# before
@import 'EXT:academic_contacts4pages/Configuration/TsConfig/page.tsconfig'
# after
@import 'EXT:academic_contacts4pages/Configuration/TSconfig/Full/page.tsconfig'

Affected Installations 

Every installation that imports a page TSconfig file of this extension by path, or that copied such a path into its own site package. An installation that relies only on the auto-included Configuration/page.tsconfig of the extension, or on its site set, is unaffected.

Description 

The record icons of this extension were registered with the core provider \TYPO3\CMS\Core\Imaging\IconProvider\SvgIconProvider , which renders the default markup - the markup a typeicon_classes entry reaches - as an <img> tag. An image is opaque to CSS, so the icon kept the ink of its file whatever the backend colour scheme said, and a dark drawing stayed dark on the dark cards of the record list.

They are now registered with \FGTCLB\AcademicBase\Imaging\IconProvider\CurrentColorSvgIconProvider , which inlines the file in both markups, and the files themselves are drawn in currentColor with no colour of their own.

The two identifiers are tx_academiccontacts4pages_domain_model_contact and tx_academiccontacts4pages_domain_model_role .

Impact 

The contact and role record icons take the text colour of the backend, so they stay legible in a dark colour scheme. Their markup is now the inlined <svg> rather than an <img> , which matters to any CSS or test that addressed the image.

The content element icon academic_contacts4pages keeps the core provider, although it shares Extension.svg with the contact record icon. That file now carries fill="currentColor" instead of the implicit black, which renders identically inside an <img> .

Affected Installations 

Every installation of this extension.

Breaking Changes 

Features 

Deprecations 

Important notes 

Also available 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

EXT:academic_contacts4pages shipped its own \FGTCLB\AcademicContacts4pages\Backend\FormEngine\ContractItemsProcFunc , which basically duplicated the contract itemsProcFunc of the hard-depended EXT:academic_persons.

The duplicated class has been removed. The contract selection field now uses the itemsProcFunc shipped by EXT:academic_persons, \FGTCLB\AcademicPersons\Backend\FormEngine\ContractItems , which is easier to maintain, especially when changes to the itemsProcFunc are made.

Impact 

Referencing the removed class throws a PHP error. The shipped TCA of tx_academiccontacts4pages_domain_model_contact has been switched to the EXT:academic_persons handler.

Affected Installations 

Installations that reference \FGTCLB\AcademicContacts4pages\Backend\FormEngine\ContractItemsProcFunc in own TCA/FlexForm configuration, extend or replace it, or call it directly.

Migration 

Use the itemsProcFunc provided by EXT:academic_persons instead:

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

Projects that need to adjust the available contract items should use the \FGTCLB\AcademicBase\Event\ModifyTcaSelectFieldItemsEvent event listener instead of a custom itemsProcFunc.

Description 

The TypoScript of this extension was shipped through a chain of @import statements: the static template read Configuration/TypoScript/, whose setup.typoscript imported Configuration/TypoScript/Page/, and the site set fgtclb/academic-contacts4pages shipped a setup.typoscript of its own that imported the first one again. The page TSconfig existed only as Configuration/TSconfig/page.tsconfig, reachable through the auto-included Configuration/page.tsconfig and through nothing else — it was not selectable on a page at all.

Both mechanisms now read one physical copy of every file, and both of them deliver the extension per component instead of as one block:

• Configuration/TypoScript/List/ holds the TypoScript of the Contact list content element and is what the static template registers and what the set points its typoscript key at. Its setup.typoscript carries what Configuration/TypoScript/Page/Plugin.typoscript and Configuration/TypoScript/Page/Fluidtemplate.typoscript used to carry, with one difference: the three Fluid root paths were literals there and are constants now, declared in the constants.typoscript beside it.
• Configuration/TSconfig/List/page.tsconfig holds its page TSconfig and is what the page field Page TSconfig offers and what the set points its pagets key at.
• Configuration/TypoScript/Full/ and Configuration/TSconfig/Full/page.tsconfig are the aggregates for installations that do not use site sets.

The extension ships a constants.typoscript for the first time. It declares the three Fluid root paths of the plugin — plugin.tx_academiccontacts4pages.view.templateRootPath , …partialRootPath and …layoutRootPath — with exactly the values that were hard coded in the setup before, so a site that changes nothing renders exactly as it did. What is new is that these paths can now be overridden as constants, in the constant editor or in config/sites/<site>/constants.typoscript.

The content element is now hidden by default. The always-included Configuration/page.tsconfig removes academiccontacts4pages_list from the selectable content element types, and the page TSconfig of the component adds it back — so the element is offered where it is wanted instead of on every page of every installation. The TCA registration itself did not move, so the frontend renders existing records exactly as before. Editing such a record in the backend is a different matter — read the warning below before upgrading.

Impact 

A sys_template record that selected the old static template keeps its stored value, and that value now points at a folder holding no constants.typoscript and no setup.typoscript. It is not an error — the frontend simply loses the plugin configuration and the data processor that assigns the contacts of a page to the page template, and the plugin renders with no template paths.

A site package that imported one of the shipped files by path fails to resolve it. @import of a missing file is silent, so this also shows up as missing configuration rather than as an error message.

The Contact list content element is no longer offered in the backend until the page TSconfig of the component is included, through the site set or through the page field Page TSconfig.

The set fgtclb/academic-contacts4pages keeps its name and keeps delivering everything, so a site configuration that depends on it needs no change.

Affected Installations 

Installations that select the static template of this extension in a sys_template record, that import one of the shipped files from an own site package, or that use the content element without including the page TSconfig of this extension.

Migration 

Replace the static template entry in the sys_template record:

Add the page TSconfig entry, which did not exist before, in the page record of the site root, tab Resources, field Page TSconfig: Academic Contacts4Pages: All components (academic_contacts4pages), stored as EXT:academic_contacts4pages/Configuration/TSconfig/Full/page.tsconfig. Without it the content element is not selectable any more, and existing records of it lose their CType when they are saved from the backend form.

Sites that use the site set instead need no migration — but they must not use both mechanisms at once, see the Configuration chapter.

Adjust every @import in an own site package:

@import 'EXT:academic_contacts4pages/Configuration/TypoScript/List/constants.typoscript'

A site configuration may name the new component set instead of the aggregate:

Description 

A contact record ( tx_academiccontacts4pages_domain_model_contact ) now carries three additional selects, grouped in the palette Displayed address records:

• E-mail address ( email_address )
• Phone number ( phone_number )
• Physical address ( physical_address )

They are offered as soon as a contract is selected and list the email addresses, phone numbers and physical addresses of exactly that contract. The contract field reloads the form on change, so the selects always match the contract that is currently selected.

Each select offers two options besides the address records themselves:

Display all

The default. All address records of that kind are rendered, the behaviour of every contact record created so far.

Do not display

The address record kind is left out of the frontend output for this contact entirely.

The narrowing is applied by the contact record itself, so it takes effect in the Contacts for this page plugin, in the page based rendering through ContactsProcessor and in project templates built on either of them - they all reach the address records through Contact::getContract() . Contact::getUnfilteredContract() returns the contract with all of its address records.

Only default language records are offered: the selection is shared by all translations of a contact, and the frontend resolves the language overlay of the address records itself. Deleted records are not offered. Hidden ones are, marked with a [Hidden] prefix - whether they reach the frontend is decided by the plugin, see below.

Impact 

Editors can restrict a page contact to a single email address, phone number and physical address of the contract, or suppress a kind completely - for example to publish the office phone number of a person on one page and the private one on another, from the same contract.

Hidden address records reach the frontend only through the Contacts for this page plugin and only while its Show hidden records option ( settings.showHiddenRecords ) is enabled, the same option that decides about hidden contacts. That covers both ways of displaying them: with the option enabled a hidden record is part of Display all and can be selected as the single one to display. Everywhere else - the page based rendering through ContactsProcessor included - hidden records are left out, and a selection pointing at one behaves like Do not display.

A selection that cannot be resolved at all behaves the same way and renders nothing. This happens when the contract of a contact is switched after the selection was made, or when the selected address record is deleted afterwards. There is deliberately no fallback to Display all: publishing the private phone number of a person because a record was removed is worse than publishing nothing.

Affected Installations 

All installations using the EXT:academic_contacts4pages extension starting with version 2.4. The three new columns default to Display all, so existing contact records keep their current frontend output and no migration is required. A database compare has to be applied for the new columns.

Description 

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

• Contacts for this page ( academiccontacts4pages_list )

This plugin previously had no flexform at all. A new Configuration/FlexForms/ContactsList.xml data structure is introduced and registered for the plugin (a "Configuration" tab with the pi_flexform field is added to the content element), so the option can be configured per plugin instance.

When the option is enabled, the frontend contacts listing includes hidden (disabled) records, independent of the Context API visibility settings. Only the hidden enable column (disabled) is ignored; the deleted restriction stays in effect.

Impact 

Editors can now opt in per plugin instance to display hidden contacts 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_contacts4pages extension starting with version 2.4. No action is required for existing installations.

Description 

To support the new "Show hidden records" plugin option, the \FGTCLB\AcademicContacts4pages\Domain\Repository\ContactRepository gained an extended method:

• findByPid(int $pid, bool $showHidden = false): QueryResultInterface — the new optional $showHidden parameter was appended.

When $showHidden is true , the query ignores only the disabled (hidden) enable field via the Extbase query settings. The \FGTCLB\AcademicContacts4pages\Controller\ContactsController reads $this->settings['showHiddenRecords'] and passes it to the repository.

Impact 

The change is non-breaking: the new parameter has a default value, so existing calls keep working unchanged. Projects that extend or replace ContactRepository should adopt the same signature when overriding findByPid() .

Affected Installations 

Only installations that extend or override \FGTCLB\AcademicContacts4pages\Domain\Repository\ContactRepository need to take the extended signature into account. All other installations are unaffected.

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

Breaking Changes 

Features 

Deprecation 

Important 

Description 

Some partials got removed as the templating structure has changed.

Impact 

Those partials include:

• Resources/Private/Partials/Contacts/ContactWidget.html
• Resources/Private/Partials/Contacts/ContactWidgetAddress.html

This extension now reuses the partials of the academic-persons extension.

Affected Installations 

EXT:academic_contact4pages installations overriding those partials.

Migration 

Adapt overrides accordingly to the partials provided by EXT:academic-persons.

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 

Breaking Changes 

Features 

Deprecations 

Important notes