[#32582] - [4.0] Fix deletion of files in script.php on updates
- Fixed in Code Base
- 4 Mar 2021
- Medium
- Build: 4.0-dev
- # 32582
- Diff
- richard67:4.0-dev-update-deleted-files-and-folders-in-script-php
User tests: Successful: Unsuccessful:
Pull Request for #32043 (comment) .
Summary of Changes
This pull request (PR) fixes following issues:
- With PR #32043 , css and js files of the skipto plugin were removed, and that PR should have added these files to the list of files to be deleted (array
$files) in script.php below the last file here here:
joomla-cms/administrator/components/com_admin/script.php
Lines 5047 to 5048 in 5185266
But it has added them to the list of folders (array$folders) here:
joomla-cms/administrator/components/com_admin/script.php
Lines 6236 to 6239 in 5185266
This PR here corrects it by moving the files to the right place, except of fileskipTo.js, see point 4 below. - Because after the removal of file
SkipTo.cssfolder/media/vendor/skipto/csswill be empty, that folder has to be removed, too, so this PR adds it to the list of folders. - The files and the folder have been removed after Beta 6 and before Beta 7, i.e. the removal was released with Beta 7, and so the comment "// Joomla 4.0 Beta 6" used by PR #32043 was wrong, it has to be "// Joomla 4.0 Beta 7".
- Since PR #31804 has been merged, there is a new function in script.php which is used to rename files with a wrong name regarding upper and lower case. The file
skipTo.jsis such a case and has been added to that function by that PR here:
Files which are renamed like this shall not be in the list of files to be deleted. PR #31804 should have removed it from that list, but this was missed, possibly due to issue 1. That's why this PR leaves it away as mentioned above in issue 1.
Testing Instructions
Code review by someone who is familiar with what this PR deals with should be sufficient, but for those who insist on a real test:
- Update a Joomla 4 Beta 6 or an earlier Joomla 4 version to Beta 7.
- Check if the following files are there:
/media/vendor/skipto/js/dropMenu.js/media/vendor/skipto/css/SkipTo.css
Result: The files are still there.
- Check if folder
/media/vendor/skipto/csswould be empty if fileSkipTo.csshad been removed.
Result: The folder would be empty becauseSkipTo.cssis the only file in it. - Now update to Beta 8 dev + this PR using the update package or custom update URL built by drone for this PR.
- Check if the following files are there:
/media/vendor/skipto/js/dropMenu.js/media/vendor/skipto/css/SkipTo.css
Result: The files have been removed.
- Check if folder
/media/vendor/skipto/cssis there.
Result: The folder has been removed.
Actual result BEFORE applying this Pull Request
After an update from Joomla 4 Beta 6 or an earlier Joomla 4 version to Beta 7, files /media/vendor/skipto/js/dropMenu.js and /media/vendor/skipto/css/SkipTo.css are still present.
Expected result AFTER applying this Pull Request
After an update from Joomla 4 Beta 6 or an earlier Joomla 4 version to Beta 7, file /media/vendor/skipto/js/dropMenu.js and folder /media/vendor/skipto/css have been removed.
Additional information
This PR doesn't fix other issues (missing stuff from Beta 6 and 7 and later up to now) in the files and folder deletion of script.php.
I will later (weekend or so, latest before the next Beta or RC) make another PR to fix these.
Documentation Changes Required
None.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_admin |
| Title |
|
||||||
@dgrammatiko Then you should have a look on #25559 and the discussion there, especially my last comment.
As long as we have a 3.10 which has ongoing development, e.g. adding new 3.10 update SQL scripts, and a 4.0-dev which also has ongoing development, e.g. adding and maybe later removing again files or vice versa, we will need 3 points for the comparison.
We have to compare 4.0 Beta 1 with the latest 3.10 nightly or a current 3.10 package to get e.g. those update 3.10 SQL's which were added in the 3.10-dev branch and will be removed when updating to 4.
And we have to compare the latest 4.0 nightly or a fresh 4.0 package with the last 4.0 for which we have done the list of files and folders last time, in our case currently Beta 5, to get what happened between those points.
What happened between 4.0 Beta 1 and 4.0 beta 5 we can ignore because that's already ok in the script.php.
I hope I did not explain to complicated and you did get what I mean, so you go the right way from beginning on and not waste a lot of time by the idea you can handle that all by only comparing 3.10-dev and 4.0. This will never work as long as both branches have ongoing development.
And we have to compare the last 4.0 for which we have done the list of files and folders last time, e.g. in our case Beta 5, with the latest 4.0 nightly or a fresh 4.0 package, to get what happened between those points.
Actually, it's a bit worse than that, should start with the first beta and diff it to all the next ones till the last one. I mean it's a bit of work to expand each package and run the script there, not hard just time consuming.
Anyways I'm reading the other PR to get a grip
Actually, it's a bit worse than that, should start with the first beta and diff it to all the next ones till the last one. I mean it's a bit of work to expand each package and run the script there, not hard just time consuming.
Well, that's true if we rebuild the lists (files and folders to be deleted, and if possible also one for the files to be renamed becuse of wrong case) completely each time. In this case we have to go through all versions one after the other, and if one day we wanna say we also allow updates between nightlies, we would have to do that every night ;-)
But if we keep the constant part of the list constant as long as once correct, and that would be the part between 4.0 Beta 1 and currently 4.0 Beta 5 (because that was the last version for which the lists in script.php were correct and complete), then we could skip to check those.
Know what I mean?
Let me dream a bit:
If we have a script which is so clever to check the differences between those 2 branches 3.10 and 4, i.e. diff between 4.0 starting point and 3.10 ending point and diff between 4.0 ending point and 4.0 starting point, and we could run it every night on the nightlies and let it update external files which are just included by script.php, we could at the end have granted possibility to update between nightlies, and all those endless discussions I sometimes need to explain beginners why they can't safely do that in all cases would have an end, and that would save me lots of time and nerves.
But that's a dream ;-)
But that's a dream
I'll take the challenge
I'll take the challenge
?
Yes ... after the UI for the child templates ... and the fix for the installation folder deletion
@dgrammatiko I just see that going through the chain of releases from old to new, including 3.10, would also not be right. See my latest comment in George's draft PR: #25559 (comment) .
But maybe we should continue to discuss that there in order not to confuse possible testers of this PR here.
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-03-04 15:00:33 |
| Closed_By | ⇒ | wilsonge | |
| Labels |
Added:
?
|
||
This is fine as it is. But I'd definitely love some help bulking out the diff script!
@richard67 I'm planning to add an npm script to keep a registry of the files in the repo and do a diff per release. In sort don't spend too much time on such PRs, we're missing some vital code here?