Configuration

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 for what happens otherwise.

What the sets contain

This extension ships two content elements, so it ships two component sets, one set for the styles.content override described below, and one aggregate set that depends on all of them.

Both content elements are driven by one Extbase plugin, so they share one TypoScript block, plugin.tx_academicprojects. That block is shipped once, in Configuration/TypoScript/, and every component includes it. Which component sets a site names therefore decides which content elements the backend offers, not how much TypoScript is loaded.

Set	Delivers
`fgtclb/academic-projects-project-list`	The Projects content element.
`fgtclb/academic-projects-project-list-single`	The Projects (selected) content element.
`fgtclb/academic-projects-content-load`	The `styles.content.getContent` override only. No content element, and nothing this extension is otherwise made of — see The content load override.
`fgtclb/academic-projects`	Everything above. This is the set to use unless you deliberately want a subset, and it is the name this extension published before the sets were cut per component — a site configuration that depends on it needs no change.

Every content element set depends 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 elements are hidden by default

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

Warning

This changed in version 2.4. Before it, both elements were selectable on every page of every installation. Read Breaking: Site sets and static templates have been restructured before upgrading: opening an existing record on a page that does not include the page TSconfig of its component can rewrite the type of that record.

What the sets do not control

The page type Academic project (doktype 30) and its backend layout AcademicProject are not part of any set, and enabling or not enabling a set never changes them.

That is deliberate, not an oversight. Both are values stored on pages records: a page carries doktype = 30 and backend_layout = pagets__AcademicProject long before any site configuration is read. Were they delivered by an opt-in set, every page tree on a site that does not use that set would show [ MISSING LABEL ] for the layout, the layout could not be picked for a new page, and the page type would disappear from the page tree wizard.

They are therefore registered installation-wide — the page type in TCA (Configuration/TCA/Overrides/pages.php), the backend layout in the always-included Configuration/page.tsconfig — and stay available on every site of the installation.

What a set does deliver for that page type is its frontend rendering: the page object that picks the Fluid template of the page type is part of the shared TypoScript block, so a site that includes no set of this extension renders such a page with whatever its own site package defines.

The content load override

Configuration/TypoScript/ContentLoad/setup.typoscript redefines styles.content.getContent for the whole site so that it selects colPos = 0 only. This is an installation-wide rendering change, it applies to every page of the site and not only to the pages of this extension, and three academic extensions ship the same override.

It is therefore a set of its own, fgtclb/academic-projects-content-load. The aggregate set depends on it, so a site on fgtclb/academic-projects keeps what it had; a site that wants the content elements without the override names the component sets it needs instead of the aggregate.

Warning

The Fluid template of the page type renders styles.content.getContent through <f:cObject typoscriptObjectPath="styles.content.getContent"/>, and that ViewHelper throws when the path is undefined. A site that opts out of this set and still uses the page type has to define styles.content.getContent itself.

Include the site set

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

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

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

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

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

Entry	Delivers
Academic Projects: Projects (academic_projects)	The TypoScript of the Projects content element.
Academic Projects: Projects (selected) (academic_projects)	The same for Projects (selected).
Academic Projects: Content load override (academic_projects)	The `styles.content.getContent` override on its own.
Academic Projects: All components (academic_projects)	Every component this extension ships, in one entry.
Academic Projects: Shared plugin settings and page rendering (academic_projects)	The shared `plugin.tx_academicprojects` block and the `page` object of the page type, on their own. This is the entry an installation stored before the configuration was cut per component, and it keeps working — but it does not make any content element selectable, which the page TSconfig below does, and it no longer carries the content load override.

Include static page TSconfig

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

Entry	Delivers
Academic Projects: Projects (academic_projects)	Makes the Projects content element selectable, and configures its entry in the new content element wizard.
Academic Projects: Projects (selected) (academic_projects)	The same for Projects (selected).
Academic Projects: All components (academic_projects)	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

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 that is the plugin.tx_academicprojects constants block, the three Fluid root paths.

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.