Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-06-11T14:50:31Zhttps://lab.civicrm.org/dev/core/-/issues/3544Bounce processing doesn't catch pattern "user doesn't exist"2022-06-11T14:50:31ZDetlev SieberBounce processing doesn't catch pattern "user doesn't exist"CiviCRM bounce processing analyzes the bounce text patterns, and decides what kind of bounce type it is. This is a fragile process, but there seems to be no better solution, since there is no general standardization of bounce patterns.
...CiviCRM bounce processing analyzes the bounce text patterns, and decides what kind of bounce type it is. This is a fragile process, but there seems to be no better solution, since there is no general standardization of bounce patterns.
Some email providers throw the bounce pattern "user doesn't exist", which is not found, and therefore results in bounce_type "syntax". However, this bounce pattern should result in immediately switching the email address to "inactive".
Solution is:
> insert into civicrm_mailing_bounce_pattern (bounce_type_id, pattern) values (6, 'user doesn\'t exist');
5.9Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3543Provide warning for mailings that are being edited to prevent Mailing not sav...2024-02-12T05:03:28ZlarsssandergreenProvide warning for mailings that are being edited to prevent Mailing not saved errors.In our org, we have multiple users who might need to edit the same mailing. Unfortunately, this creates the possibility that someone leaves the mailing open and someone else opens it and begins editing, leading to the "Mailing not saved....In our org, we have multiple users who might need to edit the same mailing. Unfortunately, this creates the possibility that someone leaves the mailing open and someone else opens it and begins editing, leading to the "Mailing not saved. Content may be out of date" error (and tears and hair loss due to lost changes). In our case, this is mostly one user putting together a mailing and another user editing it, fixing formatting errors, etc. It's very hard to train users who are used to Google Docs not to leave the tab open, leading to the need for rigid hand off procedures. We've been trying to get people trained for years, but this continues to be an issue that we waste a lot of time on.
Would it be feasible to add some kind of warning that would warn another user who wants to open another mailing that is already open for editing? I'm thinking just setting a flag on the mailing with a 30 minute expiration, which is updated every time the mailing or content is saved. The flag would be unset when the user exits the mailing. Mailings with the flag would have a warning on the draft mailings screen that would say "Someone else may be editing this mailing" or a warning before opening the mailing. This won't be a perfect solution, but I think it would prevent 95% of problems.
We're using Mosaico, but I think this would be implemented in core and apply to both kinds of mailings.https://lab.civicrm.org/dev/core/-/issues/3542Move the cache for `CRM_Extension_Browser` out of the filesystem and use a `S...2022-06-16T02:21:42ZtiotsopMove the cache for `CRM_Extension_Browser` out of the filesystem and use a `SqlGroup` insteadThe current code in `CRM_Extension_Browser` is coded specifically for an adhoc, file-based caching logic. The recommendation standard is basically to change the backing/storage from a JSON file to the civicrm_cachetable (at least, for th...The current code in `CRM_Extension_Browser` is coded specifically for an adhoc, file-based caching logic. The recommendation standard is basically to change the backing/storage from a JSON file to the civicrm_cachetable (at least, for the typical usage).
Ref [#2](https://lab.civicrm.org/dev/cloud-native/issues/2#note_4790)5.52.0tiotsoptiotsophttps://lab.civicrm.org/dev/core/-/issues/3541[Meta] Does CiviCRM have a single defined application HTTP entry point which ...2024-02-11T05:03: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)
* cloud-native#6
* cloud-native#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/core/-/issues/3540Hardcoded filesystem paths in JS strings in cache2022-06-11T14:45:13ZherbdoolHardcoded filesystem paths in JS strings in cacheI've noticed hardcoded filesystem paths in civicrm_cache where group_name = js_strings. With dynamic containers on a host this could mean that the JS can't be found if it switches containers. Is there a way to make this relative?I've noticed hardcoded filesystem paths in civicrm_cache where group_name = js_strings. With dynamic containers on a host this could mean that the JS can't be found if it switches containers. Is there a way to make this relative?https://lab.civicrm.org/dev/core/-/issues/3539When communcating with external network services, detect transient failures a...2024-02-12T13:57:20ZmfbWhen 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/core/-/issues/3538Docker2022-06-11T14:45:10ZMichael 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/core/-/issues/3537Does CiviCRM handle UNIX filesystem functionality like symlinks?2024-02-10T05:03:27ZxurizaemonDoes 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/core/-/issues/3536[META] Does CiviCRM make it easy for all connection-related configuration to ...2024-02-10T05:03:26Zherbdool[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/core/-/issues/3535Does CiviCRM allow us to declare which directories are writable, allowing the...2022-06-11T14:45:00ZherbdoolDoes 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/core/-/issues/3534Simplify the settings for filesystem paths2022-06-11T16:35:32ZxurizaemonSimplify 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/core/-/issues/3533Rewrite the standalone bootstrap protocol. Deprecate civicrm.settings.php.2024-02-09T05:03:20ZtottenRewrite 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/core/-/issues/3532Determine CiviCRM host and port in Docker-friendly way - via an environment v...2024-02-25T05:03:20ZMichael McAndrewDetermine CiviCRM host and port in Docker-friendly way - via an environment variablehttps://lab.civicrm.org/dev/core/-/issues/3531Time zones should be in sync even if database server is set to different time...2024-02-09T05:03:19ZherbdoolTime zones should be in sync even if database server is set to different time zone from server with application (PHP)According to https://docs.civicrm.org/installation/en/latest/general/requirements/#mysql-time:
> PHP and MySQL may be running on different servers, and the clocks may be out-of-sync. Configuring automatic clock synchronization is the be...According to https://docs.civicrm.org/installation/en/latest/general/requirements/#mysql-time:
> PHP and MySQL may be running on different servers, and the clocks may be out-of-sync. Configuring automatic clock synchronization is the best solution.
It's not clear how necessary it is for CiviCRM to rely on the database server's time zone. This causes issues on Pantheon since there is no guarantee the database server is in the same location as the app server. The database server is set to use UTC. One can override it with `SET @@global.time_zone = '-04:00'` or whatever, but this is only temporary. Pantheon migrates databases between servers as upgrades are rolled out. The new server has the default settings. So we can't rely on setting that and Pantheon is currently not planning to allow changes to that configuration in a file.
In core (per CMS integration) the database time zone is set each database session. Such as with `CRM_Core_Config::singleton()->userSystem->setMySQLTimeZone();` in civicrm.module. But this doesn't help in the case with Pantheon. (I'm not entirely sure why).
But it's not really clear why it needs to be done this way. Could CiviCRM instead take the same approach as Drupal/Backdrop by saving all dates as UTC and then convert them to the CMS' timezone for display? Isn't that more robust?https://lab.civicrm.org/dev/core/-/issues/3530[META] Does CiviCRM make it easy to install without using the UI?2024-02-08T05:03:21Zherbdool[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/core/-/issues/3529Does 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/core/-/issues/3528[META] Does CiviCRM make it easy to provide the absolute system path at runti...2024-02-08T05:03:20Zherbdool[META] Does CiviCRM make it easy to provide the absolute system path at runtime from the environment rather than hardcoded in a file?In CiviCRM 4.7 this seems to be mostly solved but issues keep cropping up now and then. The environment variables can be specified in the settings file. In CiviCRM 4.7.25 it finally got rid of the hardcoded absolute path in Config.IDS.in...In CiviCRM 4.7 this seems to be mostly solved but issues keep cropping up now and then. The environment variables can be specified in the settings file. In CiviCRM 4.7.25 it finally got rid of the hardcoded absolute path in Config.IDS.ini. Most recently I've noticed some hardcoded paths in civicrm_cache where group_name = js_strings. It's unclear if the cache is regenerated if the paths cannot be found. Even better would be to avoid saving the full path.
----
Issues towards this goal:
* https://lab.civicrm.org/dev/cloud-native/issues/12
* https://lab.civicrm.org/dev/cloud-native/issues/14
* https://lab.civicrm.org/dev/cloud-native/issues/15
* https://lab.civicrm.org/dev/cloud-native/issues/16https://lab.civicrm.org/dev/core/-/issues/3527Logging improvements2024-02-07T05:03:28ZmfbLogging 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/core/-/issues/3526Extensions Mapper caches full path which breaks with dynamic containers2022-06-11T14:42:45ZherbdoolExtensions Mapper caches full path which breaks with dynamic containersCRM_Extension_Mapper caches the full path to extensions which with dynamic containers (such as with Pantheon) means that the cached path might not match the active container's path. This causes a fatal error.
The only solution seems to ...CRM_Extension_Mapper caches the full path to extensions which with dynamic containers (such as with Pantheon) means that the cached path might not match the active container's path. This causes a fatal error.
The only solution seems to be to force CRM_Extension_Mapper to fetch the extensions paths from the database, or prevent it from caching the full path. Currently with the CiviCRM Starterkit we are forcing it to fetch the list from the database each time (https://www.drupal.org/node/2347897).
Relates to https://lab.civicrm.org/dev/cloud-native/issues/6https://lab.civicrm.org/dev/core/-/issues/3525Move example data to an optional/add-on step2024-02-07T05:03:27ZtottenMove 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.