Profile editing 

Assigned profile overview 

ProfileController::listAction() is the default action. It uses the authenticated frontend-user relation and passes {profileListItems} to Resources/Private/Templates/Profile/List.html. Every item contains the Profile object and the title of its sys_language_uid from the current site configuration. The profile column contains a square thumbnail or the shipped placeholder followed by the complete name. Edit passes the explicit profileUid to indexAction(); the action resolves that UID again through the authenticated user's assigned profiles before rendering anything. An unassigned or manipulated UID receives the 403 access denied response of the site, the same one an unauthenticated visitor gets — raised as a propagated response rather than returned by the action, because on TYPO3 v13 the status code of an Extbase plugin response never reaches the frontend response.

The View URI uses extension academicpersons, controller Profile, action detail and plugin Detail. Its target page comes from plugin.tx_academicpersons.detailPid and must contain the academicpersons_detail content element. The ProfileEditing TypoScript copies the Academic Persons constant into plugin.tx_academicpersonsedit.settings; there is no separate editor-specific detail PID. Importing EXT:academic_persons/Configuration/Routes/Detail.yaml is optional and turns the query-string link into a speaking URI.

View data 

The controller assigns the following variables to the Fluid template:

View structure 

The template is intentionally a composition root. The main partial groups are:

Layout and responsive behavior 

The view uses Bootstrap 5 grid, spacing, typography, background, positioning and form utilities; the Fluid templates contain no inline style declarations. Resources/Public/Css/frontend/profile-editing.css is generated from Resources/Private/Scss/frontend/profile-editing.scss by the repository build and holds only what Bootstrap cannot express: the display: block the custom elements need, a [hidden] rule that outranks Bootstrap's display utilities, three corrections to a surrounding theme (a .section overflow, one frame spacing variable, the stacking of the sticky card), the focus ring of the controls and buttons, the drag states of a sortable list and the enter/leave classes of the two editor transitions. All Bootstrap button controls of the shipped editor carry rounded-0 so their corners remain square.

The focus ring is the one appearance the view takes away from the surrounding theme rather than correcting. Bootstrap draws it with box-shadow, several themes layer further opaque rings behind that one, and a translucent accent ring over an opaque black one reads as a hard dark rectangle around the focused control. A shadow is also the wrong mechanism twice over: it is painted outside the border box, so the overflow: hidden of the two collapse panels cut the ring off the fields and buttons inside them, and forced-colours mode drops shadows altogether while the rules that draw them also set outline: 0, which leaves the appearance in that mode to the browser rather than to the site.

The view therefore draws its own ring as a real outline on :focus-visible — the pseudo-class the theme's own rules use, so the rule sits exactly where the defect is — sunk inside the border box with a negative outline-offset so that no ancestor can clip it, coloured with currentcolor so that it contrasts with whatever the control it sits on is filled with, and it rewrites box-shadow in the same rule so no layered ring and no inset shadow survives underneath. It applies to every input, select, textarea and button the view renders — the five controls of Partials/Profile/Field/Control.html, the image upload of Partials/Profile/Image/Editor.html, the synchronisation switch of Partials/Profile/Header.html and the buttons of every action group — because two focus appearances in one form would be worse than the one being replaced.

:focus-visible is not a synonym for keyboard focus. Measured in Chrome, a pointer click on a checkbox or on the synchronisation switch does not match it and those two keep Bootstrap's soft glow, while a pointer click on a text input or a select does match it and those take the inset ring. Most of what the view renders is in the second group, so the change is visible to a visitor using a mouse and not only to one using the keyboard. The colour is currentcolor, which is the colour a control draws its own text in — but not the colour of a checkbox tick or a switch knob, which Bootstrap paints as a background image with a hardcoded #ffffff. On those two the ring takes the inherited body colour, #212121 on the #577760 of a checked control with the shipped theme, and measures 3.23:1: enough for WCAG 2.1 SC 1.4.11 and no more, so a site with a darker $primary has to check that pair. Plain links are not covered, no theme rule takes their focus ring away. CKEditor 5 is covered by halves: its editable region is a div, so it is outside the rule and keeps the library's own focus styling, while the buttons of its toolbar are button elements below the plugin root and take this ring rather than the library's. That is the same answer as everywhere else - one focus appearance for everything the visitor can focus.

