[3.10] Don't use hard-coded extension_id to insert the EOS310 plugin in update SQL scripts

[richard67]

Pull Request for Issue #35032 .

Summary of Changes

Don't use a hard-coded extension_id for inserting the EOS310 plugin extension in update SQL scripts but let the auto-increment of the ID column decide.

This will result in the extension_id having a value above 10000 like 3rd party extensions have, but this is ok since we don't use that hard-coded value of 10000 anymore but the ExtensionHelper to determine if an extension is core or not.

The change is necessary because it can happen that the extension_id is already used, in case of issue 35032 it is extension_id 496 being already used by the mod_latestactions extension, and this results in an SQL error which makes the further SQL updates not being executed.

In case of issue 35032 it was the very last SQL statement in the last update SQL script, so the damage was not so big. But this will not be the case anymore if during the life time of 3.10 further update SQL scripts will be added.

Normally mod_latestactions should not have an extension_id of 496 like it was on the site with the issue because in 3.9.0-2018-05-20.sql we insert it with id 319 when updating versions older than that.

Testing Instructions

Preparation

Important hint: This PR is for 3.10, but it deals with updating from 3.9 to 3.10, so the tests have to be started on a 3.9 site (any recent version or nightly build) or when using a git clone the staging branch.

If you don't have an installation of that, make a new installation using an empty database.

If you have a 3.9.28 (or similar) site with a longer update history, check if there is already a core extension with ID (in database extension_id) = 496.

If this is the case, you are done ready for the test and can directly jump to section "Test Procedure" below.

Otherwise, if there is no extension with ID = 496, execute the following SQL in your database to insert a dummy extension, haing replaced the "#__" in the table name by your actual table prefix:

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
INSERT INTO `#__extensions` (`extension_id`, `package_id`, `name`, `type`, `element`, `folder`, `client_id`, `enabled`, `access`, `protected`, `manifest_cache`, `params`, `custom_data`, `system_data`, `checked_out`, `checked_out_time`, `ordering`, `state`) VALUES
(496, 0, 'test_pr_35034_dummy', 'file', 'dummy', '', 0, 1, 1, 1, '{\"name\":\"test_pr_35034_dummy\",\"type\":\"file\",\"creationDate\":\"July 2021\",\"author\":\"Joomla! Project\",\"copyright\":\"(C) 2005 - 2020 Open Source Matters. All rights reserved\",\"authorEmail\":\"admin@joomla.org\",\"authorUrl\":\"www.joomla.org\",\"version\":\"3.9.29-dev\",\"description\":\"test_pr_35034_dummy\",\"group\":\"\"}', '', '', '', 0, '0000-00-00 00:00:00', 0, 0);

The above SQL statements are for MySQL or MariaDB. If you are using PostgreSQL or MS SQL server, leave away the first SET SQL_MODE statement and adapt names quoting and the zero datetime to that database needs.

Test Procedure

1. Having prepared the site as described above, make a backup so you can restore the starting conditions later.

• When using an installed 3.9 site, make a backup of the database, e.g. by exporting it into SQL file from phpMyAdmin, and of the Joomla root folder and all its content.
• When using a git clone, just backup the database.

2. Set error reporting to maximum in Global Configuration.

3. Update the CMS to the latest 3.10 nightly build.

• If you can use Live Update, change the update channel to "Custom URL" in the Joomla Update Component's options and enter the regular update URL https://update.joomla.org/core/nightlies/next_minor_list.xml of the 3.10 nightlies.
• If you can't use Live Update, download the 3.10 update package from here https://developer.joomla.org/nightlies/Joomla_3.10.0-rc2-dev-Development-Update_Package.zip and use Upload & Update.

Result: See section "Actual result BEFORE applying this Pull Request" below. Verify that the details shown there apply in your backend.

4. Restore the starting conditions.

• When having started with an installed 3.9 site, delete all tables in your database, restore the database backup made in step 1 e.g. by importing the SQL file with phpMyAdmin, save your configuration.php outside the Joomla root, delete all content of your Joomla root, unpack the backup of the files and folders and copy the configuration.php back to the Joomla root.
• When having started on a git clone with the staging branch, revert your branch back to the initial state by using the following git commands on a command shell (Windows CMD, Linux Bash, ...) in your Jomla root:

git clean -d -x -f
git checkout .

5. Set error reporting to maximum in Global Configuration.

6. Update the CMS to the current 3.10-dev branch plus this PR applied.

• If you can use Live Update, you won't be able to use the custom update URL created by Drone for this package because that update site XML only targets version 3.10, i.e. you wont find an update on 3.9.
  You can use the custom URL https://test5.richard-fath.de/pr-35034_list.xml instead. It points to the same update server but targets also 3.9 versions.
• If you can't use Live Update, download the 3.10 update package created by Drone and use Upload & Update.

Result: See section "Actual result BEFORE applying this Pull Request" below. Verify that the details shown there apply in your backend.

7. Verify in the plugin manager that you can disable and enable the quickicon plugin "Joomla! 3.10 End Of Support Notification" in the same way as other quickicon plugins.

Actual result BEFORE applying this Pull Request

The update has finished but shows a warning alert about SQL error "Duplicate entry '496' for key '#__extensions.PRIMARY' as described in issue #35032 .

The database checker shows one problem about not matching database schema version:

The "Fix" button works. But it does not do anything beside fixing the schema version mismatch because database structure was already up to date, the SQL which has not been run was not a structure change.

The quickicon plugin "Joomla! 3.10 End Of Support Notification" has not been added with the update.

Because the SQL statement which failed was the last one in the last update SQL script and later update actions in script.php have been processed, the updated site is ok except of the missing EOS quickicon plugin. But that might change in future if more 3.10 update SQL scripts will be added to run after that one which failed here, and then these would be skipped, too, which could leat to larger damages.

Expected result AFTER applying this Pull Request

The update has finished without any warning alert.

The database checker shows only the usual problem about not matching database update version when using update packages built by Drone for pull requests:

The quickicon plugin "Joomla! 3.10 End Of Support Notification" has been added with the update.

Documentation Changes Required

None.

[zero-24]

Merging thanks :)

[richard67]

Thanks too.