[#40298] - [5.0] Update deleted files and folders to changes from #40293
- Fixed in Code Base
- 3 Apr 2023
- Medium
- Build: 5.0-dev
- # 40298
- Diff
- richard67:5.0-dev-deleted-files-and-folders_2023-04-02
- Pending continuous-integration/drone/pr Build is pending Details
User tests: Successful: Unsuccessful:
Pull Request for Issue # .
Summary of Changes
This pull request (PR) updates the lists of files and folders to be deleted on update in file "administrator/components/com_admin/script.php" to recent changes in the 5.0-dev branch.
Currently there are only changes caused by PR #40293 for removing the "symfony/polyfill-php72" dependency.
Testing Instructions
Code review.
Or if you want to make a real test, update the last 4.4 nightly build to the last 5.0 nightly build to get the actual result, and update the last 4.4 nightly build to the update package built by Drone for this PR to get the expected result.
Actual result BEFORE applying this Pull Request
The files and folders of the "symfony/polyfill-php72" dependency are still present after updating from the last 4.4 nightly build.
Expected result AFTER applying this Pull Request
The files and folders of the "symfony/polyfill-php72" dependency have been deleted after updating from the last 4.4 nightly build, like it is done already without this PR here with the symfony polyfills for the other PHP versions.
Link to documentations
Please select:
-
No documentation changes for docs.joomla.org needed
-
No documentation changes for manual.joomla.org needed
joomla-cms-bot
- | Category | ⇒ | Administration com_admin |
| Status | New | ⇒ | Pending |
Is our script not able to delete directories recursively?
@HLeithner The folder library's delete method does that, so yes. But in all 4.x versions and also in 3.10 we had it like that for whatever reason, so I continue with that. Maybe @wilsonge remembers why it was kept in this way.
@HLeithner Maybe the reason was that it is harder to review and harder to write a tool which does it in that way, only deleting the top folder and not what's inside when that can be done.
| Labels |
Added:
PR-5.0-dev
|
||
@HLeithner The folder library's delete method does that, so yes. But in all 4.x versions and also in 3.10 we had it like that for whatever reason, so I continue with that. Maybe @wilsonge remembers why it was kept in this way.
Haven't the foggiest :)
pretty sure to reduce it folders only
pretty sure to reduce it folders only
@HLeithner Sorry, I don't get it. What I know is that we have a script "build/deleted_file_check.php" which is used for checking deleted files and folders, and this lists them all, not only the topmost parent folder.
then why do we discuss it? waste of time... thanks anyway
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-04-03 10:35:02 |
| Closed_By | ⇒ | HLeithner |
then why do we discuss it? waste of time... thanks anyway
@HLeithner We can discuss that and I can work on improving the tool so it tells which files and folders can be removed from the list because due to later changes the complete folder can be removed. But it should not stop the current workflow of keeping the lists up to date. I agree that J5 would be a good point where we could change it. But as said, it requires some work.
@HLeithner P.S.: A different approach was once discussed in this issue: #34298 . It would be to leave the lists like they are but delete the folders only if they are empty.
Is our script not able to delete directories recursively?