xml/GenCode.php - Fix execution in default locale (without l10n data) #16583
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This fixes a recent regression in which
xml/GenCode.php
fails to execute in certain configurations.Initial report: civicrm/civicrm-buildkit#503
This most likely stems from https://lab.civicrm.org/dev/translation/issues/30 aka #15408 which was first merged into 5.23.
Before
l10n
exists in its traditional location, and if you run./bin/setup.sh -g
, then it correctly executes.l10n
does not exist in its traditional location, and if you run./bin/setup.sh -g
, then it fails with an error like this:After
You can run
./bin/setup.sh -g
with or without thel10n
folder.When running
GenCode
, the CMS URL is set to a fake valuehttp://gencode.example.com/do-not-use
.Comments
There's an argument to be made that this shouldn't be necessary: when running
GenCode
, it should only create PHP files, and none of the output should depend on the CMS URL - because that's liable to change when you deploy the PHP code. If someone did try to generate URL at such an early stage, it's arguably good to generate an error. In point of fact,GenCode
is not actually using the CMS URL.The oddity stems from the contract of
CRM_Utils_System_*
(specifically,getCiviSourceStorage()
andgetDefaultFileStorage()
) which do double-duty providing both path and URL. To avoid duplicate work,Civi\Core\Paths
uses the same grain of information - it tracks the pairs of path+URL. And because it works at the same grain, we get into logic like:civicrm.root
path, then you need to also get thecivicrm.root
URL.civicrm.root
URL, then you need to get thecms.root
URL.A more aggressive fix might be to split
getCiviSourceStorage()
andgetDefaultFileStorage()
so that it's possible to get the path and URL separately; then reviseCivi\Core\Paths
to take advantage of the finer-grained contract. However, splitting those things would be a more invasive patch, and we're currently in RC.