Hi @artfulrobot - I wasn't able to reproduce through the UI... only by making authx requests a la StatelessFlowsTest
. So no guarantee it would fix the original issue you hit...
I can't claim to understand how this works, but....
I noticed in wordpress and drupal the first Container::boot
comes from a \CRM_Core_Config::singleton()
call in the initialise functions of the wordpress plugin / drupal module.
Adding the core config call into the standalone index.php before the CRM_Core_Resources::singleton call seems to resolve the issue? https://github.com/civicrm/civicrm-core/pull/29808
Incredible sleuthing!
I'm out of time today but look forward to delving into this suspicious call stack later in the week
I had a go updating my template repo for Standalone. I think it basically works!
There are 5 build targets:
Definitely rough round the edges... but has the potential to be a lot simpler than the Drupal-based image I think.
The repo is geared towards using docker compose, but should also be possible to build the core
image using the build script and then docker run
it so long as you provide a suitable env file based on the env.template
* I think I'm coming to understand the potential downside of composer-based approach here, in that your composer.json
/ composer install
is going to by design combine civicrm-core with any extensions you have into a single layer. I can see it being preferable to have a layer for civicrm-core code, then a layer for "upstream" extensions, then a layer for site specific code, which I think would lend itself to using a tarball-based install in the Dockerfile.
PR now merged - I wont close the issue immediately as it would be good to get some broader testing