[4.0] Don't use the "id" column as criterion in WHERE clauses for updating menu items in update SQL scripts#30701
Conversation
…update-sql-with-fixed-menu-item-ids
|
Are'nt the new update sql files redundant?
|
|
@infograf768 The new scripts are needed because the corrected old scripts will not run again when updating e.g. a Beta 4 to the future version where this PR is included, because only those update SQL scripts will be extecuted which have a version and date in their name being larger and younger than the schema version stored in database. The few redundant statements which are the same in the old, modified file and the new file don't do harm. But as I said, the new ones are needed to update a previous 4.0 version where the link e.g. of com_associations has not been corrected, like my test 2 does it. |
|
I have tested this item ✅ successfully on 7f69470 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30701. |
|
I have tested this item ✅ successfully on 7f69470 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30701. |
|
RTC This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30701. |
|
Thanks! |
Pull Request for Issue #30696 (comment).
Summary of Changes
Depending on the update history which an installation has gone through in past, menu items added by the core to the database may have different
ids in the#__menutable.E.g. on an installation which has gone through an update to 2.5 in past, when Smart Search was added to the core, the
idof the smart search menu item in the admin menu (menutype='main') is 21, see update SQL2.5.0-2011-12-22.sqlin theJoomla_2.5.28-Stable-Full_Package.zip, and it will still be 21 now after the years and all updates. This is e.g. the case on my private website, which is on 3.9.21 right now.But on a new installation of 3.9.x the
idof the smart search menu item in the admin menu is 18, and on a new installation of 4.0-dev it is 13.This is just one example. In principle it can apply to any menu item added by the core with some update after Joomla 1.0.
Therefore the golden rule is never to use the
idas the criterion in theWHEREclause when updating some menu item with an update SQL script.Unfortunately there was added an update SQL script
4.0.0-2019-05-05.sqlwhich breaks this rule with PR #24801 in May last year, and for some reason I haven't noticed that PR and so haven't protested.E.g. on my private website, the
com_tagsmenu item hasid=301, and the menu item forcom_associationshasid=346. Both of these menu items have a different link than the one it has on a new 3.9 installation. The link should be normalized by the update SQL script handled with this PR, but it isn't because of the hard-codedidnot matching.This PR here fixes that by using the combination of
menutype='main' andpathas criterion in the update SQL script4.0.0-2019-05-05.sql.With
menutype='main' we can be sure it only affects the admin main menu because this name is granted to be unique and reserved for that purpose. If we had that problem with hard-codedidin update SQL scripts for other menu types (which we don't have), we would have to include also theclient_idinto the criterion.We are lucky we don't have other update SQL scripts with that problem, using
idas criterion in aWHEREclause..In addition, this PR adds a new update SQL script
4.0.0-2020-09-22.sqlfor updating previous 4.0 Beta versions to a version which includes this PR, to fix those admin menu items which have not been fixed when updating a 3.10 with a long update history to that previous Beta version.If this PR will be merged before the next Beta, it might make sense to combine that new update SQL with the recently added
4.0.0-2020-09-19.sql, i.e. remove the new script and put its content into the existing one which already fixes thecom_findermenu item, so we don't again add a new script. We already have so many.Testing Instructions
This PR should be tested with both kinds of databases, MySQL (or MariaDB) and PostgreSQL.
Testers please report back which kind of database you've used for the test. If you can test with both, MySQL/MariaDB and PostgreSQL, please do so. Thanks in advance.
Test 1: Verify that nothing is broken by this PR when updating a fresh installed 3.10
#__menu(replace#__by your table prefix) in an SQL or a CSV file.Verify that for menu items with
menutype='main' there is no difference except the generated titles and aliases of links of type 'separator'.Result: There is no difference, i.e. updating a 3.10 with the patch of this PR doesn't break anything compared to updating without the patch.
Test 2: Verify that this PR really fixes an issue and is not just cosmetics
idof the menu item forcom_associationsis larger than 101 (which is the site menu home item), update this site to the latest 3.10 nightly build.Otherwise, if you don't have such a site, make a new installation of a latest 3.10 nightly which has been patched in a way so it has menu item
ids like my private website. You can donwload such an installation package from here: https://test5.richard-fath.de/Joomla_3.10.0-alpha3-dev-Development-Full_Package_2020-09-22_pr-30701.zip.linkvalue of the menu item forcom_associations.Result: It is
index.php?option=com_associations.linkvalue of the menu item forcom_associations.Result: It is still the same as in step 2 before the update.
linkvalue of the menu item forcom_associations.Result: It is
index.php?option=com_associations&view=associations, i.e. the&view=associationshas been appended by the update SQL script.Result: Without the patch of this PR, some admin menu item links are not normalized with the update of 3.10 to a current 4.0 nightly. This will then be fixed by a later update to a future 4.0 Beta or RC version which will include this PR.
Actual result BEFORE applying this Pull Request
When updating a 3.10 site with a longer update history back to 2.5 or before, some admin menu item links for new components added to the core during the update history are not normalized with the update SQL script
4.0.0-2019-05-05.sql.Expected result AFTER applying this Pull Request
When updating a 3.10 site with a longer update history back to 2.5 or before, all admin menu item links for new components added to the core during the update history are normalized with the update SQL script
4.0.0-2019-05-05.sql.Updating a 3.10 with a shorter update history, e.g. newly installed or updated from staging/3.9.x, works as well as before.
Documentation Changes Required
None.