Configuration 

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.

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.

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.

Include the site set 

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

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

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.

The category filters 

The filter form of the Projects and the Projects (selected) content elements offers one select per category type of the group projects. Three settings change which of them it offers and how, for the whole site:

plugin:
  tx_academicprojects:
    filter:
      categoryTypes: 'department,competence_field'
      visibleCount: 1
      hideDisabledOptions: true

The settings are site settings of the aggregate set fgtclb/academic-projects and constants of the same names for a site on static templates. A site that depends on one of the component sets alone gets the defaults, but the site settings editor does not offer the settings there — both content elements read them, and a set declares settings only for itself.

Site settings exist from TYPO3 v13 on. On TYPO3 v12, set the constants.

A type is offered only when at least one category of that type exists, and an identifier that is no type of the group is ignored. The settings decide what the form offers, not what the list accepts: a link that filters by a category of a type the form does not offer still filters the list.

plugin.tx_academicprojects._LOCAL_LANG {
  default.sys_category.projects.allOptions.competence_field = All competence fields
  de.sys_category.projects.allOptions.competence_field = Alle Kompetenzfelder
}

# Only in the Projects content element:
plugin.tx_academicprojects_projectlist._LOCAL_LANG.default.sys_category.projects.allOptions.competence_field = All competence fields

Content Security Policy 

The selects of the form of the Projects and the Projects (selected) content elements submit it when the visitor changes one of them, through the inline event handler onchange="this.form.submit()" . A nonce does not cover an event handler attribute, so the frontend policy of TYPO3 blocks it once a site enforces that policy. The extension therefore allows exactly this handler text in its Configuration/ContentSecurityPolicies.php, which TYPO3 loads on its own: the directive script-src-attr of the frontend policy gets 'unsafe-hashes' and 'sha256-osjxnKEPL/pQJbFk1dKsF7PYFmTyMWGmVSiL9inhxJY='. script-src is not changed. Every site that inherits the default frontend policy gets both sources. A site whose csp.yaml sets inheritDefault: false , and a site package whose copy of Project/DemandSorting.html, Project/DemandCategories.html or Project/DemandActiveState.html uses another handler text, add the hash of that text in the csp.yaml of the site:

mutations:
  - mode: extend
    directive: 'script-src-attr'
    sources:
      - "'unsafe-hashes'"
      - "'sha256-osjxnKEPL/pQJbFk1dKsF7PYFmTyMWGmVSiL9inhxJY='"

The hash is the base64 encoded SHA-256 of the handler text, without the quotes of the attribute. A policy the web server or a proxy sends is not covered and needs the same sources itself. This works the same on TYPO3 v12 and v13.

A site whose policy allows inline scripts already, with 'unsafe-inline' in script-src, or in default-src where it has no script-src, gets no script-src-attr from the extension: a listener of academic_base takes it out again, unless the site declares the directive itself. The browser then reads script-src for the handlers of the form, as for the site's own handlers. On a page whose script-src keeps a nonce, a browser ignores 'unsafe-inline' and blocks both. TYPO3 v12 never drops a nonce: a page that uses one, and every page with uncached content such as the plugins of this form, sends it.

For a visitor without JavaScript the form renders a submit button inside <noscript> , labelled filter.submit . A visitor with JavaScript does not see it.

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 and the settings of the category filters.

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.