User tests: Successful: Unsuccessful:
Pull Request for Issue #27494 .
This Pull Request (PR) adds following to the Upload & Update tab of the Joomla Update Component:
If the selected upload file is too big, a warning alert is shown. If the user tries to upload that file anway, the upload is rejected with an appropriate browser alert message.
The size of the selected file is always shown in MB because the PHP limits and so the maximum file size will with a 99.9 % likelyhood also be in MB.
For the Upload & Install Package tab of the Extension Installer I've created PR #27665 with similar changes, but there only the browser alert is implemented. Display of the size of the selected files is not really possible there.
Requirements: npm
npm run build:js
(or npm install
if you prefer this).administrator/index.php?option=com_joomlaupdate
and there to tab "Upload & Update".Joomla package file
fields.Upload & Install
button.See isue #27494
If post_max_size
is big enough but upload_max_size
is violated:
Hint: The 403 and the missing language strings are separate issues not being fixed with this PR here. The 403 could also be related to a problem in my testing environment.
If upload_max_size
is big enough but post_max_size
is violated:
Nothing happens, and PHP error log shows: PHP Warning: POST Content-Length of 22972015 bytes exceeds the limit of 16777216 bytes in Unknown on line 0, referer: ...
(with byte figures suitable to your test).
Nothing special for this PR. The help screens for J4 backend have to be udpated anyway.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_joomlaupdate Language & Strings JavaScript Repository NPM Change |
Title |
|
@brianteeman P.S.: I'd also be happy if you could give feeback regarding point 2 in the "To be done" section of the description of this PR, if that alert div shall always be there and only visibility is changed with js like it is now, or if maybe the alert class also should be changed from warning to something else if that div is hidden, or how that is normally handled. Thanks in advance.
Update: Removed the "To be done" section because I have the feeling it might discourage people from testing. You'll see anyway if this PR does it in a good or a bad way when looking at the code changes.
@Fedik As you are very good in Joomla JS: Do you know if we already have something to make bytes nice, i.e. not show 16777216 bytes
but 16 MB
, or GB
or whatever we have? I know it's not a big thing to write it bout would be pity to have duplicate functionality at several places.
Do you know if we already have something to make bytes nice, i.e. not show 16777216 bytes but 16 MB, or GB or whatever we have?
I did not seen such in Joomla code
Labels |
Added:
?
NPM Resource Changed
?
|
@richard67 are you looking for this
joomla-cms/libraries/src/Filesystem/FilesystemHelper.php
Lines 360 to 374 in 64b9025
Other than comments about the strings and size it all seems to work fine
@richard67 are you looking for this
joomla-cms/libraries/src/Filesystem/FilesystemHelper.php
Lines 360 to 374 in 64b9025
@brianteeman For same functionality but available in javascript so I can use it here: https://github.com/joomla/joomla-cms/pull/27570/files#diff-b155936a54bbb6b34c31eb456d23a45cR48. The actual file size is determined in javascript, so I can't prepare formatted output for it in PHP like I can with the maximum allowed file size.
sorry missed the js part of the question - something like this should do it
this.files[0].size/1024/1024 + "MB"
PS fileSizeAct - what does the Act mean/represent?
@brianteeman If I want to hard-code it to MB then yes, this works. But what if GB would be more suitable?
@brianteeman "act" stands for "actual", i.e. size of actually selected file, on opposite to "max", which stands for the maximum allowed.
@brianteeman Since the PHP limits are in almost all cases given in MB, do you think it's ok to hard-code the displayed size of the actually selected file always in MB, i.e. use your code above? If you think it's ok I'll update my PR to do so.
@brianteeman If I want to hard-code it to MB then yes, this works. But what if GB would be more suitable?
hardly likely that someone would try to load a file that large via a web browser. And if they really did try to then I am sure they would understand why 5000MB is too big
@brianteeman "act" stands for "actual", i.e. size of actually selected file, on opposite to "max", which stands for the maximum allowed.
Doesnt make sense to me - what is wrong with simply saying fileSize
what is wrong with simply saying fileSize
@brianteeman Nothing wrong with that, I just thought fileSizeAct would be more precise. But if you think it is confusing I can change that. Readability of code is an important thing.
Other question: If I implement all changes suggested by you, will you then test this PR and mark the result in the issue tracker? ;-)
Implemented all changes suggested by @brianteeman . Thanks for review.
To him and all other readers: Please test (if you have npm).
Updated also testing instructions (text and screenshots).
I have tested this item
I have tested this item
@brianteeman Thanks a lot. If you have time and mood, could you also test my similar PR for the extensions installer, PR #27665 ?
already done
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
RTC
Thanks for testing.
Labels |
Added:
?
|
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-02-01 23:26:05 |
Closed_By | ⇒ | Quy |
Thanks.
@brianteeman I'd be happy if you could find time and review language strings, and - what is more important - accessibility of the new fields, if necessary.