[#38567] - [4.2] Correctly revert pull request no. 38244 for updating from 4.2.0 RC 1
- Fixed in Code Base
- 28 Aug 2022
- Medium
- Build: 4.2-dev
- # 38567
- richard67:4.2-dev-fix-reverting-of-pr-38244
Pull Request for Issue #38554 (comment) .
Summary of Changes
With pull request (PR) #38244 , a new plugin "plg_fields_menuitem" was added, which has been released with 4.2.0 Release Candidate 1 on July 19.
This PR has been reverted after that on August 14 with this commit: 31a2677
But as we guarantee that an RC 1 can be correctly updated, it was not right and not sufficient just to remove the update SQL scripts "4.2.0-2022-07-07.sql".
Because it was always subject of discussions in past if old update SQL scripts can be touched or removed, this PR here adds the removed scripts "4.2.0-2022-07-07.sql" back and comment out their content for documentation. In this special case here this is not necessary because we add a newer update SQL script so we won't have a problem with the schema version. But in other cases deleting an update SQL script may cause problems, so here I keep the best practice to serve as an example, too.
In addition, this PR here adds new update SQL scripts "4.2.1-2022-08-23.sql" to remove the extension record when updating a 4.2.0-rc1. If the record is not there, the delete statement will not cause a failure, it will just not do anything.
Finally, this PR adds the obsolete files and folders from the reverted plugin to the lists of files and folders in script.php so they are deleted on update.
Testing Instructions
-
Update any version except of a 4.2.0-rc1 to 4.2.1-dev.
-
Update a 4.2.0-rc1 to 4.2.1-dev.
In both cases use the latest 4.2.1-dev nightly to get the actual result or use the update package or custom update URL created by drone for this PR to get the expected result.
After the update:
- Check in the extensions table in your database if there is a record for "plg_fields_menuitem".
- Check if there is a folder "plugins/fields/menuitem" with subfolders and files.
Actual result BEFORE applying this Pull Request
After update from any other version than 4.2.0-rc1 to 4.2.1-dev, there is no record for the "plg_fields_menuitem" in the extensions table.
After update from 4.2.0-rc1 to 4.2.1-dev, there is a record for the "plg_fields_menuitem" in the extensions table, and there are obsolete files and folders of the reverted plugin, see https://github.com/joomla/joomla-cms/pull/38567/files#diff-db7eb77540ff419bd7e6557d2779f4cf1e31158c20cb4b63dbbe8d6c426385adR6439-R6443 for the files.
Expected result AFTER applying this Pull Request
In any case there is no record for the "plg_fields_menuitem" in the extensions table, and in case of updating from 4.2.0-rc1 the obsolete files and folders are been removed.
Documentation Changes Required
None.
joomla-cms-bot
- | Category | ⇒ | SQL Administration com_admin Postgresql |
As the files were shipped with an rc dont they have to be removed as well?
@brianteeman No. See the description for an explanation (I've updated it meanwhile to be more precise):
Removing them on update would cause the database checker complaining about a wrong schema version if no newer update SQL would be added in the mean time, and not removing them on update but not having them for new installations would require an exception in the "build/deleted_file_check.php" script so that this tool does not report them as to be added to the list of deleted files.
I meant the files for the fields not the files for the sql
As the files were shipped with an rc dont they have to be removed as well?
@brianteeman No. See the description for an explanation (I've updated it meanwhile to be more precise):
Removing them on update would cause the database checker complaining about a wrong schema version if no newer update SQL would be added in the mean time, and not removing them on update but not having them for new installations would require an exception in the "build/deleted_file_check.php" script so that this tool does not report them as to be added to the list of deleted files.
Hmm, wait, as I have added new scripts with a later version, I could indeed remove them on update (but then have to add them to script.php, too).
I meant the files for the fields not the files for the sql
Oh yes, these should be removed on update.
I will change this PR to draft / work in progress and later adjust it. Gotta do something else first.
| Title |
|
||||||
| Labels |
Added:
Release Blocker
?
|
||
| Title |
|
||||||
PR is ready for testing. See the updated description for my motivation to reintroduce the old update SQL scripts. In this special case here this would not have been necessary, but we had discussions with users who were confused when comparing their files system with a backup, and so I decided to do it the proper way, which also better for documentation of the changes.
| Status | New | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-08-28 08:15:25 |
| Closed_By | ⇒ | roland-d | |
| Labels |
Removed:
Release Blocker
|
||
Thank you
As the files were shipped with an rc dont they have to be removed as well?