With the migration from J! 3.9 to J! 3.10 from the Nightly Builds zip file, the Pre-Update screen is missing.
Through Custom URL there is the Pre-Update.
I expect Pre-Update in all update modes.
Labels |
Added:
?
|
Well it is expected behavior at this point. When you upload the package it is starting the installation already so you should check upfront before you install anything that you are compatible.
And you should only use that manuall upload thing when you k ow what you are doing and the 'normal' way don't work for you.
@adj9 As Tobias explained in the previous comment, it is by design.
Furthermore, when updating to the same major version, e.g. a 3.9 to a 3.10, there are no changes in the system requirements (PHP version, database type and version, particular PHP settings). So if there was some requirement not met, you would see it already on administrator/index.php?option=com_installer&view=warnings
before the update. So for this case it doesn't really need the pre-update check.
When updating to the next major version, i.e. from 3.10 to 4, the pre-update check gets the information about required PHP version and database server and version from the details XML on the update server and checks them BEFORE the update package is downloaded. This can work only when using an update server, i.e. "Live Update", but not when using "Upload & Update".
To change this, it would need a redesign of the update procedure as such, e.g. putting the information into the update package and check it after unpacking the package, and then having an additional confirmation step where the backend user can check the update check results and decide for "continue" or "abort". This would mean less comfort for 99.9 % of the use cases where the site admin has done his/her job and checked the requirements of the new major CMS version.
If you think it needs such a change, feel free to open a new issue with a feature request for that.
This one here I will close as expected behavior.
Status | New | ⇒ | Expected Behaviour |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-06-21 11:19:39 |
Closed_By | ⇒ | richard67 |
Closing as expected behavior for reasons as explained in my previous comment.
@zero-24 Could you check this issue?