{5.4] [AI] [com_media] Allow image editor to re-save file back to original non-ASCII filename

[thoni56]

Summary

The Joomla 5 media manager's built-in image editor returns HTTP 403 with JLIB_MEDIA_ERROR_UPLOAD_INPUT whenever the user tries to save an edit to a file whose existing name on disk contains non-ASCII characters (e.g. erik_schön.jpg, λογότυπο.png, files placed by FTP / migration / sample data).

Fixes #47934.

Reproduction

1. Place an image with a non-ASCII filename in the local filesystem adapter's root (FTP upload bypasses the media manager's transliteration, or use any file migrated from a J3 site).
2. Open it in com_media's image editor.
3. Make any edit (rotate, crop, …) and click Save.

The PUT to index.php?option=com_media&task=api.files&path=local-images:/…/erik_schön.jpg returns:

{
  "success": false,
  "message": "The file could not be uploaded.",
  "messages": { "error": ["The file name must only contain alphanumeric characters and no spaces."] }
}

Root cause

LocalAdapter::checkContent() (plugins/filesystem/local/src/Adapter/LocalAdapter.php) is called from both createFile() and updateFile() and runs the incoming filename through MediaHelper::canUpload():

$can = \$helper->canUpload(['name' => \$name, 'size' => \strlen(\$mediaContent), 'tmp_name' => \$tmpFile], 'com_media');

canUpload() (libraries/src/Helper/MediaHelper.php) enforces:

if (\$file['name'] !== File::makeSafe(\$file['name'])) {
    \$app->enqueueMessage(Text::_('JLIB_MEDIA_ERROR_WARNFILENAME'), 'error');
    return false;
}

File::makeSafe() transliterates non-ASCII characters via Any-Latin; Latin-ASCII + iconv("UTF-8", "ASCII//TRANSLIT//IGNORE", …), so erik_schön.jpg !== erik_schon.jpg, the guard fires, and checkContent throws 403.

The check is correct for uploads — new files with non-ASCII names are deliberately not accepted by the media manager. It is incorrect for in-place updates, where the filename is fixed on disk and the operation only rewrites the bytes. The size, MIME and executable-extension checks performed by the same canUpload() call are still wanted and should keep running.

Fix

Pass File::makeSafe(\$name) into canUpload() so the name-equality test trivially passes while the content checks still run. New uploads continue to be blocked up-front by getSafeName() in createFile() / createFolder(), so this only changes behaviour for in-place edits of pre-existing files.

Test plan

• Open an image with a non-ASCII filename (erik_schön.jpg) in com_media's image editor, rotate it, save → file is rewritten on disk, no 403.
• Open an ASCII-named image, edit, save → still works.
• Try uploading a new file with a non-ASCII name via the media manager → still rejected up-front by getSafeName() as before.
• Try uploading a file with an executable extension (.php.jpg) on top of an existing non-ASCII file → still rejected by canUpload()'s extension check.

Documentation Changes Required

None.

Generative AI disclosure

Per the Joomla Generative AI Policy: this patch was drafted with Claude (Anthropic) assistance during root-cause analysis of the 403 above. The fix is one line + comment; the reporter (me) reproduced the bug on a real Joomla 5.4 site, applied the patch, and verified all four scenarios above pass before opening this PR.

[brianteeman]

What would happen if your filesystem has both files erik_schön.jpg and erik_schon.jpg

[thoni56]

@brianteeman That is not the issue being fixed, and having an erik_schon.jpg is not relevant for the case. In this case there is a file called erik_schön.jpg which has been opened for editing. It should be allowed to be saved back to that name. In fact all existing files that can be opened with the media manager for editing should be written back to the original name, not silently skipping, or even renaming.

The premise being that someone decided to upload erik_schön.jpg through some other means than the built-in media manager, ftp, cp or another, non-renaming, media manager.

[brianteeman]

My question was because my reading of the change says that it uses a temporary "safe" filename and I am wondering what happens if a file exists already that has the same name as the temporary filename

[thoni56]

@brianteeman Aah, yes, that is a relevant point. I guess that it depends if canUpload actually uses the name to store the file temporarily. But when I tested it the original, non-ASCII named, file was updated and no new file with the "safe name" were created. But I should probably test that case explicitly.