User tests: Successful: Unsuccessful:
Pull Request for Issue #38068 and #38530 .
Improve error handling in MediaManager
Apply patch. Run npm install.
Try upload something not allowed in to mediamanager.
General error Unable to upload file.
General error Unable to upload file.
Then multiple detailed errors:
Or Illegal mime type detected or This file type is not supported (depend from medimanager config)
Or for svg: The file looks suspicious, therefore cannot be uploaded
nope
@brianteeman please review an updated string.
| Status | New | ⇒ | Pending |
| Category | ⇒ | JavaScript Administration com_media NPM Change Language & Strings |
| Labels |
Added:
Language Change
NPM Resource Changed
?
|
||
Thank you for providing a better solution!
even better would be to display the error message from the svgsanitizer which explains exactly why the file was rejected
I have added documentation about uploading SVG files. You can find it at https://docs.joomla.org/J4.x:Media:_Uploading_SVG_files. It may need refining and additional content. You are welcome to pitch in, thank you!
The script render all messages that was sent from PHP backend.
In your example, I guess the first one comes from a controller, and second one from a validator.
I have tested this item
Before the fix, the script was rendered only first message, and rest were ignored.
In your example, I guess the first one comes from a controller, and second one from a validator
The first message is from the Exception https://github.com/joomla/joomla-cms/blob/4.2-dev/plugins/filesystem/local/src/Adapter/LocalAdapter.php#L772 , additional messages are Joomla system messages generated by calling $app->enqueueMessage from canUpload from MediaHelper https://github.com/joomla/joomla-cms/blob/4.2-dev/libraries/src/Helper/MediaHelper.php#L200
Still the first error message is redundant as Brian said. Is it OK to make the Exception https://github.com/joomla/joomla-cms/blob/4.2-dev/plugins/filesystem/local/src/Adapter/LocalAdapter.php#L772 with empty message, and have the Joomla system messages rendered for this case ? It is kind of workaround but more user friendly.
Is it OK to make the Exception with empty message
I do not think.
I think the root issue that $helper->canUpload() should return boolean and cannot throw an exception, so someone decided to put all in to $app->enqueueMessage . Not perfect, but working.
I have tested this item
Not perfect but work.
| Status | Pending | ⇒ | Ready to Commit |
RTC
@AmyKrizanWang please do not update your comment. It is nothing to do with this issue.
This pull request has been automatically rebased to 4.3-dev.
| Labels |
Added:
?
bug
|
||
| Status | Ready to Commit | ⇒ | Pending |
Pleas test it again, there was a complex conflict, I had to redo changes.
| Labels |
Added:
PR-4.3-dev
?
Removed: ? ? |
||
This pull request has been automatically rebased to 4.4-dev.
| Title |
|
||||||
@AmyKrizanWang please do not update your comment. It is nothing to do with this issue.
comment removed
This pull request has been automatically rebased to 5.2-dev.
| Title |
|
||||||
| Labels |
Added:
Small
PR-5.2-dev
Removed: PR-4.3-dev ? |
||
I have tested this item ✅ successfully on 2e13c16
npm ci)I have tested this item ✅ successfully on 8b01df6
Upload of a suspicous svg failed with the new messages. Ordinary svg worked
| Status | Pending | ⇒ | Ready to Commit |
RTC
| Labels |
Added:
RTC
|
||
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2025-01-18 20:56:50 |
| Closed_By | ⇒ | Hackwar |
Thank you!
Nice one as it will catch on every request the error messages.