Above the grid, the complete profile name and the synchronization/edit-all controls share one responsive header row. The controls wrap below the name on narrow viewports. On lg and larger viewports the first content row uses a 4 / 8 column split. The profile image block has sticky-top so the image and its edit action stay visible while the profile data scrolls. Below lg both columns stack in document order. The about section follows the complete first row and therefore never overlaps the sticky column.

At runtime initializeStickyImageOffset() reads the visible outer height of #page-header.navbar-fixed-top through getBoundingClientRect().height, adds a 10-pixel visual gap and assigns the result to the top property of data-pe-sticky-image. The measurement itself is observePageHeaderOffset() of academic_persons, which the public detail view uses for its own sticky navigation — one implementation, two callers. A ResizeObserver watches the header's border-box and keeps the offset synchronized whenever the navbar changes height, including height or padding changes caused by a scroll-dependent header state. Environments without it use the window resize event as a fallback. If the matching fixed page header is absent, Bootstrap's regular sticky-top value remains in control.

The two columns live in their own align-items-stretch row. The image column inherits the stretched cross-axis size, giving the sticky image a containing block as tall as the adjacent profile data. The full-width about section keeps its own col-12 in a separate sibling row below it.

The complete profile name is the page's h1 above both columns. Both Fluid and JavaScript use the ordered fields list from special.title . Fluid renders the initial name; data-pe-profile-name-field-ids lets JavaScript recompose the same name after a successful update without reloading the page.

Profile values are rendered as readable text rows with alternating bg-body-tertiary surfaces. The only read-mode action is a borderless pencil button with an accessible label. Name components and the URL/title pair of each link share one preview row and open as one editing group. Only one field or group is ever open: a second pencil, and Edit all, discard the one that is open before they open theirs (Two editing modes). The special name editor retains the established responsive grid (academic title / first name at 4 / 8 and middle / last name at 6 / 6) without putting layout metadata into YAML.

Settings-driven controls 

ProfileSectionProvider converts the typed profile and special settings into an ordered Fluid view model. Section placement itself remains explicit in Templates/Profile/Index.html: the template decides where profileSections.information and profileSections.aboutme appear. It does not enumerate their individual fields.

Profile/Fields.html chooses the field control solely from renderType. Option values are not duplicated in YAML: for a select field, ProfileFieldOptionsService reads the corresponding Profile TCA items. Preview behavior likewise follows the rendered control type. Removing a special component removes its controls; marking the image or synchronization special readonly or disabled also blocks the matching write endpoint, not just its Fluid control.

A translated profile initially uses TYPO3's parent localization state for the image and follows changes to the default-language image. The first upload or deletion in that frontend language changes the image field to custom; the translated profile then owns its FAL reference and can select, replace or delete its image independently. The image controls therefore remain available while editing a translated profile; the endpoint still verifies that the requested profile is assigned to the authenticated frontend user.

The shared Resources/Private/Partials/Profile/Field/Editable.html partial composes three focused, reusable partials:

• Field/Preview.html renders the text preview and pencil trigger — the trigger that opens this field and closes whichever other one is open,
• Field/Control.html renders either f:form.textfield or f:form.textarea, including the CKEditor hook, and
• Field/Actions.html renders delete, cancel and save.

Field/Group.html composes related textfields below one preview. Its data-pe-field-ids value defines which fields open, cancel and save together; data-pe-display-field-ids and data-pe-display-mode control whether the preview joins values (the name) or uses the first non-empty value (link title falling back to its URL).

Helptext buttons are edit controls: field and group previews do not render them. They appear after the corresponding field editor is opened. Document helptexts follow the same rule and are present in add/edit forms, but not in a document editor opened in view mode.

