---
title: "Important: Profile image upload uses native Extbase upload handling"
manual: "Academic Profiles Edit"
version: "main"
source: "Changelog/3.0/Important-MigratedProfileImageUploadToNativeExtbaseFileUploadHandling.rst"
rendered: "2026-09-30T20:17:10+00:00"
---

# Important: Profile image upload uses native Extbase upload handling {#important-migrated-profile-image-upload-to-native-extbase-file-upload-handling}

## Description {#description}

The profile image upload of the `academicpersonsedit_profileediting` plugin was
handled by the custom type converter
`\FGTCLB\AcademicBase\Extbase\Property\TypeConverter\FileUploadConverter`
(`EXT:academic_base`). It has been replaced with the native Extbase file upload
handling introduced in TYPO3 v13.3 (`FileUploadConfiguration`, see TYPO3
feature [forge#103511](https://forge.typo3.org/issues/103511)), and the replacement survives the editor rewrite of
the same release: the new editing view uploads the image through the same
configuration.

The TypoScript setting names are unchanged.
`settings.editForm.profileImage.targetFolder`,
`settings.editForm.profileImage.validation.maxFileSize` and
`settings.editForm.profileImage.validation.allowedMimeTypes` keep
their names and are mapped onto the core `FileSizeValidator` and
`MimeTypeValidator`. What a *blank* value means changed - see
[Breaking: Profile image upload validation always applies](Breaking-ProfileImageUploadValidationAlwaysApplies.html#breaking-profile-image-upload-validation-always-applies).

## Impact {#impact}

The upload behaves differently in four ways:

-   **Stored file names change.** The custom converter built the file name from
    the profile data as `<firstname>-<lastname>-<uid>.<extension>` and replaced
    an existing file of that name. The native handling keeps the name supplied by
    the client, appends a random suffix and renames on conflict instead. Stored
    names therefore no longer contain the name of the person, which is an
    improvement for a folder that is usually reachable over the web.
-   **The previous image is deleted on re-upload.** Because the generated name
    changed on every upload, replacing an image would leave the previous file
    behind. Uploading a new profile image now deletes the file the profile
    referenced before, unless it is still referenced by another record.
-   **The mime type is detected from the file content.** The custom converter
    trusted the media type sent by the browser, which can be spoofed. The core
    `MimeTypeValidator` inspects the uploaded file itself and additionally
    cross-checks the file extension. An upload whose real content does not match
    an allowed mime type is now rejected, even if the browser announced an
    allowed one. Uploads that only passed because of a faked header stop working
    \- this is intended.
-   **The file is only stored once the upload validates.** Previously the file
    was imported into FAL while mapping the request, so an upload that failed
    validation afterwards left an unreferenced file behind in the upload folder.
    The file is imported after successful validation now, which avoids those
    orphaned files.

## Affected Installations {#affected-installations}

Installations using the profile editing plugin
(`academicpersonsedit_profileediting`) with profile image uploads. Installations
that rely on the stored file name - for example when referencing those files by
a fixed path outside of FAL, or when addressing them by the person's name - need
to review that assumption.

## Migration {#migration}

No configuration change is required for the upload itself; check the blank-value
semantics of the two validation settings in the breaking entry named above.
Files uploaded before this change keep their existing names and references, and
are deleted as soon as the corresponding profile image is replaced.