Configuration 

What the sets contain 

This extension ships four content elements, so it ships four component sets and one aggregate set that depends on all of them.

All four content elements are driven by one Extbase plugin, so they share one TypoScript block, plugin.tx_academicpartners . 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_partners hides all four 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 partner (doktype 40) and its backend layout AcademicPartner 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 = 40 and backend_layout = pagets__AcademicPartner 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 of a partner page 

A partner page renders the content elements of its main column ( colPos = 0 ) below the partner data, in their manual order and in the language of the page. Any set of this extension, or the static template of the shared block, delivers that, and no other set is needed for it.

The content is the variable partnerContent of the page object, defined inside the condition on the partner page type, so it exists on partner pages only. It is a CONTENT object that renders the records through the tt_content object of the site, and it works for a FLUIDTEMPLATE and a PAGEVIEW page object alike.

To render another column, or to slide the content from the parent pages, change the variable inside the same condition:

[page && traverse(page, "doktype") == 40]
  page.10.variables.partnerContent {
    select.where = {#colPos}=1
  }
[END]

A page template of your own renders it as {partnerContent -> f:format.raw()} .

The layout of a partner page 

A partner page renders inside the page layout of the site package, the way the other pages of the site do: the page template declares a layout and fills its section Main . The layout is Default unless a setting names another one, which is what bk2k/bootstrap-package and most site packages provide.

It is a site setting of the aggregate set fgtclb/academic-partners, and a constant of the same name for a site on the static templates. A site that depends on a component set alone gets the default, but the site settings editor does not offer the setting there. Depend on the aggregate set to configure it.

The page template reaches it as the variable partnerPageLayout of the page object, so it works on a FLUIDTEMPLATE and a PAGEVIEW page object alike.

A site package without a layout Default gets the fallback layout of this extension, which renders the section Main and nothing else: the page renders without the header, navigation and footer of the site, as it did up to 2.x, rather than failing. A layout Default of the site package wins over it. The fallback exists for Default only: a layout the setting names has to exist in the site package, or the partner page fails as any page with a missing Fluid layout does.

# FLUIDTEMPLATE: a directory holding Partner/Page/Header.html
page.10.partialRootPaths.75 = EXT:my_sitepackage/Resources/Private/Partials/

# PAGEVIEW: a directory holding Partials/Partner/Page/Header.html
page.10.paths.75 = EXT:my_sitepackage/Resources/Private/

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-partners

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.

Pagination of the partner list 

The Partners List content element can split its partners into pages. Whether it does, and how many partners a page holds, is set on each content element, tab Pagination:

How many page numbers the navigation links at once is one value for the whole site:

The site setting is declared by the set fgtclb/academic-partners-list, so the site settings editor offers it to a site that depends on that set or on fgtclb/academic-partners. A site configured through static templates sets the constant instead.

Every page link keeps the active filter and sorting, and a filter submission starts on page one. The Partners Map is never paginated.

The category filters 

The filter form of the Partners List and the Partners Map offers one select per category type of the group partners. Three settings change which of them it offers and how, for the whole site:

plugin:
  tx_academicpartners:
    filter:
      categoryTypes: 'sdg,region'
      visibleCount: 1
      hideDisabledOptions: true

The settings are site settings of the aggregate set fgtclb/academic-partners and constants of the same names for a site on static templates. A site that depends on fgtclb/academic-partners-list or fgtclb/academic-partners-map 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.

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_academicpartners._LOCAL_LANG {
  default.sys_category.partners.allOptions.region = All regions
  de.sys_category.partners.allOptions.region = Alle Regionen
}

# Only in the partner map:
plugin.tx_academicpartners_map._LOCAL_LANG.default.sys_category.partners.allOptions.region = All regions

Active filters, reset link and result count 

Three switches add to the filter form of the Partners List and the Partners Map, for the whole site. All three are off by default.

plugin:
  tx_academicpartners:
    filter:
      showActiveFilters: true
      showReset: true
      showResultCount: true

The settings are site settings of the aggregate set fgtclb/academic-partners and constants of the same names, like the filter settings above.

• A tag shows a category in the language of the page.
• A tag stays a tag when the editor preset its category: removing it shows the list without that category, and the reset link brings the preset back.
• Where the content element hides the filter, the visitor cannot change it, and neither tags nor the reset link are shown. The count is.
• Every selected category is a tag, also one whose type the form does not offer (see the filter types above), for example a preset one. Removing it works like for any other tag.
• The tags and the reset link come from the partial Partner/ActiveFilters.html, the count from Partner/ResultCount.html. Both are rendered by Partner/SortingAndFilters.html, so a project that overrides that partial does not show them until it renders them as well. The partials use the classes academic-partners-active-filters (with __tags, __tag, __remove and __reset) and academic-partners-result-count, and bring no styles.
• The reset link needs the variable {visitorSelection} , which the list action assigns. A template that renders the partials with arguments of its own has to pass it on, or the list offers no reset link.
• The labels are filter.activeFilters.label , filter.activeFilters.remove , filter.reset , list.resultCount.singular and list.resultCount.plural of this extension. The count labels take the number as %d, the remove label the category title as %s.

The partner map 

The Partners Map content element draws its partners on a map, with the tiles of OpenStreetMap by default. Where the map is centred, how far it zooms and where its tiles come from is one configuration for the whole site:

plugin:
  tx_academicpartners:
    map:
      centerLatitude: 47.5162
      centerLongitude: 14.5501
      zoom: 7
      maxZoom: 14

The settings are site settings of the set fgtclb/academic-partners-map, so the site settings editor offers them to a site that depends on that set or on fgtclb/academic-partners. A site configured through static templates sets the constants instead.

The defaults are the values the map used before they could be configured, and the map falls back to them for every value it cannot use: an empty value, a number that is not a number or lies outside its range. The centre is one value, so a latitude it cannot use discards the longitude as well. An empty tile URL or attribution uses the default, because a tile server's terms usually require an attribution. Whether the tile server delivers tiles up to the maximum zoom, and what its attribution has to say, is up to the site.

<f:render partial="Partner/Map" arguments="{partner: partner, map: mapSettings}" />

The header of the content elements 

The header and the subheader an editor enters on a Partners List, Partners Map, Partnerships List or Partnerships Teaser 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_academicpartners.renderContentElementHeader = 1

On a site that uses the site set, that is the site setting Render the content element header in the plugins of fgtclb/academic-partners. 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_academicpartners.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.

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_academicpartners constants block: the three Fluid root paths, the number of page links of the pagination, the settings of the category filters and of the partner map, 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.

Search, permissions and the wizard 

The Integration chapter of academic_base covers what an installation runs beside the academic extensions: an index queue for partner pages with EXT:solr, the tables, fields and content types an editor group needs as a preset for b13/permission-sets, and how to move, rename or order the academic content elements in the new content element wizard.