[4.0] Don't use the "id" column as criterion in WHERE clauses for updating menu items in update SQL scripts #30701
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
id
s in the#__menu
table.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
id
of the smart search menu item in the admin menu (menutype
='main') is 21, see update SQL2.5.0-2011-12-22.sql
in 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
id
of 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
id
as the criterion in theWHERE
clause when updating some menu item with an update SQL script.Unfortunately there was added an update SQL script
4.0.0-2019-05-05.sql
which 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_tags
menu item hasid
=301, and the menu item forcom_associations
hasid
=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-codedid
not matching.This PR here fixes that by using the combination of
menutype
='main' andpath
as 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-codedid
in update SQL scripts for other menu types (which we don't have), we would have to include also theclient_id
into the criterion.We are lucky we don't have other update SQL scripts with that problem, using
id
as criterion in aWHERE
clause..In addition, this PR adds a new update SQL script
4.0.0-2020-09-22.sql
for 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_finder
menu 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
id
of the menu item forcom_associations
is 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
id
s 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.link
value of the menu item forcom_associations
.Result: It is
index.php?option=com_associations
.link
value of the menu item forcom_associations
.Result: It is still the same as in step 2 before the update.
link
value of the menu item forcom_associations
.Result: It is
index.php?option=com_associations&view=associations
, i.e. the&view=associations
has 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.