[4.0] Add update SQL script for admin modules parameters changed by PR #33045

[richard67]

Pull Request for Issue #33314 .

Summary of Changes

This pull request (PR) adds an update SQL script (one for each db type) to fix the bootstrap size and header tag parameters of those admin modules touched by PR #33045 when updating from 4.0 Beta 7 or a previous 4.0 Beta.

The WHERE clause of the update statement is made as precise as possible in order to really make sure to update only the desired modules.

Testing Instructions

Requirements

This PR needs to be tested for all supported database types (MySQL, MariaDB and PostgreSQL). In case of MySQL or MariaDB, if you can use both the "MySQLi" and the "MySQL (PDO)" database driver, test with both.

All testers please report back which database and driver types you have tested so it can be properly recorded.

The PR cannot be tested with patchtester because it needs to test database updates. It has to be tested as described below with use of update packages or custom update URL's.

1. Have an installation of Joomla 4.0 Beta 7 or earlier (but not before Beta 4) with clean admin control panel modules, i.e. you haven't modified them, or make a new installation of 4.0 Beta 7 if you don't have that.

2. In Global Configuration, switch on "Debug System" and set "Error Reporting" to "Maximum" to be sure to get notice of any PHP or SQL errors.

3. Update to the latest 4.0 nightly build.

4. Check the admin dashboard and other dashboards (users, privary, ...).

Result: See section "Actual result BEFORE applying this Pull Request" below. The modules look weird.

5. Using a tool like e.g. phpMyAdmin or phpPgAdmin (depending on your database type), export the content of table #__modules (Replace #__ by your table prefix).

6. Update to the update package built by Drone for this PR.

7. Check again the admin dashboard and other dashboards (users, privary, ...).

Result: See section "Expected result AFTER applying this Pull Request" below. The modules look as they should.

8. Export again the content of table #__modules into a different file than the one used in step 5.

9. Compare the file created in step 8 with the one created in step 5, and compare the differences you can see with the differences shown in PR [4.0] Admin modules bootstrap #33045 for the base.sql file for your database type..

Result:

• The bootstrap size parameter has been changed from "6" to "12" and the header tag parameter has been changed from "h3" to "h2" wherever the particular parameter is present among the records of table #__modules which have been modified in file base.sql with PR [4.0] Admin modules bootstrap #33045.
• Other records of table #__modules have not been modified during the update.
• In opposite to what PR [4.0] Admin modules bootstrap #33045 does for the base.sql` file, this PR here doesn't add the bootstrap size or the header tag parameter when it is missing.

Actual result BEFORE applying this Pull Request

See issue #33314.

After updating a Joomla 4.0 Beta 7 (or previous 4.0 Beta) to latest nightly build:

Expected result AFTER applying this Pull Request

After updating a Joomla 4.0 Beta 7 (or previous 4.0 Beta) to the update package built by drone for this PR, the admin dashboard looks the same as after a new installation of current 4.0-dev or latest nightly without this PR applied.

Documentation Changes Required

None.

[brianteeman]

I have tested this item ✅ successfully on e72a196

Does what it says

---

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

[brianteeman]

The first update looks the same as the second. What am I missing?

[brianteeman]

Sorry forgot to add the test environment part

Database Type mysql
Database Version 10.5.7-MariaDB
Database Collation latin1_swedish_ci
Database Connection Collation utf8mb4_general_ci
Database Connection Encryption None
Database Server Supports Connection Encryption No
PHP Version 7.3.27

---

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

[richard67]

@brianteeman There are cases with space and without space between name and value, that's the difference between the first 2.

[brianteeman]

ah - i see that now. guess I need new glasses

[richard67]

@brianteeman Thanks for testing.

[chmst]

I have tested this item ✅ successfully on e72a196

Tested on MariaDB. The PR works as decribed. Own modules, added to the dashboard by the user, remain unchanged, this is ok. If a user has changed the sizes of modules before this PR, they are overwritten. As these changes had no consequences before #33045 was merged, this is correct too.

---

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

[richard67]

RTC

---

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

[richard67]

I set it to RTC because it has 2 tests, but maybe @alikon can test it with PostgreSQL in addition. If it fails I can revert RTC. Of course I have tested my PR myself with PostgreSQL, too.

[SharkyKZ]

This should be reverted. User data should not be randomly changed without good reason.

[richard67]

The good reason can be found in the issue.

[SharkyKZ]

It's not good enough.

[richard67]

@SharkyKZ I think that's a matter of taste. But I've forwarded your concerns to the maintainers and have no problem if they agree with you and revert this PR.

[richard67]

@SharkyKZ How good a reason is depends not only on the severity of the issue but also on the importance of the data we update or not update. Here we are updating only stuff which never existed before J4 and where one very unlikely ever has made some important changes, the parameters of the template styles of the "Atum" template admin modules. Be honest: Who do you think has made any important changes on these? It would be different if I'd update some menu item stuff, but here I think your concerns are more academical than of practical relevance.

Update: Had mixed it up with another PR so had to correct something in my previous comment, see strike through. But it also applies here that it's something which came with J4 and not from J3 what we update.

[brianteeman]

In general I agree that changing params like this PR does should not be done BUT as explained by @richard67 there are always exceptions and this is one

[richard67]

I just see I've mixed up this one here with another one so I had to correct my previous comment a bit, see the strike through text. But the main message stays the same.