[#47935] - [5.4] [AI] [com_media] Allow image editor to re-save file back to original non-ASCII filename
- Pending
- Medium
- Build: 5.4-dev
- # 47935
- Diff
- thoni56:fix/com-media-image-editor-non-ascii-filename
User tests: Successful: Unsuccessful:
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
- 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).
- Open it in com_media's image editor.
- 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 bycanUpload()'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.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Front End Plugins |
| Title |
|
||||||
@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.
| Labels |
Added:
PR-5.4-dev
|
||
| Title |
|
||||||
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
@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.
| Labels |
Added:
Information Required
|
||
| Category | Front End Plugins | ⇒ | Front End Plugins Unit Tests |
@brianteeman No, I didn't ;-) But now I added an explict unittest for it instead: tests/Unit/Plugin/Filesystem/Local/Adapter/LocalAdapterTest.php::testUpdateFileDoesNotTouchExistingSafeNamedNeighbour
It first creates a file at the "safe name" along the non-ASCII one, edits the non-ASCII, and asserts that the safe-named file is untouched with no stray files left behind.
muhme
- | Title |
|
||||||
| Labels |
Added:
Unit/System Tests
PBF
Removed: Information Required |
||
@thoni56
Can you update the PR so a new download package is created?Sorry, don't know what this means. I'm not familiar with the Joomla release process. Or how and why that affects this PR.
It’s just clicking the branch update button on GitHub. I have done that already. New packages are available.
@thoni56 Could you check and apply my latest code change suggestions? You can comfortably do that on GitHub in your PR #47935 by applying them one by one with a button, or if you go to the changes of your PR on GitHub here https://github.com/joomla/joomla-cms/pull/47935/changes , you can add my suggestions to a batch with a button for each suggestion and at the end when all added just apply that batch with another button.
There, should be done now. Waiting for checks.
I have tested this item ✅ successfully on 4c85fc9
I tested this successfully. Currently there is no error shown when you edit an image with non ascii filename but the edit is simply not done. With this PR the edit is processed.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47935.
I have tested this item ✅ successfully on 4c85fc9
I tested this successfully. Currently there is no error shown when you edit an image with non ascii filename but the edit is simply not done. With this PR the edit is processed.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/47935.
What would happen if your filesystem has both files
erik_schön.jpganderik_schon.jpg