Feature: Configurable public profile 

Description 

The public profile detail view - the output of the Persons Detail and Persons List and Detail content elements - is assembled from the profile map of Configuration/AcademicPersons/Settings.yaml instead of a fixed template. Its structure lists name the elements of the left and the right layout column in render order, and details says per element which profile properties, which contract data or which label it shows. The shipped file renders the section navigation on the left and, on the right, the headline, the contract positions, the image, the contact data, a subline, the fold-out profile entries, the link properties and the timeline sections; below the large breakpoint the navigation moves into the content column, directly before the subline element - an override that drops subline from the right column therefore has no mobile navigation. See The profile map.

Resources/Private/Templates/Profile/Detail.html receives the map as publicProfile and dispatches every configured element to a partial of its own below Resources/Private/Partials/Profile/PublicProfile/. An empty property or relation renders nothing, and so does an element identifier the template does not know.

Everything the old, static template rendered has an element: links carries the website and publicationsLink properties with their companion title properties, and the contact rows carry the type of each email address, phone number and postal address again. What the rebuilt view has no equivalent for are the two headings of its static sections, Contracts and Additional information - every block is a configured element now and carries its own heading. The label changes that follow from this are listed in Important: Label changes of the public profile.

The view renders no <main>, no <aside> and no <h1>: it is a content element, a page may carry two of them, and the page template owns those. Its headings start at <h2> for the headline and step down from there.

The view ships a small ES module for the fold-out entries, the sticky navigation and the Bootstrap ScrollSpy, loaded by the template through the asset collector. It ships no stylesheet, the site styles the view, see Breaking: The profile views ship no stylesheet. The seven control icons of the view are the shared frontend icons 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 of academic_base, rendered by its ab:icon ViewHelper. They are drawn in currentColor and inlined, so they take the text colour of the page. A site package replaces one in its own Configuration/FrontendIcons.php, see Breaking: Renamed icons and a frontend icon registry.

A theme that clips its content sections with overflow: hidden cuts off a sticky navigation of the left column - see How the layout is rendered for the one rule that lifts it.

Impact 

A site package changes the layout of the public profile and the fields it shows by shipping its own profile map, without replacing the detail template. The maps are merged key by key, so an override names the entries it changes; the lists inside them - a column of structure , the fields of a details entry - are replaced as a whole and are therefore repeated completely. Flush the TYPO3 caches after changing the file.

An installation that overrides Templates/Profile/Detail.html keeps rendering its own template; the publicProfile variable is available to it from now on. Such an override switches this feature off entirely, and it does so without any sign that it did: the page renders as it always did, the profile.structure and profile.details maps are read by the new partials only, and a change to either has no effect on that page. The timeline properties such an override prints - {item.year}, {item.yearStart}, {item.yearEnd} - are unchanged, so its entries keep rendering; what it loses is the layout, not the values.

The way back is to delete the override and configure the layout instead, or to re-derive the override from the shipped Detail.html, which is 45 lines and dispatches to the eleven partials below Resources/Private/Partials/Profile/PublicProfile/. Those eleven are the override surface now, and overriding one of them keeps the configured layout intact. Which partials the detail view stopped rendering, and which of them was deleted with it, is listed in Breaking: The partials of the detail view change.