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.