validation.inputType supplies the concrete HTML input type. Checkbox controls save immediately on change. Select controls use the same clear, undo and save actions as text fields. The synchronization switch in Header.html is persisted through its own endpoint.

Two editing modes 

The profile fields have two mutually exclusive editing modes, and the controls say which one is active.

Single field. The pencil beside a value opens that field — or, for a group, that group — and the three buttons of Field/Actions.html act on it: clear empties the control and keeps it open, undo restores the saved value and closes it, save posts what changed. This is the mode described everywhere else on this page, and the editors of the document and contract panels behave the same way.

Only one editor is open at a time — one field or group, the whole form, one document row or one contact of a contract. Opening another one, and entering full form editing, closes the one that is open first. An editor that still holds the values it was opened with closes silently, exactly as its own Undo or Cancel would close it. An editor with changes does not: the view asks, in a dialog of its own rather than a browser prompt, whether to Save and continue, to Discard changes or to Keep editing. Saving stores exactly what the open editor's own save would store and then opens the other editor; a save the server refuses keeps the visitor in the refused editor with its messages, and opens nothing. Discarding puts the editor back to the stored values and announces it in the polite live region: Unsaved changes were discarded. Keeping — and Escape in the dialog — opens nothing at all. Pressing the pencil of the field or group that is already open changes nothing and keeps what has been typed.

The dialog is the unsaved-changes template of Partials/Profile/UnsavedChanges.html, a <dialog> element the view clones and shows modally; its labels are the extension's own and are overridable with the partial. A site that drops the template leaves the visitor in the editor that is open: nothing is thrown away because a template is missing.

Full form. Edit all opens every editable field of the profile at once. While it is open, every per-field and per-group button group is hidden — including the undo beside an autosaving checkbox — and one bar governs the whole form. Field/FormActions.html renders it at the end of every data-pe-fields-form, and the shipped template has two of those (personal data and about me); each bar acts on all of them.

updateAction() validates the complete field map before it persists anything, so an apply either stores all of it or none of it. A refusal reverts nothing: the entered values stay where they were entered, each refused field is marked and described by its own message, the caret goes to the first of them, and the refusal is announced once rather than once per field.

While an apply is on its way to the server, Undo, Discard, Edit all and Escape do nothing. The request cannot be taken back, and reverting under it would leave the stored profile and the editor's own baseline disagreeing without anything on screen saying so.

The same holds for a save beside a single field: because opening an editor now discards one, a pencil, Edit all and the Delete content and Undo beside a field or group do nothing at all while such a save is on its way — not even open the editor that was asked for. All of them work again as soon as the answer has been written back, and while they do not, they say so in the polite live region: Please wait until the change has been saved.

A request that the server accepts and never answers therefore leaves the editors of that profile refusing until the page is reloaded. The frontend deliberately sets no timeout on its requests, so nothing here decides on the visitor's behalf that a slow save has failed.

A pencil pressed while Edit all is open does nothing at all, and says nothing: every field is already open, and the form's own bar is the way out of the mode.

A checkbox that saves on change does not save while the form is open — it is applied with everything else. Without that it would reach the database while the visitor is still deciding and Discard could not take it back. The synchronization switch of Header.html is outside the field forms and keeps saving immediately.

Generic field update 

The URL is generated by f:uri.action for updateAction() with page type 1733735 (see The page type of the JSON endpoints). Requests must use POST, Content-Type: application/json and the request header X-Requested-With: XMLHttpRequest (see The request header the endpoints require). Only values changed since the last successful save are sent. An empty string clears a property when its section-local validation permits an empty value; omitted properties remain unchanged.

{
  "profile": 123,
  "data": {
    "gender": "female",
    "website": ""
  }
}

