---
title: "Configuration"
manual: "Academic Contacts for Pages"
version: "main"
source: "Configuration/Index.rst"
rendered: "2026-09-18T06:17:05+00:00"
---

# Configuration {#configuration-1}

This extension ships its frontend TypoScript and its backend page TSconfig in
two forms: as TYPO3 **site sets**, and as classic **static templates** plus
**page TSconfig files** that are selected on a page. Both forms read the very
same files, so they configure an installation identically.

Pick one of them per site and stay with it — see
[Do not combine both](#one-mechanism-per-site) for what happens otherwise.

## What the sets contain {#what-the-sets-contain}

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

| Set | Delivers |
| --- | --- |
| `fgtclb/academic-contacts4pages-list` | The **Contact list** content element: its TypoScript (`plugin.tx_academiccontacts4pages`), the data processor that assigns the contacts of a page to the page template, and the page TSconfig that makes the content element selectable in the backend. |
| `fgtclb/academic-contacts4pages` | Everything above. This is the set to use unless you deliberately want a subset. |

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.

> [!NOTE]
> The setup of this extension reads
> `{$plugin.tx_academicpersons.detailPid}` — a constant this
> extension does not declare and that belongs to
> **EXT:academic_persons**. Two further constants of that extension
> are mapped the same way, because the partials rendering a contact read
> them: the image placeholder
> `{$plugin.tx_academicpersons.image.placeholder.default}` and
> the phone link prefix
> `{$plugin.tx_academicpersons.phoneNumbers.telPrefix}`.
>
> Nothing has to be done about it. The component names that extension's
> TypoScript in its own `include_static_file.txt`, and both delivery
> mechanisms read that file, so the constant resolves whether this extension
> arrives through its site set or through its static template.
>
> The site set deliberately does *not* depend on a set of
> **EXT:academic_persons**. Such a dependency would not deliver the
> constant, and it would make that extension's content element selectable
> wherever this one is enabled.

## The content element is hidden by default {#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 {#include-the-site-set}

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

**config/sites/my-site/config.yaml (diff)**

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

See also [TYPO3 Explained, Using a site set as dependency in a site](https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/SiteHandling/SiteSets/Index.html#site-sets-usage).

## Include static templates {#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.

> [!TIP]
> On TYPO3 v13 and v14 we recommend the site set — and if you use it, do not
> press the backend button **Create a root TypoScript record** on that
> site. The `sys_template` record it creates carries the flag
> **Clear** for constants and setup, and that flag discards everything
> the site sets contributed. An installation that is already in that state
> gets its configuration back by selecting the static templates below in that
> very record.

### Include static TypoScript {#include-static-typoscript}

Edit the `sys_template` record of the site root and add the entry to
**Include static (from extensions)**:

| Entry | Delivers |
| --- | --- |
| **Academic Contacts4Pages: Contact list (academic_contacts4pages)** | The TypoScript of the **Contact list** content element. |
| **Academic Contacts4Pages: All components (academic_contacts4pages)** | Every component this extension ships, in one entry. |

### Include static page TSconfig {#include-static-page-tsconfig}

Edit the page record of the site root, tab **Resources**, field
**Page TSconfig**, and add the entry:

| Entry | Delivers |
| --- | --- |
| **Academic Contacts4Pages: Contact list (academic_contacts4pages)** | Makes the **Contact list** content element selectable, and configures its entry in the new content element wizard. |
| **Academic Contacts4Pages: All components (academic_contacts4pages)** | Every component this extension ships, in one entry. |

The setting is inherited by every page below the one it is set on.

## Do not combine both {#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.