cloud-native issueshttps://lab.civicrm.org/dev/cloud-native/-/issues2022-06-11T16:02:23Zhttps://lab.civicrm.org/dev/cloud-native/-/issues/16[Meta] Does CiviCRM have a single defined application HTTP entry point which ...2022-06-11T16:02:23Zxurizaemon[Meta] Does CiviCRM have a single defined application HTTP entry point which routes all requests?Various issues arise when we have multiple entry points to the application (eg scripts in `extern/`, direct call scripts like KCFinder `integration/civicrm.php`, IPN handlers).
These issues stem from duplicated / non-identical approache...Various issues arise when we have multiple entry points to the application (eg scripts in `extern/`, direct call scripts like KCFinder `integration/civicrm.php`, IPN handlers).
These issues stem from duplicated / non-identical approaches to bootstrapping / path discovery / session management.
The end goal here is to eliminate alternate entry points and ensure any callback uses CiviCRM's core routing.
As much as possible auth/bootstrap/url/path resolution should be handled in one place only (each) for maintainability.
## Background issues / examples:
* [CRM-17212](https://issues.civicrm.org/jira/browse/CRM-17212)
* [CRM-13249](https://issues.civicrm.org/jira/browse/CRM-13249)
* [CRM-12246](https://issues.civicrm.org/jira/browse/CRM-12246)
* #6
* #7
## Targets
* [`extern/authorizeIPN.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/authorizeIPN.php), [`ipn.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/ipn.php), [`pxIPN.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/pxIPN.php) - IPN handlers → use `civicrm/ipn/%` entry point
* [`extern/cxn.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/cxn.php)
* [`extern/open.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/open.php) - endpoint to track mail opens via image URL
* [`extern/rest.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/rest.php) - API endpoint → `civicrm/api/v3`, `civicrm/api/v4` etc
* [`extern/soap.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/soap.php) - SOAP interface, still used by CiviSMTP? → `civicrm/soap`
* [`extern/url.php`](https://github.com/civicrm/civicrm-core/blob/master/extern/url.php) - Mailing redirect → `civicrm/redirect` ?
* [`packages/kcfinder/integration/civicrm.php`](https://github.com/civicrm/civicrm-packages/blob/master/kcfinder/integration/civicrm.php) - KCFinder integration for CiviCRM - IDK
IPN handlers should be tackled as those core payment processors are moved to extensions.
https://lab.civicrm.org/dev/cloud-native/-/issues/8Move example data to an optional/add-on step2022-06-11T16:02:18ZtottenMove example data to an optional/add-on stepDuring installation, the installer shows a checkbox which asks whether you want to load sample data. Then:
* If you don't want sample data, it loads `sql/civicrm_data.mysql`.
* If you do want sample data, it loads `sql/civicrm_generat...During installation, the installer shows a checkbox which asks whether you want to load sample data. Then:
* If you don't want sample data, it loads `sql/civicrm_data.mysql`.
* If you do want sample data, it loads `sql/civicrm_generated.mysql`.
This has some consequences:
* You must choose whether to load sample data during *installation*. This is presented in the installer UI.
* The `civicrm_generated.mysql` takes extra work to maintain (eg `bin/regen.sh`; the output of which is not merge-friendly).
The goal here would be to have one *installation* process -- which could be headless. *Afterwards*, you should have the *option* to enable create the sample data. This *option* may be specified as at same time as other install parameters (eg via arg) or perhaps via a separate command afterwards.https://lab.civicrm.org/dev/cloud-native/-/issues/12Determine CiviCRM host and port in Docker-friendly way - via an environment v...2022-06-11T16:02:16ZMichael McAndrewDetermine CiviCRM host and port in Docker-friendly way - via an environment variablehttps://lab.civicrm.org/dev/cloud-native/-/issues/7Rewrite the standalone bootstrap protocol. Deprecate civicrm.settings.php.2022-06-11T16:01:17ZtottenRewrite the standalone bootstrap protocol. Deprecate civicrm.settings.php.## tldr
Rewrite `Bootstrap.php` to support CMS-first -- and make `civicrm.settings.php` unnecessary.
## Background: Problem
CiviCRM has many entry-points -- specific examples would be `bin/cli.php`, `extern/open.php`, `extern/url.php`...## tldr
Rewrite `Bootstrap.php` to support CMS-first -- and make `civicrm.settings.php` unnecessary.
## Background: Problem
CiviCRM has many entry-points -- specific examples would be `bin/cli.php`, `extern/open.php`, `extern/url.php`, `extern/rest.php`, or `extern/cxn.php`. More broadly, *all test suites and CLI processes* use a standalone bootstrap script. (These entry-points are distinct from the front-end entry-points typically associated with the UI.)
There are a number of technical details and happenstance we can go into, but there are two fundamental nubs in writing and executing a standalone script:
* *It doesn't know which CMS is active.* There's usually some *hard-coding* to the find the CMS.
* *Bootstrapping the CMS adds overhead.* Many admins have written-off this consideration as cost of doing business - but for someone, somewhere, at some point it mattered.
## Background: `civicrm.config.php` protocol
The original protocol for standalone bootstrap originated many years ago (circa 1.x or 2.x?). It's still used in several cases. It's key design elements:
* `civicrm.config.php` is *generated* at build-time to match the CMS. The tarball/zipball for each CMS includes a different build of this file. It's main purpose is to locate `civicrm.settings.php`.
* `civicrm.settings.php` includes a `define` for the `CIVICRM_UF` (among many others).
* `CRM_Utils_System::*` includes functions like `loadBootStrap()`.
* __Original protocol__: A standalone script would include `civicrm.config.php`, which would locate the `civicrm.settings.php` using a CMS-specific search. It then boots Civi by loading `civicrm.settings.php` and calling `CRM_Core_Config::singleton()`. Optionally, it also boots the CMS by calling `CRM_Utils_System_*::loadBootStrap()`.
The original boot protocol has some major consequences -- for example:
1. It requires creating an extra settings file (`civicrm.settings.php`) on every build.
2. Depending on how the page-load starts, the Civi settings file and CMS settings may load in different orders. It's not valid to infer Civi settings based on CMS settings (and vice-versa).
3. You need to figure the *absolute or relative* path of `civicrm.config.php`. This is *possible* in `civicrm-core` -- but it's basically impossible with any other publishable deliverable.
4. Reading/understanding the boot protocol requires having multiple builds of Civi (one for each CMS) -- *that's the only way to see each version of `civicrm.config.php`.
## Background: `cv` bootstrap protocol
A few years ago, I combined the various `civicrm.config.php` files with the aim of producing a universal boot script that solved `#3` and `#4`. This produced https://github.com/civicrm/cv/blob/master/src/Bootstrap.php which eventually became the heart of the `cv` command. This endeavor preserved a bunch of assumptions from the original protocol... but it made a key change: *dynamically discovering* the boot info.
The dynamic discovery works a bit like this:
* Do a file-system search (from PWD) to figure out the CMS.
* Do a file-system search (from CMS dir) to figure out where `civicrm.settings.php` is.
* Unless... you really want a faster bootstrap. Then you can set an environment variable with your boot info (and bypass the searches).
IMHO, dynamic CMS discovery (with optional env-var for optimization) is a pretty good way to make the code more robust to deploying in a variety of environments and file-structures.
There's just one problem: the *implementation* grew out of `civicrm.config.php` and kept some of the assumptions, so the implementation still shares issues `#1` and `#2`.
## Proposal: Provide a universal, CMS-first bootstrap script -- and knock over some dominoes
The basic idea is to write a CLI helper which bootstraps the CMS first -- and then bootstraps Civi. The logic is roughly:
```php
function boot($startDir) {
$parentDirectories = array($startDir, parent($startDir), grandparent($startDir), ...);
foreach ($parentDirectories as $dir)
if ($dir has Drupal) { bootDrupal(); bootCivi(); return; }
elseif ($dir has Joomla) { bootJoomla(); bootCivi(); return; }
elseif ($dir has WordPress) { bootWordPress(); bootCivi(); return; }
elseif ($dir has Backdrop) { bootBackdrop(); bootCivi(); return; }
}
}
```
This helper still provides standalone bootstrap, so we can still have all our standalone scripts/unit-tests/commands/etc. But it makes a fundamental change:
* **You can always rely on having the CMS bootstrapped first**.
* Therefore, you can detect things like `CIVICRM_BASEURL` using CMS API's -- because they're always available.
* Therefore, you don't need `civicrm.settings.php` to store those settings.
* Therefore, you don't need `install/index.php` to create `civicrm.settings.php`.
* Therefore, you don't need write-access to create `civicrm.settings.php` (in the typical case).
* Therefore, you don't need to migrate or preserve `civicrm.settings.php` (in the typical case).
*Note: Of course, the entire CiviCRM install-base currently uses `civicrm.settings.php`, and some of them use it to accomplish special ends (like custom multidomain/multisite/multitenant arrangements). Therefore, I wouldn't argue for complete removal of the file -- but, instead, it should be an optional/advanced thing.*
## General Tasks
* Write the new bootstrap script.
* Phase-in the new bootstrap script for use by `cv` and `civicrm-core`.
* Update `civicrm-core` to compute values for all those constants (`define('CIVICRM_FOO',...)`) at runtime using CMS functions.
* Update the installer to omit `civicrm.settings.php`
* Update docs to describe the advanced/optional use of `civicrm.settings.php`.https://lab.civicrm.org/dev/cloud-native/-/issues/2Does CiviCRM allow us to declare which directories are writable, allowing the...2022-06-11T14:46:36ZherbdoolDoes CiviCRM allow us to declare which directories are writable, allowing the rest to be locked-down?CiviCRM core seems to be consistent in only writing to a files directory. Until recently, however, it attempted to write to the extensions directory to store extension updates. It's unclear if CiviCRM enforces this for extensions. I've h...CiviCRM core seems to be consistent in only writing to a files directory. Until recently, however, it attempted to write to the extensions directory to store extension updates. It's unclear if CiviCRM enforces this for extensions. I've heard that some extensions will write to directories outside of the files (but I haven't been able to confirm this). If that's the case then it will conflict with PAAS that only allow certain directories to be writable.https://lab.civicrm.org/dev/cloud-native/-/issues/13When communcating with external network services, detect transient failures a...2022-06-11T14:45:12ZmfbWhen communcating with external network services, detect transient failures and queue for retryFor improved resiliency, CiviCRM should detect transient failures when communicating with external network services and queue for retry. e.g.
* Transactional email: Queue for sending rather than sending during the request process?
* Bul...For improved resiliency, CiviCRM should detect transient failures when communicating with external network services and queue for retry. e.g.
* Transactional email: Queue for sending rather than sending during the request process?
* Bulk mail: Catch transient failures and ensure that they are retried. PRs: https://github.com/civicrm/civicrm-core/pull/11838 https://github.com/civicrm/civicrm-core/pull/11840 (and there are additional failure scenarios possible)
* ...https://lab.civicrm.org/dev/cloud-native/-/issues/11Docker2022-06-11T14:45:11ZMichael McAndrewDockerHey there,
I've been doing a bit of work on [CiviCRM on Docker](https://github.com/michaelmcandrew/civicrm-buildkit-docker/). I know that others have been doing the same and I feel like it would be great to start co-ordinating a bit mor...Hey there,
I've been doing a bit of work on [CiviCRM on Docker](https://github.com/michaelmcandrew/civicrm-buildkit-docker/). I know that others have been doing the same and I feel like it would be great to start co-ordinating a bit more.
I am wondering whether cloud native is the right place for it, or if we should create a Docker project.
On the one hand, I feel like there could be a lot of Docker chat and wouldn't want to drown out other chat. On the other, I don't want to proliferate groups unnecessarily.
Any thoughts? I am erring toward a seperate group at the minute.https://lab.civicrm.org/dev/cloud-native/-/issues/10Does CiviCRM handle UNIX filesystem functionality like symlinks?2022-06-11T14:45:09ZxurizaemonDoes CiviCRM handle UNIX filesystem functionality like symlinks?Some cloud hosting providers dynamically assign storage (disk) and may use symlinks to associate dynamic storage with predictable filesystem locations. CiviCRM seems to be confused by the presence of symlinks in the CiviCRM install path ...Some cloud hosting providers dynamically assign storage (disk) and may use symlinks to associate dynamic storage with predictable filesystem locations. CiviCRM seems to be confused by the presence of symlinks in the CiviCRM install path (and possibly resource paths).
This manifests as "weird" resource URLs or inability to resolve filesystem paths.
> This doesn't work in all configurations. For example, if your directory structure uses symlinks, it may not resolve correctly.
For examples, https://civicrm.stackexchange.com/search?q=symlink eg
* https://civicrm.stackexchange.com/questions/19495/set-civicrm-files/19498#19498
* https://civicrm.stackexchange.com/questions/20064/help-needed-in-setting-up-rest-api-in-civi-crm/20076#20076
* https://civicrm.stackexchange.com/questions/20265/mailchimp-plugin-creating-webhook-with-invalid-url
* https://civicrm.stackexchange.com/questions/21925/incorrect-resource-url-warning-but-menu-arrows-are-present
For WP specifically, https://github.com/civicrm/civicrm-core/pull/11086https://lab.civicrm.org/dev/cloud-native/-/issues/4[META] Does CiviCRM make it easy for all connection-related configuration to ...2022-06-11T14:45:05Zherbdool[META] Does CiviCRM make it easy for all connection-related configuration to be provided via environment variables: database credentials, key-value database credentials, filesystem, and so on?It is possible by editing civicrm.settings.php to inject the environment variables.
I'm wondering if a more generic framework might be useful where CiviCRM provides some boilerplate for what strings are required from the environment va...It is possible by editing civicrm.settings.php to inject the environment variables.
I'm wondering if a more generic framework might be useful where CiviCRM provides some boilerplate for what strings are required from the environment variables.
This could help since there is so much repetition of variables that need to be assigned.
----
Issues towards this goal:
* https://lab.civicrm.org/dev/cloud-native/issues/12
* https://lab.civicrm.org/dev/cloud-native/issues/7
* https://lab.civicrm.org/dev/cloud-native/issues/8https://lab.civicrm.org/dev/cloud-native/-/issues/1Simplify the settings for filesystem paths2022-06-11T14:44:59ZxurizaemonSimplify the settings for filesystem paths* [Hosting environments like WPEngine don't permit (extra) .php files located in the webroot (apparently)](https://civicrm.stackexchange.com/questions/15942/is-it-possible-in-civicrm-to-change-extension-of-cached-php-files-from-php-to-s)...* [Hosting environments like WPEngine don't permit (extra) .php files located in the webroot (apparently)](https://civicrm.stackexchange.com/questions/15942/is-it-possible-in-civicrm-to-change-extension-of-cached-php-files-from-php-to-s)
* Caching generated content there means potential for info leakage or execution via input variables
* Filesystem caching can be inefficient compared to other caches
* Herb has done work to get Smarty caching via Redis?
* https://www.drupal.org/node/2570335
* https://forum.civicrm.org/index.php?topic=35125.0;nowap
* https://issues.civicrm.org/jira/browse/CRM-17401
* https://github.com/freeform/civicrm-drupal-pantheon/blob/4.6.x/patches/smarty-redis-civi-cache.patch
* would Smarty 2 choke if we just set the path to redis:// ?
* .php extension is [tacked on here](https://github.com/civicrm/civicrm-packages/blob/master/Smarty/Smarty.class.php#L1512), may be other places to change thishttps://lab.civicrm.org/dev/cloud-native/-/issues/5[META] Does CiviCRM make it easy to install without using the UI?2022-06-11T14:44:16Zherbdool[META] Does CiviCRM make it easy to install without using the UI?Currently CiviCRM can be installed via the commandline with drush ~~or cv~~, but it doesn't allow for environmental variables in the command (from what I can tell). I'm not sure if that's the best way to automate a build anyway. To allow...Currently CiviCRM can be installed via the commandline with drush ~~or cv~~, but it doesn't allow for environmental variables in the command (from what I can tell). I'm not sure if that's the best way to automate a build anyway. To allow for builds we may need to be able to point CiviCRM to a file with the env vars and then install fresh. And may need to override the default behaviour of CiviCRM showing errors when it finds a civicrm.settings.php already.
---
Issues towards this goal:
* https://lab.civicrm.org/dev/cloud-native/issues/7
* https://lab.civicrm.org/dev/cloud-native/issues/8https://lab.civicrm.org/dev/cloud-native/-/issues/9Does CiviCRM work well with database replication and clustering?2022-06-11T14:44:13ZdavejDoes CiviCRM work well with database replication and clustering?There have been a few discussions on Mattermost in recent months in which people have described problems running Civi in replicated / cluster environments. In particular, Civi's use of temporary tables has caused issues. E.g.
10 Oct 20...There have been a few discussions on Mattermost in recent months in which people have described problems running Civi in replicated / cluster environments. In particular, Civi's use of temporary tables has caused issues. E.g.
10 Oct 2017 eileen:
> We have been having some replication lag issues & one metric we are investigating is the slaves (only) seem to show a large number of open temp tables on one metric. The odd thing about the replication lag is it seems to get worse the longer since a server restart (presumably just the mysql part needs to be restarted).
10 Oct 2017 jackrabbithanna:
> Ok we're dealing with Percona DB
>
> Database Error Code: Statement violates GTID consistency: CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed outside transactional context. These statements are also not allowed in a function or trigger because functions and triggers are also considered to be multi-statement transactions., 1787
>
> followed by a php error: Fatal error: Uncaught CRM_Core_Exception: [0: Transaction integrity error: Expected to find active frame thrown
>
> Per https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-restrictions.html the multi-statements transactions are not allowed as they could potentially run using the same global transaction ID (GTID)
>
> this error happens when trying to create a Drupal user, with CiviCRM profile on the form
Further comments from Eileen:
> OK - I'll have a read of that - the CiviCRM usage of temp tables is pretty common & in particular ties in with the way mailing recipients are calculated & rolled back. However, I'm also reading concerns that replicated DBs don't like temp tables (although it's not blocked in the version we have)
>
> (we use mixed mode replication)
>
> I think it's kind of a big picture question isn't it? I had thought to move all temp table creations to a single function (so if we want to do something different we can do it in there) - the thing is a lot of them are used to calculate group_contact_cache & those will cause rollback to fail
> "A recommended practice when using statement-based or mixed-format replication is to designate a prefix for exclusive use in naming temporary tables that you do not want replicated, then employ a --replicate-wild-ignore-table option to match that prefix. For example, you might give all such tables names beginning with norep (such as norepmytable, norepyourtable, and so on), then use --replicate-wild-ignore-table=norep% to prevent them from being replicated." - we could at least do that for reports etc
> if you are using statement based replication or mixed replication then any temp tables used to build real tables have to be replicated
>
> or else the query will fail on the slave
> it's an improvement basically 'make civicrm support replication'
> it does work with replication but I think that's more because various people have just configured it to do so
>
> but I don't think there has ever been any official support for that or effort to understand the design implications
13 Oct eileen:
> ... our replication issue DOES seem to be related to the temp tables created for civimail at this stage. ... What we are seeing is the DROP statement is written to the binlog BEFORE the create statement is - somewhat in line with https://www.xaprb.com/blog/2007/01/20/how-to-make-mysql-replication-reliable/
>
> (not really clear from there but it says "As I mentioned, each transaction goes into the binlog in the order in which it commits, not in the order in which it is started, so transactions may execute in a different order on the replica. ")
>
> the binlog is parsed on the slaves & they temp tables mount up
>
> not 100% sure if this will solve all our woes - but not letting civicrm use temp tables to create recipient lists seems to be important
We ran a bunch of Civi sites with MySQL replication several years ago and had a lot of problems with it: replication would fall over periodically and then everything would grind to a near standstill as it was re-sync'd.
As a starting point, it would be useful to gather some data on how many people use replication / clustering with Civi, how frequently problems are encountered, what the most common problems are and whether they have been solved.https://lab.civicrm.org/dev/cloud-native/-/issues/20Logging improvements2022-06-11T14:42:49ZmfbLogging improvementsI ran into some issues re: CiviCRM logging:
1. Currently, in many cases, CiviCRM does not indicate a severity level when logging a message. Thus many events are logged at info level.
1. When passing log messages thru to Drupal's watchdo...I ran into some issues re: CiviCRM logging:
1. Currently, in many cases, CiviCRM does not indicate a severity level when logging a message. Thus many events are logged at info level.
1. When passing log messages thru to Drupal's watchdog() logger, debug level is typically used, even for a fatal error. There is no attempt made to map the level appropriately.
1. Some of the CRM_Core_Error methods - e.g. CRM_Core_Error::debug_var() - don't have an argument for severity level - but we could/should add one.
1. When providing a severity level to "old school" CRM_Core_Error calls, we also have the option of "upgrading" these to instead be Civi::log() calls.
I would be curious to hear anyone's thoughts, but it seems fairly straightforward to make some big improvements here.https://lab.civicrm.org/dev/cloud-native/-/issues/3Does CiviCRM make it possible to specify which directories are private and wh...2022-06-11T14:42:42ZherbdoolDoes CiviCRM make it possible to specify which directories are private and which are public-accessible?This is currently not possible in CiviCRM. A PAAS like Pantheon provides a specific folder for private file uploads and we can't change it to any other folder. However, CiviCRM assumes that the site is either running on Apache (and it ca...This is currently not possible in CiviCRM. A PAAS like Pantheon provides a specific folder for private file uploads and we can't change it to any other folder. However, CiviCRM assumes that the site is either running on Apache (and it can use .htaccess files) or that custom NGINX rules can be set. This is an unreasonable expectation.
CiviCRM requires some filepaths to be private and will complain if they're not configured properly: https://civicrm.org/advisory/civi-sa-2014-001-risk-information-disclosure
CiviCRM has hardcoded the filepaths of some things based on the path of CIVICRM_TEMPLATE_COMPILEDIR. The problem is that CIVICRM_TEMPLATE_COMPILEDIR needs to be private but many of the files that CiviCRM is trying to write based on that path need to be publicly available (e.g. dynamically written JS).
An audit of both baseFilePath() and CIVICRM_TEMPLATE_COMPILEDIR:
[audit-template_compiledir.txt](/uploads/39d0d65db8943aff2d79d581fe2cc221/audit-template_compiledir.txt).
Tim provided some technical guidance in another thread https://lab.civicrm.org/dev/cloud-native/issues/1#note_3124:
> - The references to `baseFilePath()` in `CRM_Utils_System_*` should become irrelevant if `civicrm.settings.php` has the `$civicrm_paths['civicrm.files']`
>
> - The references to `baseFilePath()` in `CRM_Utils_File::absoluteDirectory` and `::relativeDirectory` already appear to be irrelevant within `civicrm-core`. (The only usage I could find was one which explicitly set its own base.)
>
> - The reference to `baseFilePath()` in `CRM_Core_Config_Runtime` is more effort. I don't know if it'd work, but my first try would be (a) lookup a path-variable like `Civi::paths()->getVariable('civicrm.log', 'path')`, (b) declare the variable in `Civi\Core\Paths`, (c) change the relative boot order of `Civi\Core\Paths` and `CRM_Core_Config_Runtime`.
>
> - I think `CRM/Utils/Cache/SerializeCache.php` is unused.
>
> - The `CRM/Core/IDS.php` line feels silly. We should pick one folder! Pointing that at `templates_c` makes as much sense as `uploadDir`. (TBH, I'm not sure does anything now that `Config.IDS.ini` has been killed.)
>
> - `Civi/Core/Container.php` and `CRM/Extension/ClassLoader.php` are very similar to the Smarty use-case (i.e. writing out ephemeral PHP files to take advantage of opcode caching).https://lab.civicrm.org/dev/cloud-native/-/issues/21Don't cache the full path of extensions so they don't break with dynamic paths2022-06-11T14:41:18ZherbdoolDon't cache the full path of extensions so they don't break with dynamic pathsExtension paths are cached as full paths, which are incompatible with cloud services that might have dynamic filepaths (such as Pantheon). Instead the full path can be determined by other means.
This is an example of what gets cached in...Extension paths are cached as full paths, which are incompatible with cloud services that might have dynamic filepaths (such as Pantheon). Instead the full path can be determined by other means.
This is an example of what gets cached in CRM_Extension_Mapper::getActiveModuleFiles:
```
a:6:{i:0;a:2:{s:6:"prefix";s:4:"iats";s:8:"filePath";s:101:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/com.iatspayments.civicrm/iats.php";}i:1;a:2:{s:6:"prefix";s:14:"extendedreport";s:8:"filePath";s:114:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/nz.co.fuzion.extendedreport/extendedreport.php";}i:2;a:2:{s:6:"prefix";s:12:"cividiscount";s:8:"filePath";s:116:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/org.civicrm.module.cividiscount/cividiscount.php";}i:3;a:2:{s:6:"prefix";s:9:"sumfields";s:8:"filePath";s:108:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/net.ourpowerbase.sumfields/sumfields.php";}i:4;a:2:{s:6:"prefix";s:4:"gdpr";s:8:"filePath";s:102:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/uk.co.vedaconsulting.gdpr/gdpr.php";}i:5;a:2:{s:6:"prefix";s:10:"l10nupdate";s:8:"filePath";s:107:"/var/www/vhosts/httpdocs/sites/all/civicrm_custom/extensions/com.cividesk.l10n.update/l10nupdate.php";}}
```
Previous solution was to use the patch in this issue https://www.drupal.org/node/2347897 but it meant there was a performance hit by always skipping cache.5.24.0https://lab.civicrm.org/dev/cloud-native/-/issues/18Soften messages for read-only extensionsDir2022-06-11T14:41:11ZtiotsopSoften messages for read-only extensionsDirImprove messaging when someone has a different policy for managing `extensionsDir`.This a continuation of this [PR](https://github.com/civicrm/civicrm-core/pull/11895). Most of the messaging update has already been done. There is only on...Improve messaging when someone has a different policy for managing `extensionsDir`.This a continuation of this [PR](https://github.com/civicrm/civicrm-core/pull/11895). Most of the messaging update has already been done. There is only one message ("Read-Only Extensions"). It still encourages web-writable policy, but it lowers the severity and presents it a choice ("if you want X, do Y").
Probably, changing the `warning` into a `notice` is the only thing to update:- a `warning` implies something is wrong, while a `notice` says it's merely out of the ordinary.5.9tiotsoptiotsophttps://lab.civicrm.org/dev/cloud-native/-/issues/19Maintain "official" containerized version(s) of CiviCRM2022-06-11T14:41:05ZmfbMaintain "official" containerized version(s) of CiviCRMCiviCRM could maintain container images for development and/or production use.
This could be useful for CI purposes (e.g. if CiviCRM is eventually doing CI via GitLab), and provide a baseline for shops, developers and implementers who n...CiviCRM could maintain container images for development and/or production use.
This could be useful for CI purposes (e.g. if CiviCRM is eventually doing CI via GitLab), and provide a baseline for shops, developers and implementers who need to deploy/develop/test CiviCRM.