Unknown profile properties, configured read-only/disabled fields and select values not configured in the matching TCA field are rejected. The direct academic/honorific profile.title field is an ordinary configured Profile property; the composed display name is special.title . skipSync is a direct special property. A configured combinedLink additionally enables its matching *Title companion. All other writable Profile properties come from profile . Extbase validation errors are returned in an errors object keyed by property path and are mapped back to the corresponding form controls by the frontend module.

ProfileFieldOptionsService supplies both the presentation options and the strict allow-list validation for every configured select. Thus another select does not require a new Fluid partial, validator service or JavaScript branch.

Rich-text content fields 

The shipped configuration marks five profile properties with renderType: ckeditor . Four are displayed with the information section, while miscellaneous belongs to aboutme :

• coreCompetences,
• teachingArea,
• supervisedDoctoralThesis,
• supervisedThesis, and
• miscellaneous.

The editor is TYPO3's shipped CKEditor 5 from the typo3/cms-rte-ckeditor package. The profile/rich-text.js module imports its CKEditor modules through TYPO3's JavaScript import map; it does not load an editor from a CDN. An editor instance is created lazily when a rich-text field is opened. If initialization fails, the original textarea remains available and the component reports an error.

The toolbar intentionally exposes only undo, redo, bold, italic, bulleted lists, numbered lists and links. Editor changes are mirrored into the underlying textarea, so required-field validation, changed-value detection and the existing JSON request remain the single persistence path. CKEditor's initial HTML normalization becomes the local comparison baseline; merely opening an editor therefore does not submit or rewrite legacy content.

Profile fields may configure a positive characterLimit next to renderType: ckeditor. Fluid then adds the limit metadata and an accessible live counter to that field. The shared rich-text module counts normalized visible text, keeps the last accepted value when an addition would exceed the limit and still allows older over-limit content to be shortened. The Extbase validator checks the submitted sanitized value again before the partial update is persisted. The shipped miscellaneous field uses a limit of 1000.

Outside edit mode, each rich-text field renders its formatted content directly and provides a borderless pencil action on the right. Empty values show a localized placeholder. The preview is initially rendered through TYPO3's HTML formatting pipeline and is replaced after a successful save with the sanitized markup returned by the server. The frontend applies the same strict tag, attribute and URI-scheme allowlist without assigning markup through innerHTML.

Each open text or rich-text field has three explicit actions. For renderType: ckeditor only, the action group sits in the label row with Bootstrap's ms-auto utility, leaving the editor itself full width. Other field types retain the action group beside their control. Selects and checkboxes save immediately when their value changes.

• Delete (data-pe-dismiss) clears the current browser-side draft. The editor stays open and no request is sent.
• Cancel (data-pe-cancel) restores the last successfully persisted value and closes only that field. No request is sent.
• Save (data-pe-save) sends that field through the JSON AJAX endpoint. It closes the field only after a successful response or when there is no changed value to persist.

The action group uses Bootstrap utility classes to remain content-sized and align itself to the end of the editor row instead of stretching to the CKEditor height. No additional stylesheet or inline style is required. The Edit all toggle beside the page heading opens both regular fields and grouped rows, receives Bootstrap's active state and changes its label to Close all. Activating it again collapses every editor without saving or discarding browser-side drafts. There is no global footer action area; save and undo remain explicit per-field actions.

The pencil is rendered through TYPO3's core:icon ViewHelper. Template overrides may replace the icon but must retain the button's edit hook, data-pe-for target and accessible label. The profile value itself must not be placed back inside the button.

Editable structured profile sections 

The profile editing view renders the structured records directly below the About me field. ProfileDocumentSectionProvider supplies one ordered view model instead of duplicating relation mapping in Fluid. It reads all sections, including contracts, from the shared settings graph. That graph is built from the active packages' EXT:academic_persons/Configuration/AcademicPersons/Settings.yaml files, so configured order is also presentation order. The same graph supplies the public profile, frontend validation and backend TCA metadata.

For every document section the provider reuses the configured identifier, fieldName, record type, LLL label, readonly state, rowFields, actions and the section-local validations. The heading is translated directly from that label. A newly configured type consequently does not require another section registry in academic_persons_edit. The generic localized empty state is used until an identifier-specific message is added.

