Component-Extensions - Ensure the initial activation list matches

[totten]

Overview

Fixes a regression from #26036 (merged circa 5.63-dev) where old-style installation procedures may produce inconsistent data.

This problem was introduced by 5.63, but it became symptomatic in 5.64 because #26208 makes the system reliant on the extension-data.

Steps to Reproduce

Perform an installation using any of the old-style installation routines, such as:

• setup.sh
• drush civicrm-install
• Joomla Web Installer
• Manual loading of civicrm.mysql, civicrm_data.mysql, or similar

For example, I used this procedure:

./bin/setup.sh -Dgsdf           ## With basic data
#./bin/setup.sh -Dgsef          ## With example data

cv flush --level=cms-full

cv vget enable_components -v
cv ext:list -Li

Note: For newer install procedures (civicrm-setup), it seems to be OK (*based on very cursory testing of cv core:install and civibuild reinstall), but I haven't stress-tested. I expect these commands worked because civicrm-setup has additional logic for initializing components+extensions.

Before

After installation, the list of "Components" and "Extensions" is out-of-sync.

After

After installation, the list of "Components" and "Extensions" match.

Technical Details

There is a structural asymmetry - when dealing with an empty/default dataset, "settings"/"components" will inherit a default activation-list; but "extensions" start with an empty activation-list. You must have a record to show the extension as active.

This patch makes the live-setting-default (for enable_components) and the stored default (for civicrm_extension) match. To ensure that they continue matching, they will need to be updated in tandem. I added comments to both sides to point this out.

[civibot]

(Standard links)

• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[colemanw]

@totten it looks like this will work great for now because it adds to sql/civicrm_data/civicrm_extension.sqldata.php - but that system comes with a pretty big caveat:

// Note this is a limited interim technique for installing core extensions -  the goal is that core extensions would be installed
// in the setup routine based on their tags & using the standard extension install api.
// do not try this at home folks.

We probably ought to add this to the comments, because it's not explicitly stated but "do not try at home" actually translates to "this doesn't work with extensions that have any installer logic". Namely, it doesn't work with SearchKit, so we're still going to have that problem. But at least this solves a problem so based on that, MOP.

PS: If we really can't solve the searchKit install issue, I guess a better-than-nothing hack might be to include SK tables in civicrm_generated?

[totten]

@colemanw Yeah, I used the low-tech approach here because 5.63 is in RC now (want keep the RC stable; and the data isn't gonna change within 5.63.x). But I agree it's not ideal long-term -- we want something more structural/automatic.