Profile sections 

The contracts of the position and contact blocks 

A block rendered with special: datasFromContracts chooses which of the profile's contracts it renders. The shipped file states the defaults:

profile:
  details:
    position:
      special: datasFromContracts
      contracts: all
      onlyValid: false
      fields:
        - position
    contact:
      special: datasFromContracts
      contracts: all
      onlyValid: false

contracts

all renders every contract, first only the first in the editor's order that onlyValid leaves. Anything else is all.

onlyValid

true leaves out the contracts that have ended or not started yet, and limits the page cache lifetime as described in The page cache follows the validity. A boolean, or a value PHP reads as one (1, 'true', 'yes', 'on'); anything else is false.

The two blocks are configured one by one, so a profile page may list every position and the contact data of the first contract only. The unit and function type filter of the list elements has no counterpart here: the detail view shows one profile, not a restricted list. See Which contracts a profile shows for how the options of the content elements relate.

What the position line shows 

profile.details.position.fields lists what the position line shows of each contract, in this order. Three values are accepted:

position

The position text of the contract.

functionType

The name of the contract's function type. A profile with the gender ms gets the female name and one with mr the male name, where the function type has one. Every other profile, and a function type without the gendered name, gets the general name.

organisationalUnit

The display text of the contract's organisational unit, or its unit name where the display text is empty.

The shipped value is [position] , the line as it was before the key existed. Other values are dropped, and a list that keeps none of the three is the shipped value. A contract that has none of the listed values gets no line.

Settings files merge key by key, so a site package that wants the function type next to the position states only the list:

profile:
  details:
    position:
      fields:
        - position
        - functionType

Each value is rendered in an element of its own, an ace-value with the class of its field: ace-position, ace-function-type or ace-organisational-unit. The values of one contract share one line, ace-attribute ace-position-line. The stylesheet of the site separates them, the example of How the layout is rendered with a comma.

How the layout is rendered 

The shipped Resources/Private/Templates/Profile/Detail.html receives the two keys as publicProfile and dispatches every identifier of structure to a partial of the same name below Resources/Private/Partials/Profile/PublicProfile/:

Overriding a partial changes how an element renders, overriding profile changes what renders and where. The years of a timeline entry are printed as they are stored - a single year, a range, or an open range prefixed with a "since" or "till" label - and nothing about them is locale dependent.

Below the large breakpoint the elements of the left column are rendered a second time, directly before the subline element of the right column. A layout without subline in right therefore has no mobile navigation.

The view is a content element and renders no <main>, no <aside> and no <h1> - a page may carry two profile plugins, and those belong to the page template. Its headings start at <h2> for the headline, with the block headings one level below it.

The template loads the module @fgtclb/academic-persons/frontend/profile.js through the asset collector. The module toggles the fold-out entries, keeps the sticky navigation below a page header with the id page-header and, when the site loads Bootstrap, marks the section in view through its ScrollSpy. The icons of the contact rows and the fold-out entries are the shared identifiers tx-academicbase-info-email, tx-academicbase-info-phone, tx-academicbase-info-location, tx-academicbase-info-room, tx-academicbase-info-time, tx-academicbase-action-expand and tx-academicbase-action-collapse. They are frontend icons, registered in the Configuration/FrontendIcons.php of academic_base and rendered by its ab:icon ViewHelper. A site package that depends on academic_base replaces a glyph by registering the identifier in its own Configuration/FrontendIcons.php, an entry in its Configuration/Icons.php does not reach the detail view. The replacement applies wherever an academic extension renders the identifier. To replace an icon on the profile only, override the partial and render an identifier of the site package. The icons are Font Awesome Free icons, see Third-party icons.

The extension ships no stylesheet, the site package styles the view through its speaking ace-* classes, see The profile detail. Two parts of the view depend on rules of that stylesheet: a fold-out entry renders its expand and its collapse glyph and the stylesheet shows the one that matches its aria-expanded state, and the navigation of the left column is only sticky when a rule makes it so. The shipped icons carry a size of their own, 1em. A replacement drawing without a width and a height of its own needs a rule that sizes the icon, as the example below sizes it to its container. The module keeps a sticky navigation below the page header and writes the offset to --academic-persons-detail-scroll-offset on the root element.

The mono repository the extension is developed in carries an example to start from, the stylesheet of its development instances: _academic-persons.scss of EXT:academics_dev_site. It themes the view through custom properties declared on the .academic-persons-detail root element, and touches nothing outside that element. The development versions of 3.0 shipped it with the extension, see Breaking: The profile views ship no stylesheet.

body:has(.academic-persons-detail) .my-theme-section {
    overflow: unset;
}

What an override of the detail template loses 

Until 2.4 Templates/Profile/Detail.html was the view: it rendered the image, the contact data and every timeline section itself. Since 3.0.0 it is a dispatcher over the structure map, and the eleven partials below Partials/Profile/PublicProfile/ are what renders.

A project that overrides the template keeps rendering its own copy. Nothing looks broken, and two things are silently gone:

• The configurable layout. profile.structure and profile.details are handed to the template as publicProfile and are read by the new partials only, so changing them has no effect at all while the old template renders.
• Three partials the detail view no longer renders. Partials/Profile/Header.html and Partials/Profile/SectionHeader.html are still shipped and still rendered - by the list and card views, and by the profile editing view of academic_persons_edit - so an override of one of them made for the detail view no longer reaches it. Partials/Profile/DataHeader.html had the detail view as its only caller and is deleted: a project template that still renders Profile/DataHeader fails at render time rather than rendering nothing. Breaking: The partials of the detail view change has the migration.

Adopt the new template instead, and move the project's changes into the partial of the element they belong to: they are one file per element, and overriding one of them is what How the layout is rendered describes.

The fields 

Every other key is a field, and fields share one shape across profile , contracts.fields and contracts.contactSections.<section>.fields :

A field is dropped silently when it has no section (profile fields), no fieldType or no renderType . Removing a field from the file removes it from the editing frontend and from the validation; it never removes a column or stored data. Apart from a project field, the settings describe columns and properties the extensions ship and create none.