contracts contains FGTCLB\AcademicPersons\Domain\Model\Contract objects. Every other collection contains FGTCLB\AcademicPersons\Domain\Model\ProfileInformation objects. Contract rows show the configured values, which are start date and position in the shipped settings. Profile-information rows render only the configured values in their declared order. The aliases from, to and description map to yearStart, yearEnd and bodytext. All sections remain visible when empty and display a localized empty state.

The three year properties year, yearStart and yearEnd are four digit integers stored in nullable int columns. Their add/edit control is an <input type="number"> carrying min="0", max="9999" and step="1" - the bounds of the TCA range of the same columns, which the endpoint enforces again on every submission, so a client that ignores them is refused rather than clamped. Nothing about a year is formatted and nothing follows a locale.

The three controls each use col-12 col-md-3 and share one responsive row on medium and larger viewports. Their HTML and server-side required states come from the same validation set: only a field with the additional required flag must be filled. In the shipped settings this applies to year but not to from or to.

The two Contract dates validFrom and validTo are the only date fields of the editor, and their control is a plain <input type="text"> showing d.m.Y behind the hint dd.mm.yyyy - the control the previous editor had. It is not an <input type="date">: the native control follows the locale of the browser rather than the one of the site, it cannot be styled with the rest of the editor, and its calendar is not the date picker this editor is meant to get. A date picker is deliberately not shipped yet. It is a feature of its own, it will not be the browser's, and until it exists the date is typed.

The endpoint accepts two formats for such a field. d.m.Y is what the control shows and submits. Y-m-d is what the endpoint answered and accepted while the control was a native one and stays accepted, so a client written against that shape keeps working. Both are read strictly - the parsed date is formatted back and has to match what came in, so 32.01.2026 is refused rather than read as the first of February - and anything that is neither format is refused with The value must be a valid date. The read view is unaffected: a stored date is rendered as the MEDIUMDATE of the site language, the way the public profile renders it.

Profile-editing development boundary 

academicpersonsedit_profileediting is the only profile-editing content element offered in the backend CType selector and new-content-element wizard. All profile-editing behavior is implemented through the Profile template and partial tree, ProfileController AJAX actions and the inline JavaScript component. The former dedicated controllers and their Fluid trees are removed; they are not compatibility entry points.

