Configuration 

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 and the content element header switch.

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.

The contact list 

plugin.tx_academiccontacts4pages.settings.groupByRole = 1

plugin.tx_academiccontacts4pages.view.partialRootPaths.20 = EXT:my_sitepackage/Resources/Private/Extensions/academic_contacts4pages/Partials/

The contacts in a page template 

The data processor of this extension hands the contacts of a page to a page template, for a page layout that shows them outside the content area, as a sidebar or a slide-in panel. The shipped TypoScript attaches it to page.10 , where most site packages, the bootstrap package among them, put their page template, by its identifier academic-page-contacts. The contacts are the ones the content element shows: a contact whose contract or profile is not visible is left out, and a listener of the page contacts event reaches both outputs.

The processor takes three options, each with stdWrap :

Contacts are edited in the form of their page and stored on it, so saving them clears the cache of that page. A page that shows the contacts of another page through pageUid is not cleared with it and keeps the old contacts until its own cache is cleared. The page TSconfig of the page the contacts belong to can clear it as well:

TCEMAIN.clearCacheCmd = 42

The options go on the shipped entry:

page.10.dataProcessing.400 {
    as = pageContacts
    showHiddenRecords = 0
}

A site package that defines its page object after this extension's TypoScript is included, or that renders a further page object, a page type of its own for example, attaches the processor there by the same identifier. Assigning a new content object to page.10 keeps the properties set before, the shipped dataProcessing.400 included, so clear it first, or the processor runs twice. A processor attached twice to one page object on purpose needs a variable name for at least one of them, or the second overwrites the first:

page.10 >
page.10 = PAGEVIEW
page.10 {
    paths.10 = EXT:my_sitepackage/Resources/Private/Templates/
    dataProcessing {
        40 = academic-page-contacts
        40.as = pageContacts
    }
}

<f:for each="{pageContacts.roles}" as="role">
    <h2>{role.name}</h2>
    <f:for each="{pageContacts.contacts}" as="contact">
        <f:if condition="{contact.role.uid} == {role.uid}">
            <p>{contact.contract.profile.firstName} {contact.contract.profile.lastName}</p>
        </f:if>
    </f:for>
</f:for>
<f:for each="{pageContacts.contactsWithoutRole}" as="contact">
    <p>{contact.contract.profile.firstName} {contact.contract.profile.lastName}</p>
</f:for>

A page template that renders the contacts through the Profile/Item partial of EXT:academic_persons needs the partial root paths of that extension and of EXT:academic_base in its view, see Breaking: Profile images render as a responsive picture.

The class name \FGTCLB\AcademicContacts4pages\DataProcessing\ContactsProcessor in place of the identifier keeps working, for TypoScript written before the identifier existed.

The header of the content elements 

The header and the subheader an editor enters on a Contacts for this page content element are rendered by the content element layout of the site, as for any other content element. The layouts of EXT:fluid_styled_content and of the bootstrap package do that, and the plugins render no header of their own.

A site whose content element layout renders no header, because its element templates render it instead, lets the plugins render it:

plugin.tx_academiccontacts4pages.renderContentElementHeader = 1

The extension declares no site settings, so a site that uses the site set sets the constant in config/sites/<site>/constants.typoscript. The templates then render the header partial of EXT:fluid_styled_content above their output, for every header layout except Hidden. Do not switch it on where the layout renders the header: the header then appears twice.

The extension does not require EXT:fluid_styled_content. It adds the partial path of that extension below every other one, so a site package that ships a Header/All.html of its own renders that one instead, and a site without EXT:fluid_styled_content provides the partial that way.

For the header layout Default, the partial takes the heading level from plugin.tx_academiccontacts4pages.settings.defaultHeaderType , which is mapped from the constant styles.content.defaultHeaderType of EXT:fluid_styled_content. A site that does not include the TypoScript of EXT:fluid_styled_content sets the setting itself; without it, such a header renders as an empty <header> element.