Profile editor and validation 

Loading and overrides 

The central factory reads the same relative path from every active package and merges maps at the top level. A site package can therefore override the shared configuration by providing Configuration/AcademicPersons/Settings.yaml. Replacing one of the four maps replaces that complete map; repeat every entry which must remain.

Flush TYPO3 caches after a change so the unified typed settings graph and its cache entry are rebuilt.

Field validators 

Regular fields declare an ordered list of flags:

profile:
  website:
    section: information
    fieldType: input
    renderType: combinedLink
    validators:
      - url

Supported flags are:

Rules remain attached to the configured profile, contact or document section. They are not collected from a sibling section. Only submitted fields are validated during a partial AJAX update.

Profile CKEditor character limit 

A profile field configured as CKEditor may declare its character limit directly on the field:

profile:
  miscellaneous:
    section: aboutme
    fieldType: textarea
    renderType: ckeditor
    characterLimit: 1000
    validators:
      - html

A positive integer characterLimit adds a live current / limit counter and prevents the editor from accepting additional visible characters beyond the limit. The partial AJAX update is checked independently by the same server-side Extbase validation. HTML tags do not count. The property is ignored when renderType is not ckeditor or its value is invalid or non-positive. The key is case-sensitive; characterlimit is not normalized.

This deliberately differs from document descriptions, which keep their existing nested editor.limit schema. Both forms normalize to the same typed validation metadata. Character limits do not alter backend TCA or the database schema.

Document validators and aliases 

Document aliases map presentation names to DTO and database properties:

The shipped year rules are deliberately dynamic:

documentSections:
  cooperation:
    validators:
      from:
        - number
      to:
        - number
      year:
        - required
        - number

Consequently year receives a required attribute and marker while from and to remain optional. Removing or adding required in a site override changes the JSON metadata, the rendered controls, the Extbase validation and the corresponding backend TCA field state together; no field name is hard-coded as mandatory.

The richer description form remains supported:

description:
  editor:
    limit: 500
    type: ckeditor

editor.type: ckeditor is normalized to the html validation/input metadata so the editor and the server side sanitizer agree. A positive integer editor.limit additionally defines the maximum number of visible characters. HTML tags do not consume that allowance; entities, non-breaking spaces and repeated whitespace are normalized before counting. The editor returns the limit in its JSON field metadata, displays a live current / limit counter and prevents CKEditor from accepting further characters beyond it. Both the document JSON actions and the Extbase form-data validator enforce the same limit on the server.

editor.limit is frontend validation metadata, not TCA configuration. It is ignored for non-CKEditor controls, and removing it or setting it to a non- positive value disables both the counter and the additional validation without changing backend FormEngine.

Contract form and contact sections 

The order of contracts.fields is the form order returned by the JSON endpoint. Every entry declares its frontend field and render type, validation, option source and helptext together. The shipped organisationalUnits, functionTypes and locations option sources resolve their records through the corresponding repositories. Removing or reordering an entry therefore removes or reorders that control without changing the template.

Physical addresses, email addresses and phone numbers are ordered structural children below contracts.contactSections . Each child owns an ordered fields map and an isolated validation set:

contracts:
  type: contracts
  fields:
    position:
      fieldType: input
      renderType: text
      validators:
        - required
    organisationalUnit:
      fieldType: select
      renderType: select
      options: organisationalUnits
  contactSections:
    physicalAddresses:
      fields:
        country:
          fieldType: input
          renderType: select
          autocomplete: country
          helptext: 'LLL:EXT:site/Resources/Private/Language/locallang.xlf:address.country.helptext'
          validators:
            - required
    emailAddresses:
      fields:
        emailAddress:
          propertyName: email
          fieldType: input
          renderType: email
          autocomplete: email
    phoneNumbers:
      fields:
        phoneNumber:
          fieldType: input
          renderType: phone
          autocomplete: tel

documentSections:
  contracts:
    type: contracts

The shipped physical-address country control obtains its localized labels and ISO alpha-2 values from TYPO3's CountryProvider. Keeping fieldType as input preserves the domain extension's existing backend TCA while renderType: select selects the frontend control and its option validation. Every Contract and contact field helptext is rendered as a Bootstrap popover in add/edit mode.

The shipped autocomplete tokens are street-address, postal-code, address-level2, country, email and tel. They describe the purpose of the corresponding control without changing validation or storage.

Backend TCA integration 

The domain extension still owns the base TCA and the column configuration. It applies the normalized validation metadata from the unified settings graph to the relevant Profile, contact and Profile-information TCA fields. Consequently required, readonly and field-type metadata remain consistent between frontend validation, profile editing and FormEngine in TYPO3 13 and TYPO3 14. Character limits remain frontend/server-side metadata and do not change the database schema.

Year row 

year, yearStart and yearEnd each receive col-12 col-md-3. They therefore stack on small screens and share one row from the medium breakpoint. Each is an <input type="number"> carrying the bounds of its TCA range as min, max and step.