The ProfileEditing TypoScript, AJAX page type, site set and page TSconfig live in their own Configuration/*/ProfileEditing components. ProfileEditing is the only component enabled through either its component configuration or the aggregate.

The ProfileEditing functional test setup reflects the same boundary. It uses a dedicated academicpersonsedit_profileediting fixture and the neutral AbstractFrontendProfilePluginTestCase base.

Synchronization checkbox 

The synchronization checkbox appears as the compact Private switch immediately left of the Edit all/Close all toggle in the page header and is persisted immediately through updateSkipSyncAction(). Its form is a sibling of the profile form, not a nested form. Its presence and writable metadata follow the special.skipSync configuration; the underlying data and endpoint semantics remain skipSync. It does not submit or mutate any other field. The endpoint accepts exactly one boolean property:

{
  "profile": 123,
  "data": {
    "skipSync": true
  }
}

Any additional property or a non-boolean value returns invalid_payload. On failure the JavaScript restores the last successfully persisted checkbox state.

Expanding profile image editor 

Clicking the compact edit button below the current profile image or its placeholder keeps the profile view active. Partials/Profile/Image/Editor.html is rendered by Fluid into a dedicated full-width target above the profile header, data-pe-image-editor-target, which is where it is shown: it is hidden until the editor is opened rather than inserted then, so the container contributes its final width and height from the first paint and the cropper can initialize with the complete available width. The header, profile fields and structured sections remain in the same profile flow below the cropper; no separate view or overlay is involved. While the editor is open, the complete image-preview column is hidden and the profile-fields column changes from col-lg-8 to col-lg-12. The editor itself uses a bordered, padded surface. Closing it scrolls the restored image-preview column into view and focuses its edit action without causing a second browser scroll. The focus is restored only after two animation frames have applied the collapsed layout. A 1.5rem scroll margin keeps the restored preview clear of the viewport edge.

<academic-persons-edit-image-editor> is the element that drives that partial. It renders nothing of its own — the <f:form> carries the __trustedProperties signature the property mapper validates the upload against, and only the server can produce that — so it is a controller over Fluid's markup: it binds the events and writes everything the shipped view derives from the editing state, including the two column widths of Templates/Profile/Index.html.

Opening and closing is animated with a short vertical move and fade, driven by the …-image-editor-enter-active / -enter-from / -leave-active / -leave-to classes of the extension's stylesheet. An explicit CSS grid row expands and collapses the editor height, padding, margin and border instead of removing the complete block in one layout step. The open scroll leaves 2rem above the editor. The return scroll starts together with the collapse and uses the preview's calculated final position; native scroll anchoring is disabled only during that phase, so it cannot introduce a competing correction. Environments requesting reduced motion skip the transition, and the close then completes in the same frame rather than waiting for an animation that never runs.

The full-width btn-sm edit action sits directly below the preview. Its visible label and image upload icon are complemented by localized title and aria-label attributes.

The image editor deliberately has no state-dependent Add or Replace action. Selecting a file immediately replaces only the inline crop preview with a local object URL. The page preview and persisted profile remain unchanged until Save succeeds. A successful upload replaces both previews, collapses the editor and shows the saved image directly. During the leave transition, the preview remains hidden and the profile fields retain their full width. The regular 4 / 8 grid is restored only after the editor has finished collapsing, preventing competing layout changes while the page returns to the image preview. Cancel discards the selected preview and restores the persisted image. Delete is shown only while an image is persisted.

If special.image.renderType is cropper and special.image.settings.ratio contains a positive ratio such as 1x1 or 16:9, the editor instantiates the CropperJS module the TYPO3 core maps as cropperjs - version 1.6.1 on both supported core versions. The selection remains constrained to that ratio and only the generated cropped file is added to the multipart request. No CDN or other runtime request is used. The ratio remains fixed while the selection can be dragged and resized to choose the visible image area, and the cropped file is written at the resolution of the selected file rather than at the size the editor displays it, up to 2400 pixels wide. The cropper is instantiated only after a new local file is selected. A persisted profile image and the placeholder remain normal previews and cannot themselves become crop input. The original upload behavior remains active for every other render type.

The save button remains disabled until a new local file is selected. This also prevents an already persisted image from being fetched, cropped and uploaded again. While an upload or deletion is pending, all image controls are disabled and the active action displays a Bootstrap spinner. This prevents duplicate requests and leaving the image editor during a running operation.

plugin.tx_academicpersonsedit.settings.editForm.profileImage {
    targetFolder = 1:/profile-images
    validation {
        maxFileSize = 2M
        allowedMimeTypes = image/jpeg,image/png,image/webp
    }
}

{
  "profile": 123,
  "data": {}
}

Authentication and responses 

Every endpoint above requires an authenticated frontend user and accepts only the profile assigned to that user. The generic update, synchronization and delete endpoints propagate machine-readable JSON errors. Image upload validation is also converted to and propagated as JSON by the controller's error action.

Customizing the view 

Override Resources/Private/Templates/Profile/Index.html and the partials below Resources/Private/Partials/Profile/ through the regular template and partial root paths. The index keeps URL/data setup, the responsive main grid, the prototypes and the composition. The Profile, Documents, Image and Field directories group the corresponding UI responsibilities; the status regions and client-side button templates remain shared at the root.

Every file in that tree is an override point, including the two regions a browser builds at runtime. The editor of one document or contract and the contacts of one contract cannot be rendered as finished markup - their fields, labels, options and display values come from the documentForm and contractContactForm responses - so Fluid renders their shapes instead, as <template data-pe-proto="…"> blocks, and the elements clone one and fill it.

A prototype is filled through exactly four attributes, and an override keeps them and their keys:

What an override may change is every tag, every class and every label. What it may not change is the vocabulary - the data-pe-* hooks and the slot, condition and list keys - and what it cannot change is the order the elements insert things in and which slot carries which value; both are TypeScript. See Important: The profile editor is Fluid, driven by five custom elements in the changelog.

data-pe-autosave-undo          data-pe-document-kind
data-pe-compact                data-pe-document-section-header
data-pe-contract-contact-actions   data-pe-document-sections
data-pe-contract-contact-fields    data-pe-group-actions
data-pe-contract-contact-form      data-pe-helptext
data-pe-document-actions       data-pe-image-editor-heading
data-pe-document-fields        data-pe-profile-header
                               data-pe-rich-text-heading

State classes and selectors JavaScript uses 

No element and no prototype filler writes markup: every tag, every class attribute and every label of the editor is authored in Fluid. What the modules below them do is toggle state classes on markup that already exists, and select a few nodes by class. Both are part of the override contract - renaming one of them breaks the editor silently, because nothing throws when a classList.toggle() writes a class no stylesheet defines.

Frontend build 

The package has no separate development toolchain below Resources/Public/. TypeScript sources, SCSS sources and the committed JavaScript and CSS output use the repository-wide frontend suites from the repository root:

Build/Scripts/runTests.sh -s buildJs
Build/Scripts/runTests.sh -s checkJsBuildClean
Build/Scripts/runTests.sh -s lintTypescript -n
Build/Scripts/runTests.sh -s typecheckJs
Build/Scripts/runTests.sh -s testJs

Nothing is bundled: the build emits one module per source file and leaves every import as it was written. No JavaScript library is committed with the extension - both libraries the editor uses, CKEditor 5 and CropperJS, are resolved through the import map from rte_ckeditor and core.

Tests 

Controller unit tests cover method, payload and authentication errors for the JSON actions. Sanitizer unit tests cover the supported profile properties, allowed editor markup and rejection of scripts, event attributes, styles, unknown tags and unsafe link schemes. Validation-service unit tests verify that sanitization happens before a value is registered for persistence.

A JavaScript suite runs the shipped modules and elements against a DOM (Build/Scripts/runTests.sh -s testJs). It drives the rendered markup of the Fluid partials through the modules that read it, which is the only place the event handling, the optimistic list updates, the transitions and the focus management are executed at all.

Functional plugin tests render the inline-collapse targets, the prototypes and the image view, verify the decomposed Fluid contracts, AJAX-only controls, direct rich-text previews and the separate delete, cancel and save actions. They also assert the prototype inventory, every slot key of every prototype, and that a prototype control and the live control of the same type carry the same tag, the same classes and the same attributes. The section-provider unit test verifies that order, identifiers, field names, relation types and labels come from the shared settings graph while row fields, action capabilities, presentation modes and typed records are preserved. Functional fixtures cover contracts and every configured profile-information relation; the rendered page test derives the expected order and metadata from the same settings service, then checks placement below About me, alternating records, empty states, writable add controls and exactly the configured row actions. AJAX lifecycle tests cover schema loading, CKEditor inline fields, creation, partial updates, arrow and drag sorting, cross-section rejection, deletion and read-only endpoint denial. Contract tests additionally cover every configured field plus address, email-address and phone-number creation, display, update, independent sorting, deletion and cross-Contract rejection. They also guard the ProfileEditing plugin against accidentally exposing removed mutation controllers. Registration tests ensure that ProfileEditing is the only editing content element offered to editors. The architecture unit test scans the ProfileController, Fluid tree and JavaScript for forbidden legacy controller and template references.

The AJAX tests persist malicious rich-text input through the real update endpoint and assert that only the sanitized response is stored. The inline image tests verify that a missing file can never return success and that a real multipart upload returns hasImage: true and creates the FAL relation. They also exercise the dedicated image deletion endpoint through the generated action URL. Form submissions reuse the complete rendered action URL, including the JSON page type, so the tests exercise the same routing contract as the browser. Upload tests are assigned to the not-core-13 PHPUnit group because TYPO3 v13's CLI upload permission check requires a real HTTP upload.

The page type of the JSON endpoints 

Every writing endpoint of the editor is an Extbase action of the same plugin, reached through a dedicated PAGE object with typeNum = 1733735 . The object is delivered by the site set and by the static template of this extension, it is not cached, and it sets Content-Type: application/json on the page - TYPO3 v13 drops the headers a plugin response carries, so the page has to declare it.

Three things in a project's infrastructure have to know about that number:

• The TypoScript of the site itself. The object exists where the TypoScript of this extension is included - through the site set fgtclb/academic-persons-edit-profile-editing or the static template Academic Persons Edit: Profile editing. There was no such page type before version 3.0, because the previous editor was a server-rendered form flow, so a site package that copied the extension's TypoScript into its own instead of including it has no academicPersonsProfileEditingAjax object. The editor then renders, and every save is answered with the HTML of the page instead of JSON - a failure that happens in the browser, with nothing in the TYPO3 log to look at. The editor therefore checks the TypoScript setup of the request for a PAGE object with that typeNum , and where there is none it renders a role="alert" message (data-pe-missing-ajax-page-type) instead of the silent failure, and logs the cause at error level. Include the delivered TypoScript, or copy the object into the site package:

  EXT:my_sitepackage/Configuration/TypoScript/setup.typoscript

  academicPersonsProfileEditingAjax = PAGE
  academicPersonsProfileEditingAjax {
    typeNum = 1733735
  
    10 < tt_content.academicpersonsedit_profileediting.20
  
    config {
      disableAllHeaderCode = 1
      admPanel = 0
      debug = 0
      disablePrefixComment = 1
      no_cache = 1
      additionalHeaders.10 {
        header = Content-Type: application/json
        replace = 1
      }
    }
  }

  Copied!

• Route enhancers. A PageTypeDecorator that maps page types onto URL suffixes has to list 1733735, or the editor's request URLs are not resolvable. Without a decorator the type travels as &type=1733735 and nothing has to be configured.

  config/sites/<identifier>/config.yaml

  routeEnhancers:
    PageTypeSuffix:
      type: PageType
      default: ''
      index: ''
      map:
        profile-editing.json: 1733735

  Copied!
• Web application firewalls and reverse proxies. The endpoints are POST requests carrying JSON, and one of them carries a multipart/form-data image upload. A rule set that blocks unknown JSON bodies, strips the X-Requested-With header or limits the upload size below the configured maxFileSize makes the editor fail with a generic error message and no server side log entry.

The request header the endpoints require 

Every writing endpoint - the fifteen JSON actions and the image upload - requires the request header X-Requested-With: XMLHttpRequest. A request without it is answered with 400 and the error code invalid_request.

The shipped JavaScript sends the header on every request, so this is invisible in normal use. It exists for the image upload, which is a multipart/form-data request and therefore one that any foreign page could submit with a plain form, carrying the visitor's session along. A custom header cannot be set on a cross-origin request without a CORS preflight, which the browser refuses for a cross-site page - so requiring one closes that door without relying on the SameSite attribute of the session cookie, which an installation may change.

A project that talks to the endpoints from its own code has to send the header.

Icon identifiers 

The action icons of the editor are registered in Configuration/Icons.php and rendered through core:icon with alternativeMarkupIdentifier="inline", so the SVG is inlined and follows the text colour of the button it sits in. The files are Bootstrap Icons (MIT, see Resources/Public/Icons/LICENSE-bootstrap-icons.txt) drawn in currentColor.

Identifier and file name name the action, not the glyph: a project that replaces the icon set changes the drawing, not the identifiers its template overrides address.