I have tested this item ✅ successfully on 2e49b38

I am not sure about that
UPDATE #__menuSETlink='index.php?option=com_finder' WHERE id=13;

default com_finder menu in 3.x is not at id 13 but 18, which may mean that an update would chnage com_newsfeeds link instead of com_finder, if I do not mistake.

That is a different issue if correct

No, it is not a different issue. You have to change the WHERE clause in your update SQL script to not use the ID, except if you can be sure that on any installation with any long update history it always has the same ID. This can not be granted, and so the golden rule is to never use the ID to identify a menu item for an update with an SQL update script.

If you want I can advise with a proper WHEREclause.

I suggest to use the following where clause:

WHERE `menutype`='main' AND `title`='com_finder' AND `link`='index.php?option=com_finder&view=index'

For example if someone had a Joomla 1.5 or so installation and updated it to 2.5, then the menuitem ID would be 21, see update SQL 2.5.0-2011-12-22.sql in the Joomla_2.5.28-Stable-Full_Package.zip, and it will still be 21 now after the years and all updates.

it seems more correct imho, the only left question is about the alternative admin menus that can be configured .....

it seems more correct imho, the only left question is about the alternative admin menus that can be configured .....

@alikon Those will not have menutype='main'.

And no, it is not more correct, it is just correct, because using the ID as criteria in the WHERE clause is DEFINITELY wrong, see my previous comment about ID of that menu item being 21 when coming from pre-2.5 in the update history, and as @infograf768 wrote it is 18 on a new installed staging.

sorry my bad .... i've not checked deep that alternative admin menu have a proper different menutype

Happy to update - you should note that the code was copied from
administrator\components\com_admin\sql\updates\mysql\4.0.0-2019-05-05.sql

you should note that the code was copied from
administrator\components\com_admin\sql\updates\mysql\4.0.0-2019-05-05.sql

@brianteeman OMG!!! I have to check and if possible fix that! Thank you for that information,

oh shit ..... i need to ask to myself where i was when that s..... was proposed/merged

@alikon Initially it was that one: #24801 . But let's continue that discussion somewhere else in order not to pollute this PR with off-topic. I will check and if necessary make an issue or PR.

sure right......ping me if you need help/tests on that matter

I have tested this item ✅ successfully on f579ff9

@alikon Did you do a real test? Or just code review? Am preparing real test, but it takes time. It needs to test new installation with this PR applied and also update SQL statements test on a 4.0-dev for both MySQL and PostgreSQL.

i've made a quick test on my current staging 4.0-dev.... probably this is not enough....well i'll remove my test

I have not tested this item.

too much quick test

@alikon No, it's ok. I'll do the complete test. From you it's ok with 1 real test and a code review.

@alikon In your case, as you are an SQL expert with both MySQL and PostgreSQL, a code review could be sufficient ;-) Just wanted to know how you had tested, that's why I had asked. If you had said you have done all real tests I could have decided to be lazy and do the code review only ;-)

I have tested this item ✅ successfully on f579ff9

Tested

• New installation with patch applied on MySQL
• Update SQL applied on clean 4.0-dev on MySQL
• New installation with patch applied on PostgreSQL
• Update SQL applied on clean 4.0-dev on PostgreSQL

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/30696.}

I have tested this item ✅ successfully on f579ff9

rtc
happy i could help...

Tks

thanks