General configuration 

Extension configuration There are some options for global extension configuration:

profile.allowedLanguages

profile.allowedLanguages
type

string

Default
 

A comma-separated list of language IDs. These IDs configure in which languages a persons profile can be translated by a frontend user.

The synchronisation into these languages runs after a profile is auto-created — on frontend user login or through the academic:createprofiles command of EXT:academic_persons — and after every change persisted through ProfileEditing. Left empty, frontend edits do not touch translated profile records at all.

Which fields can be edited 

Which profile fields belong to each visual section, how they are rendered, which are mandatory and which are locked is configured by EXT:academic_persons in Configuration/AcademicPersons/Settings.yaml. The single profile map contains both the public layout and the editable field definitions. Structured records use the documentSections map from the same file.

Consequences worth knowing before reporting a problem:

  • A field configured disabled or readonly is rendered locked. The ProfileEditing JSON endpoint rejects attempts to submit it.
  • First name, Middle name and Last name are locked by default, because profile names are usually owned by the connected frontend user record and synchronised from elsewhere. They are therefore not editable in the frontend form - and not in the TYPO3 record editor either: the same validation set is merged into the TCA of the profile table through TcaValidationMerger , where disabled becomes readOnly . Unlocking a field for the frontend form unlocks it in the backend as well.
  • Document validators are selected by the section's stored record type; validators from sibling sections are never merged as a fallback.
  • The normalized rules are applied to the frontend controls, server-side Extbase validation and the corresponding backend TCA field state.

See Profile editor and validation for the schema, supported validator flags, document aliases, shipped defaults and override rules. The same profile map also controls the public detail layout.

Image processing: WebP 

The ProfileEditing image editor offers the profile image as WebP through the <picture> candidates, with the <img> fallback in the source format. TYPO3 has to be allowed to produce WebP, otherwise rendering a profile that has an image fails with:

Unable to render image uri in "tt_content:1": The extension webp is not
specified in $GLOBALS['TYPO3_CONF_VARS']['GFX']['imagefile_ext'] as a valid
image file extension and can not be processed.
Copied!

On TYPO3 v13 and v14 webp is part of the default value of $GLOBALS['TYPO3_CONF_VARS']['GFX']['imagefile_ext'] , so nothing has to be done. An installation that removes it from that list - some restrict the allowed formats deliberately - has to put it back, either in Admin Tools > Settings > Configure Installation-Wide Options > [GFX][imagefile_ext] or in config/system/settings.php.

Permitting the format is not the same as being able to produce it: the configured image processor, GraphicsMagick or ImageMagick, has to be built with WebP support.