Add *.boot.setting.php meta for CIVICRM_UF_BASEURL and CIVICRM_DOMAIN_ID

[ufundo]

Overview

EDIT: Jenkins / cv bootstrap didn't like the addition of CIVICRM_UF as a defined env var, for reasons I can't quite pin down - so I've rolled that back for now

Now just adds CIVICRM_UF_BASEURL and CIVICRM_DOMAIN_ID as globals, which means:
a) they can be provided using environment variables,
b) CIVICRM_DOMAIN_ID will default to 1 if not set (so the define('CIVICRM_DOMAIN_ID', 1) is not required in civicrm.settings.php)

Before

• CIVICRM_DOMAIN_ID and CIVICRM_UF_BASEURL must be defined in civicrm.settings.php
• $civicrm_root global must be set in civicrm.settings.php

After

• CIVICRM_UF_BASEURL can be provided as env var on in civicrm.settings.php
• CIVICRM_DOMAIN_ID can be provided as env var or in civicrm.settings.php - but if not provided will default to 1
• $civicrm_root global will be set relative to SettingsManager file

Technical details

All the above applies only to Standalone, as that is where we have the SettingsManager::bootSettings function wired into the bootstrap, in order to source env vars for these kind of things early enough.

I've put in an explicit opt out from the naming convention in settings style test, instead of a backdated value for the version added.

...

Previous bolder scope:

---

Following on from #30533 - this brings a few more constants into the *.boot.setting.php system, in order that they can be loaded from environment variables or defaults.

It's based upon #31150 - between the two I was able to run Standalone without civicrm.settings.php - just providing a three env vars.

Before

• civicrm.settings.php provides many critical constants

After

• provide CIVICRM_DSN, CIVICRM_UF_BASEURL and CIVICRM_UF as environment variables
• set CIVICRM_SETTINGS_PATH to a non-existent path (to work around current is installed check)

• delete civicrm.settings.php
• Standalone still runs 😀

Comments

It's running Smarty2, but it's running....

@michaelmcandrew could you have a go testing this branch with the Docker container?

[civibot]

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...

• If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
• A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
• A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
• If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
• Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
• A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
• To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
• For more information about contributing, see CONTRIBUTING.md.

Quick links for reviewers...

• ➡️ PR Demo site (can be rebuilt with the command test this please).
• 📖 Review standards
• 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗

[michaelmcandrew]

@ufundo - I tried this out as follows:

1. Added the following two lines to the civicrm Dockerfile

ENV CIVICRM_SETTINGS_PATH=/var/www/html/setting-stub # presume that this path is OK

RUN touch setting-stub

1. Built an image with the build.php script from https://github.com/civicrm/civicrm-docker as follows: php build.php --download-url=https://storage.googleapis.com/civicrm-build/pr/core-31155/civicrm-5.79.alpha1-standalone-202409202150.tar.gz --image-prefix=pr31155 --php-version=8.3 --skip-push --no-cache.
2. Used the current example compose.yaml file but with services.app.image set to pr31155/civicrm:latest
3. docker compose up -d and waited for the database to initialise (you'll likely need/want to docker compose down -v if you have existing volumes from a previous 'up -d')
4. Installed civicrm with docker compose exec -e CIVICRM_ADMIN_USER=admin -e CIVICRM_ADMIN_PASS=password app civicrm-docker-install
5. Visited http://localhost:8760 and noted that I can log in with my username and password 👍
6. Removed /var/www/html/private/civicrm.settings.php and (sadly 👎) be confronted with the installer and the following warnings:

Warning: Constant CIVICRM_UF already defined in /var/www/html/core/setup/src/Setup/UI/SetupController.php on line 130

Warning: Constant CIVICRM_UF_BASEURL already defined in /var/www/html/core/setup/src/Setup/UI/SetupController.php on line 132

Warning: http_response_code(): Cannot set response code - headers already sent (output started at /var/www/html/core/setup/src/Setup/UI/SetupController.php:130) in /var/www/html/core/setup/src/Setup/BasicRunner.php on line 31

I wasn't sure where /var/www/html/setting-stub should exist or not so I removed it but got the same message.

I also tried passing CIVICRM_DSN instead of, and as well as CIVICRM_DB_* variables but but got the same message.

Let me know if I am missing something or you want me to test again.

[ufundo]

CIVICRM_SETTINGS_PATH=/var/www/html/setting-stub

Sorry @michaelmcandrew that doesnt exist as an env var (yet)

For now I got it working by adding

define('CIVICRM_SETTINGS_PATH', '/var/www/html/setting-stub');

at the top of civicrm.standalone.php

[michaelmcandrew]

I can confirm that adding that line works for me :) I was able to log in successfully.

[ufundo]

retest this please

[colemanw]

I've marked this merge-on-pass based on user testing, and hit "retry" on the failing unit tests. @ufundo can you take a look at any test failures when the runs complete.

[ufundo]

Oh yes there's also an issue with settings style conformance:

Civi\Core\SettingsStyleTest::testConformance
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
+    0 => 'uf: In 5.53+, names should us...refix.'
+    1 => 'domain: In 5.53+, names shoul...refix.'
+    2 => 'userFrameworkBaseURL: In 5.53...refix.'
 )

If I "add" them using current versions, then it wants the metadata to have prefix. But the pre-existing constants don't obviously conform.

I think I could backdate the "add" to opt out of the conformance. Or I could make them fit the existing pattern, though it will be more deviation from the current names.

[colemanw]

@ufundo whatever's cleanest. Opting out seems reasonable.

[ufundo]

@colemanw something strange was going on with CIVICRM_UF and cv, so I've backed out of that one for now, and just stuck with CIVICRM_DOMAIN_ID and CIVICRM_UF_BASEURL.

Hope still ok to MOP with the reduced scope.

Step by step.