[4.0] Installer improvements#26399
Conversation
|
@brianteeman Is there maybe a step "Apply the changes of this PR" (or similar) missing in the testing instructions between the 1st export and the 2nd clean install? |
|
obviously - but as it wasn't that obvious I updated the instructions |
|
Code review looks good to me, can do real test tonight after work (if still necessary then). |
|
Just as a fair warning, this change probably breaks “fixing” timestamps and user IDs in the |
|
@mbabker - forgot that. of course there would still be an issue with custom.sql being used for custom installations (with extensions) which could not be updated as this function would not be aware of those tables and fields |
|
also the script is still wrong in its existing format for the use cases you described |
|
Just got pointed at this by Richard. I'm happy to remove the date code like done here in favour of people using |
|
See PR #26825 . |
Pull Request for Issue #26387 .
Summary of Changes
Don't perform update queries where they are not needed.
Make sure that the queries performed are correct
Testing Instructions
Perform a clean install
Check the db table and you will see that modules have no start publishing date
Export the database
apply the pr
Perform a clean install
Check the db table and you will see that modules have a start publishing date
Export the database
Compare the two database exports
The only differences between the two exports will be sessions, admin password and the timestamps.
There should be no difference for the userid
There should be a difference with the modules publish_up date which should be the time of the install and not 0000
Benefits
Less queries performed that are not needed reduces the installation time etc