Configuration 

What the sets contain 

This extension ships two content elements, so it ships two component sets 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 of a project page 

A project page renders the content elements of its main column ( colPos = 0 ) below the project 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 projectContent of the page object, defined inside the condition on the project page type, so it exists on project 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") == 30]
  page.10.variables.projectContent {
    select.where = {#colPos}=1
  }
[END]

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

The layout of a project page 

A project 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-projects, 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 projectPageLayout 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 project page fails as any page with a missing Fluid layout does.

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

# PAGEVIEW: a directory holding Partials/Project/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-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 Selected Projects 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: 'project_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.

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

Active filters, reset link and result count 

Three switches add to the filter form of the Projects and Selected Projects content elements, for the whole site. All three are off by default.

plugin:
  tx_academicprojects:
    filter:
      showActiveFilters: true
      showReset: true
      showResultCount: true

The settings are site settings of the aggregate set fgtclb/academic-projects 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 or state: removing it shows the list without it, and the reset link brings the preset back.
• The category tags are shown only while the category filter is, and the state tag only while the state select is: a tag removes what the visitor could change. Where the content element hides both, 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 Project/ActiveFilters.html, the count from Project/ResultCount.html. Both are rendered by Project/SortingAndFilters.html, so a project that overrides that partial does not show them until it renders them as well. The partials use the classes ace-active-filters on the list of tags, ace-active-filter on a tag, ace-link on the links and ace-count on the 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 state of a project 

A project is active while it has no end date or its end date is still ahead, and completed once its end date has passed. The Active state filter of the project lists selects by that rule, and a template reads the same state from every project as {project.activeState} : active or completed, never empty.

A project page whose end date was never stored has no end date either, and is active. That is a page created in the page tree, a page switched to the project page type, an imported page or one from before the extension was installed, as long as no editor has entered an end date. The Active filter lists it, and the Completed filter does not.

<p class="ace-state completed">Completed</p>

The crop variants of the project page media 

The image cropper of the media of a project page offers three crop variants. A template requests one by its name, through the cropVariant argument of <f:image> or of the image partial of EXT:academic_base:

default is the variant TYPO3 offers when a file field configures none, with the same ratios, and the templates of this extension render it. A crop an editor stored before the update is stored under that name and keeps its meaning.

The variants belong to the project page type. The media of a standard page keeps what TYPO3 offers.

An image stores a crop for the new variants once an editor opens it in the backend form and saves the record. Until then a template that requests landscape or portrait renders the image uncropped. Where the image already has a crop for default, the cropper starts landscape from that crop, fitted into its ratio, and portrait from the whole image, fitted and centred; an image without a crop starts both from the whole image.

A site that does not want a variant disables it in TCA, on this field only. The extension configures the variants in its own TCA overrides, so the site package has to depend on academic_projects for its line to load later:

$GLOBALS['TCA']['pages']['types'][30]['columnsOverrides']['media']['config']['overrideChildTca']['columns']['crop']['config']['cropVariants']['portrait']['disabled'] = true;

Page TSconfig is not the way to do that. TCEFORM.sys_file_reference.crop.config.cropVariants reaches every image below the page it is set on, and on an image field that configures no variants of its own it leaves the cropper with no variant at all, not even default.

A project that defines crop variants of its own for the project page media does so at the same path. A variant it sets by name replaces the one of the same name and leaves the others; assigning the whole array replaces all of them.

Crop variants a project configures on the media field of every page, or on sys_file_reference for every image, are merged with these on the project page: the values of this extension win key by key, and a ratio the project adds to a variant of the same name stays. A project that restricted default to a fixed ratio that way therefore finds all the ratios of the TYPO3 default offered on project pages again, and the free ratio preselected on an image without a crop.

The header of the content elements 

The header and the subheader an editor enters on a Projects or Selected Projects 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_academicprojects.renderContentElementHeader = 1

On a site that uses the site set, that is the site setting Project lists | Render the content element header of fgtclb/academic-projects. 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_academicprojects.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_academicprojects constants block: the three Fluid root paths, the settings of the category filters 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 project 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.