l that update script overwrite any existing customisations?

Sorry, I didn't understand the question. If we are talking about templates, then by default the tag is not included in the text. It is difficult to imagine a situation in which one of the users still added a tag to the text, which in the end does not show anything.

If a user has customised that mail template then applying your update will overwrite their changes. You can either not have an update query OR you will need to write a query that only alters the params.

How can it be? We are talking about a fresh installation of Joomla 4.2 and an upgrade from 3x.

@richard67 am I wrong? Wouldn't this change be applied on a normal 4.x update as well?

@richard67 am I wrong? Wouldn't this change be applied on a normal 4.x update as well?

You are wrong.

When updating a 4.0.0, the database schema version is "4.0.0-2021-08-17" because that's the name of the youngest schema update for 4.0.0 at that time, and now we update to a 4.x.y and have a script 4.0.0-2020-12-20.sql. The schema version "4.0.0-2020-12-20" in that script's name is lower than "4.0.0-2021-08-17" when comparing with version_compare, and so it will not run.

It will only run when we update a version (old alpha or beta or maybe also RC) where the script 4.0.0-2020-12-20.sql was not there yet.

You would be right if this PR would have added a new 4.0.0 update SQL with a newer date. This then would run when we would update a 4.0.0.

But this is not the case, and this is a perfect example why it sometimes makes sense to update the old update SQL scripts which you claim to be immutable because (as your question here shows, too), never really understood how the database updates work.

I am almost sure that for the one or the other of your recent PRs where you said you won't make update SQL scripts it would have been possible to do the same, change the old update SQL so at least updating from 3.10 will result in the right params.

But you never accepted any of my explanations why we can and sometimes should change old update SQL scripts.

And so I gave it up to check your PRs for that and argue with you.

How can it be? We are talking about a fresh installation of Joomla 4.2 and an upgrade from 3x.

@Kostelano You are right. Brian just doesn't understand how it works.

I might not know how it works according to you but surely this PR will only fix the bug for new installs and new upgrades from joomla 3. All other sites will still have the extra param.

this is not the first time that we have had an almost identical issue with the params for the updates see #37504 which @richard67 approved and was a pr created because of an issue also reported by @Kostelano

It needs an update sql like this

UPDATE `#__mail_templates`
	 SET `params` = '{"tags":["name","sitename","siteurl","username","password_clear"]}'
 WHERE `template_id` = 'com_users.registration.user.registration_mail_w_pw' AND `params` = '{"tags":["name","sitename","activate","siteurl","username","password_clear"]}';
 
UPDATE `#__mail_templates`
	 SET `params` = '{"tags":["name","sitename","siteurl","username","password_clear"]}'
 WHERE `template_id` = 'com_users.registration.user.registration_mail' AND `params` = '{"tags":["name","sitename","activate","siteurl","username","password_clear"]}';

Ok, I'll add tomorrow.

Got it today, added. Should be OK.

Now I have rechecked and everything works - both for a new installation and for a live site. Description corrected.

I have tested this item ✅ successfully on dc1f750

@Kostelano Was there the need for updating the branch, i.e. conflicts, or broken drone? You know, when you update the branch, it resets the counter for human tests, so if nobody restores that test in the issue tracker, we will not find a PR which has 2 tests when we search for that in the issue tracker. That means additional work for us, so we should avoid unnecessary branch updates. Now I will go and restore Quy's test.

@richard67 I didn't know that, sorry. Let then hangs PR so.

@Kostelano Well, it still might need branch updates when there are conflicts or when you want to restart drone or appveyor and can't do that directly in their UI. Let me know when you have a PR which needs tests to be restored because commits after tests were just clean branch updates or small changes in code comments or so, or when you find such PRs. Thanks for your contributions by the way.

I have tested this item ✅ successfully on cf42737

I've tested installations as well as updates. For the latter, I've used the custom URL created by drone for this PR for the live update with the update component to update from current 4.2-dev to this PR.

I've tested with both MySQL and PostgreSQL, so it was 4 tests in total, and all SQL changes made by this PR were covered by these tests.

RTC

Hello @Kostelano I would like to get this into 4.2.7 but the filename of the SQL file should be updated as it is now 4.2.6-2022-11-11.sql. Can you please update these filenames so I can merge this?

@roland-d, done.

@Kostelano Thank you, now we wait for Drone :)

Thank you