FYI on related issue triggered by Admin Utilties

[awestuk]

This isn't a problem with AU, which seems to do everything correctly, but just an FYI that both AU and Profile Sync are triggering a process that causes an error when CiviRules is installed:

https://lab.civicrm.org/extensions/civirules/-/issues/175

Doesn't seem to be CiviRules either - looks like more of a Core issue: the mysterious sometimes-extension-classes-don't-load-properly issue that comes up on Mattermost from time to time. But as it's triggered when AU is in place I figured people might mention it.

It's at least replicable! Trying to dig into it here.

[christianwach]

@awestuk Interesting - thanks for the report.

Looks to me from the backtrace in the Lab ticket that calling civi_wp()->initialize() in a callback from civicrm_config triggers the issue. Since the CiviCRM_For_WordPress_Admin::initialize() method hasn't completed before being called again, the static variable hasn't been set and it cannot return early.

Having said that, the ClassLoader should have been set up in the first call (i.e. before it reaches $config = CRM_Core_Config::singleton();) so there's a bit of a conundrum:

• Should plugins be prevented from checking if CiviCRM is initialised before proceeding during that callback?
• Or should CiviCRM-WordPress recognise a recursive call in CiviCRM_For_WordPress_Admin::initialize() and bail early?
• And if the latter, should the return value be true or false? Is CiviCRM initialised or not at that point?

I can remove those checks from my plugins to avoid the issue in the short term, but the issue will remain dormant unless it's also addressed in CiviCRM-WordPress. This could be as simple as checking doing_action( 'civicrm_config' ) but see the final bullet point above. Perhaps documentation and prevention is a better route?

[christianwach]

@awestuk I've removed the initialized() checks from civicrm_config callbacks in this plugin and in CiviCRM Profile Sync. Let me know if they help. I'll release new versions on the WordPress Plugin Directory in due course.

[awestuk]

That sounds a knotty problem, but a sensible workaround! I'll test asap.

This and its PR look potentially relevant, although it's a different error message: https://lab.civicrm.org/dev/core/-/issues/3502