Pull Request for Issue #19348 .

Summary of Changes

This Pull Request (PR) reverts the removal of column custom_data from the extensions table made once with PR #14750 , as requested by extension developers in the referenced issue.

Testing Instructions

Test 1: Reproduce the issue

1. Have a current 4.0-dev branch or latest nightly build, either a new installation or one updated from 3.10, whatever you just have, and if you have nothing just install one.

2. With a tool like e.g. phpMyAdmin (MySQL or MariaDB) or phpPgAdmin (PostgreSQL), check if column custom_data of the extensions table exists.

Result: See section "Actual result BEFORE applying this Pull Request" below. The column doesn't exist.

Test 2: New installation with the patch of this PR applied

This test shall verify that that the column custom_data of the extensions table is there after a new installation, and that installing extensions of any kind works.

1. Apply the patch of this PR on a current 4.0-dev branch or latest nightly build and make a new installation, or use the installation package which has been built for this PR to make a new installation.

You can find a page with a link to an installation package for download as shown in the following screenshot with the green ellipse (if necessary expand the "Show all checks" to see that):

2. After the installation has finished, login to backend ang to to "System - Information - Database. Check if there are database problems shown.

Result: If you have used the installation package which has been built for this PR, there is only one database problem about not matching versions shown, otherwise no database problem is shown.

3. With a tool like e.g. phpMyAdmin (MySQL or MariaDB) or phpPgAdmin (PostgreSQL), check if column custom_data of the extensions table exists.

Result: The column exists.

4. Install extensions of different types, whatever you can find. Possible types are:

• Component
• File
• Language
• Library
• Module
• Package
• Plugin
• Template

I'm not sure if you can find extensions of all of these types which are ready for J4, but test whatever you can, the more, the better.

Result: No SQL errors about column custom_data not having a default value. The PHP added back with this PR prevents this.

Test 3: Update a 3.10 to a 4 which has the patch of this PR applied

This test shall verify that that the column custom_data of the extensions table is still there after updating a 3.10.

1. Update a current 3.10-dev or 3.10 nightly to a 4.0-dev which contains the patch of this PR.

You can find a page with a link to a custom update URL and an update package for download at the same place as described in thep 1 or the previous test 1 for the installation package.

Result: The update suceeds without SQL errors.

2. With a tool like e.g. phpMyAdmin (MySQL or MariaDB) or phpPgAdmin (PostgreSQL), check if column custom_data of the extensions table exists.

Result: The column exists.

Test 4: Update a 4 without this patch to a 4 which has the patch of this PR applied, including a manual pre-update procedure

This test shall verify that the manual pre-update procedure to fix updating e.g. from 4.0 Beta-3 to a future Beta-4 which will contain the patch of this PR is sufficient to make the update succeed.

1. Manual pre-update step: On an installation of a current 4.0-dev branch or latest nightly build which does not contain the patch of this PR, use a tool like e.g. phpMyAdmin (MySQL or MariaDB) or phpPgAdmin (PostgreSQL) to run following SQL commands, having replaced #_ by the database prefix of your installation.

On MySQL or MariaDB databases:

ALTER TABLE `#__extensions` ADD COLUMN `custom_data` text NOT NULL;

On PostgreSQL databases:

ALTER TABLE "#__extensions" ADD COLUMN "custom_data" text NOT NULL;

2. Update this installation to a newer 4.0-dev which contains the patch of this PR.
   See step 1 of test 1 about where to find a custom update URL or update package.

Result: The update suceeds without SQL errors.

3. With a tool like e.g. phpMyAdmin (MySQL or MariaDB) or phpPgAdmin (PostgreSQL), check if column custom_data of the extensions table still exists.

Result: The column still exists.

4. Install extensions of different types, whatever you can find. See step 4 of test 2 for possible extension types.

Result: No SQL errors about column custom_data not having a default value. The PHP added back with this PR prevents this.

Actual result BEFORE applying this Pull Request

Colum custom_data of the #__extensions table is removed when updating 3.10 to 4 and not existing on a new installation of 4.

Expected result AFTER applying this Pull Request

Colum custom_data of the #__extensions table is not removed when updating 3.10 to 4, and it is existing on a installation of 4.

Updating a previous 4 Beta version to a future one which contains this PR will require a manual step for other reasons (see e.g. #30333 #30363 #30365 for details). After this manual step, colum custom_data of the #__extensions tables will be back, and after the update it will be initialized properly when installing any kind of extension.

Documentation Changes Required

We haven't mentioned the removal of this column in https://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_4, as far as I can see, so no need to change something there.

But in the release notes of a future J4 Beta which will include this PR we need to describe the manual step, see "Test 4" in the testing instructions. In additon it might need other manual steps for another issue not related to this PR, see e.g. #30369 .