CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-06-11T16:35:32Zhttps://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/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/3524Does CiviCRM make it possible to specify which directories are private and wh...2022-06-11T14:42:36ZherbdoolDoes 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/9302db5820d0af0181edf9990fd47b90/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/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/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/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/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/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.https://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/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/3305Allow overriding membership status temporarily until specific date2022-04-22T16:16:26Zomar_compucorpAllow overriding membership status temporarily until specific date## Overview
Improving membership status override to provide extra options to allow temporary status override.
## Details
Instead of having a checkbox called (Override Status?) in membership add/edit/renew form, it will be replaced wi...## Overview
Improving membership status override to provide extra options to allow temporary status override.
## Details
Instead of having a checkbox called (Override Status?) in membership add/edit/renew form, it will be replaced with a select box that allow the user to choose one of three options :
1- No
2- Override Permanently
3- Override until selected date
- If the first option is selected, then the membership will behave as if the old (Override Status?) is **unchecked**, which means that the membership is subject to membership status rules.
- If the 2nd option is selected, then the membership will behave as if the old (Override Status?) is **checked**, which mean that the membership status is overridden and is not subject to the membership statues rules.
- If the 3rd option is selected, then a new field will appear allowing the user to choose a date, in this status, the membership will behave similar to option 2, but when today date is equal or less than the selected date, then the "Update Membership Statuses" scheduled job will automatically convert its status back to **No**, which means that the membership status is overridden temporarily only for the selected date and after that it will revert back and be subject to membership status rules
## Mocks
![Screen_Shot_2018-01-12_at_18.09.22__1_](/uploads/17bbabdc32947f63399d37e9af7652e6/Screen_Shot_2018-01-12_at_18.09.22__1_.png)
## Most notable Technical Details :
civicrm_memebership.is_override field is removed, and two alternative fields are added, once is called status_override_type (DEFAULT 0) , and the other is status_override_end_date (DEFAULT NULL).
status_override_type may contain 0 (means no override), 1 (means override Permanently) or 3 (means Override until selected date), where status_override_end_date will contain the override end date in case the status override type is 3 (override until selected date).https://lab.civicrm.org/dev/core/-/issues/1Allow to search for "in progress" contributions2024-03-01T16:29:50ZxavierAllow to search for "in progress" contributionsThe search is hiding the status "in progress". However, some payment processor do use this status (eg the sepa one), so it is in effect hiding contributions, and therefore makes the users very sad and confused
Fix:
allow to search on s...The search is hiding the status "in progress". However, some payment processor do use this status (eg the sepa one), so it is in effect hiding contributions, and therefore makes the users very sad and confused
Fix:
allow to search on status "in progress". Worse case scenario, no contributions have this status, and it will return an empty list4.7.31https://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/2Display Inbound Email: linefeed suppressed2024-03-26T10:22:28ZDetlev SieberDisplay Inbound Email: linefeed suppressedWhen viewing an activity of type inbound email, the text is displayed in "details". However, althought the database contains it in plain text and html, it is displayed as plain text without LFs, what makes it hardly readable.When viewing an activity of type inbound email, the text is displayed in "details". However, althought the database contains it in plain text and html, it is displayed as plain text without LFs, what makes it hardly readable.4.7.31https://lab.civicrm.org/dev/core/-/issues/3Upgrade Symfony dependency to 3.x2024-02-09T08:47:50ZbgmUpgrade Symfony dependency to 3.xThe Ubuntu/Debian community have raised the issue that the 2.x version of Symfony used by CiviCRM is quickly going to be outdated. `nacc` on IRC recommended moving to 3.x.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883640
cc @ja...The Ubuntu/Debian community have raised the issue that the 2.x version of Symfony used by CiviCRM is quickly going to be outdated. `nacc` on IRC recommended moving to 3.x.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883640
cc @jackrabbithanna @totten
IRC log:
```
2018-02-12 13:11 < nacc> Apologies for what might be considered offtopic; I work on Ubuntu
Server, and am responsible for our current migration to PHP7.2 (from PHP7.1). One of
the fallouts was a move to Symfony 3.4.3, which in turns breaks CiviCRM which is incompatible
with 3.0 per composer.json. Is this a hard (and not likely to change) dependency, and should
we therefor remove civicrm from Ubuntu?
2018-02-12 13:16 < nacc> [...] our feature freeze is March 1. I will note as well that civicrm
is uninstallable in Debian for the same reason (the Debian pacakge, that is):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883640
```
@jackrabbithanna mentioned on Mattermost:
> Actually CiviCRM Core is behind Drupal 8, so upgrading it would be super
> D8 either is or will be using Symfony 3.2.8 (was/is 3.2.6)
> https://www.drupal.org/node/2743809
> https://www.drupal.org/node/2891254
> anyway, 8.4 definitely is Symfony 3.2https://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/3293Make menu more accessible2022-04-22T16:04:20ZJoeMurrayMake menu more accessiblePreliminary tasks, many from https://lab.civicrm.org/dev/accessibility/issues/1#note_4855 below:
1. [x] Hide D7 menubar
1. [x] Fix for D8
1. [x] After getting focus into top menu, tabbing and back-tabbing revealed there was something hid...Preliminary tasks, many from https://lab.civicrm.org/dev/accessibility/issues/1#note_4855 below:
1. [x] Hide D7 menubar
1. [x] Fix for D8
1. [x] After getting focus into top menu, tabbing and back-tabbing revealed there was something hidden between Quick Search textbox and the CiviCRM icon. Opening submenus and back-tabbing revealed it was the search options for the Quick Search textbox. Please remove this from tab order.
1. [x] After getting focus into top menu, Space did not open (and when repeated, close) child menu on current item. It should act similarly to Return.
1. [x] When focus is on an item that could be selected to navigate somewhere, Return worked fine but Space did not replicate this.
1. [x] When on an open sub-submenu (eg Contributions > Accounting Batches with Open Batches with focus), using left arrow correctly moved focus to Accounting Batches, but it did not close the sub-submenu.
1. [x] When on a submenu, using left arrow should close the submenu and move focus to parent item. Instead it moved focus to menu item to left of parent item. The submenu was left open when it should have been closed.
~~1. [ ] When on a sub-submenu, escape should only close that level of menu but closes both the sub-submenu and the submenu.~~
1. [ ] "First item in menu bar should be in the tab order (tabindex=0)." (https://staff.washington.edu/tft/tests/menus/index.html). This may be a bit of work to implement in all CMSes but I think tabindex=0 for CiviCRM menu makes sense as the default on CiviCRM pages on default CMS installs. The CiviCRM Menu left item should be considered the QuickSearch. There appears to be an item for a div around the textarea and a separate way to focus on the textarea itself. The div around the textarea should be tabindex=0.
1. [ ] The cited spec is relatively silent, but other accessible menus have different implementations on the following: 1) When focus is on top menu item and its submenu is open, left and right cycle focus to left and right top menu items and shift which submenu is open to the one under the top menu focussed item. 2a) When focus is on a submenu item left closes the submenu, cycles focus to left on top menu and opens that top menu's submenu. 2b) When focus is on a submenu item without a subsubmenu, right similarly closes submenu, cycles focus right on top menu and opens that top menu item's submenu. 2c) When focus is on a submenu item with a subsubmenu, right opens the subsubmenu. Let's change behaviour 1), 2a) and 2b) to not opening new submenu. Leave 2c) as is.
~~1. [ ] When focus is not on the menu, cursor hovering over a menu item brings focus to it and opens submenu. Submenu should not open until click, return or space.~~
A user should be able to navigate the menu bar by use of the keyboard:
1. [ ] The menu bar should occupy one tab stop
1. [ ] When focused on a menu at the top level:
1. [ ] The right arrow key should move the user to the next top-level menu
1. [ ] The left arrow key should move the user to the previous top level menu
1. [ ] User focus should wrap to the beginning if the user advances past the final menu item. Likewise, if the user tries to navigate to the previous item from the first menu, focus should wrap to the last menu.
1. [ ] The down-arrow and ENTER keys should expand a child menu and focus the user on the first item
~~1. [ ] When a character is typed, the next menu item starting with that letter receives the focus, circling around to first when there are no more. If no menu item starts with the typed character, focus does not move. (deprecated by HTML 5.2 accesskey standard)~~
1. [ ] When focused on a child menu
1. [ ] The down arrow key should move the user to the next menu item
1. [ ] The up arrow key should move the user to the previous menu item
1. [ ] The right arrow key should expand a menu item with a submenu and place user focus on the first item in that submenu. If there is no submenu, then no action is taken.
1. [ ] The left arrow key should collapse a submenu and place user focus on the parent of that submenu
1. [ ] The ESC key should close the active child menu, and any submenus, and return user focus to the parent menu at the top level.
~~1. [ ] When a character is typed, the next child menu item starting with that letter receives the focus, circling around to first when there are no more. If no child menu item starts with the typed character, focus does not move. (deprecated by HTML 5.2 accesskey standard)~~
Test the menu works on default installs (ie default theme!) on
1. [x] Drupal 7
1. [x] WordPress
1. [x] Joomla
1. [x] Backdrop
1. [x] Drupal 8
(NB: deliberately ignoring support for Drupal 6.)
Test the menu works on:
1. [x] Drupal 7 site with shoreditch theme installed
1. [x] Drupal 7 site with mosaico installed, on a CiviMail mosaico page.
A more detailed functional spec is provided at http://lists.w3.org/Archives/Public/wai-xtech/2007Dec/att-0025/index.html#menu
A good implementation that might be useful for its implementation details (seeing View Source) is https://staff.washington.edu/tft/tests/menus/simplyaccessible/index.html. As there are no sub-submenus, I imagine the code implementation needs to be extended to opening sub-submenus properly.
Was https://issues.civicrm.org/jira/browse/CRM-20824
Original description from https://civicrm.stackexchange.com/questions/17735/access-for-blind-users-to-civicrm/17752#17752
The menu bar is keyboard accessible, but awkwardly. Generally I find it best to focus on the first item then TAB (as opposed to arrowing) to the top level menu the user wants to interact with before pressing ENTER to activate the pop-up menu. You will then have to locate the HTML list element containing the menu choices. Often this element appears after the menu bar, or at the bottom of the virtual document (sometimes depending on the CMS theme, sometimes depending on, seemingly, the browser’s mood). In either case, it will not appear immediately “under” the activated menu.https://lab.civicrm.org/dev/core/-/issues/3294Make accordion panels accessible2024-03-15T20:39:55ZJoeMurrayMake accordion panels accessibleFrom https://civicrm.stackexchange.com/questions/17735/access-for-blind-users-to-civicrm/17752#17752
Accordion panels in the contact record cannot be expanded with the keyboard. In general, panels containing certain contact data (demogr...From https://civicrm.stackexchange.com/questions/17735/access-for-blind-users-to-civicrm/17752#17752
Accordion panels in the contact record cannot be expanded with the keyboard. In general, panels containing certain contact data (demographic information, address, etc.) are collapsed by default. It is necessary to use the mouse (JAWS) cursor in order to expand these panels.
A user should be able to expand an collapse an accordion panel by using the keyboard only and not be required to use the mouse. To accomplish this, elements of crm-acordion-header should be made keyboard focusable and be configured to provide feedback to the screen reader on whether they are collapsed or expanded. At the simplest level, these elements could be made buttons instead of divs and be given the aria-expanded attribute which would be dynamically toggled depending on the panel’s state. This will allow a keyboard user to focus the panel header with the tab key and expand or collapse it with ENTER or SPACE. More in-depth examples of accordion accessibility can be found at OAA Accessibility http://www.oaa-accessibility.org/examplep/accordian1/, and Basic Accessible Accordion Panel for jQuery http://www.jqueryscript.net/accordion/Basic-Accessible-Accordion-Plugin-jQuery.html.
Technical spec to come.
Was https://issues.civicrm.org/jira/browse/CRM-208255.73.0https://lab.civicrm.org/dev/core/-/issues/3296Add aria-label (and label?) to form elements missing them2022-04-22T16:04:46ZJoeMurrayAdd aria-label (and label?) to form elements missing themUse accessible labels for all pages/forms following spec at https://www.w3.org/WAI/tutorials/forms/labels.
Tasks will include the following general points. Some details will change to ensure that ts() is handled properly, addField() is...Use accessible labels for all pages/forms following spec at https://www.w3.org/WAI/tutorials/forms/labels.
Tasks will include the following general points. Some details will change to ensure that ts() is handled properly, addField() is used appropriately, etc from comments below:
1. Label without control elements/text: In some pages/forms we are simply declaring labels under `<label>` tag against an element/text.
1. Remove tag when it is declared against a text as in
```
- <div class="label"><label>{ts}Contact{/ts}</label></div>
+ <div class="label">{ts}Contact{/ts}</div>
```
1. Add `aria-labelledby` attribute to tag
```
- <label>{ts}Contact{/ts}</label><input type="text" name="contact_id" id="contact_id">
+ <label aria-labelledby="contact_id">{ts}Contact{/ts}</label><input type="text" name="contact_id" id="contact_id">
```
1. Add aria-label attribute to QuickForm element when label is not declared in tpl: Say for example we are assigning a label to a QuickForm element
`$form->addElement('text', 'pledge_installments', ts('Installments'), array('size' => 3));` but not using it in tpl.
**Fix**: Add aria-label attribute to QuickForm element:
```
- $form->addElement('text', 'pledge_installments', ts('Installments'), array('size' => 3));
+ $form->addElement('text', 'pledge_installments', ts('Installments'), array('size' => 3, 'aria-label' => ts('Pledge Installments')));
```
1. Add aria-label attribute to form element via JS: A special case when after declaring this attribute didn't got added to the QuickForm element as in case of 'Credit card Expiration date' when this element got rendered in the quickform as `$form->add('date', 'credit_card_exp_date', ts('Expiration Date'), ['format' => M Y'])` and thus rendered into two select field without this attribute
**Fix**: Add `aria-label` attribute via JS instead. This might involve modifying $.fn.crmDatepicker in Common.js to add aria-labels to the autogenerated date elements it inserts.
1. Fix date fields.
Focus initially on public facing pages/forms:
1. [x] contribution page
1. [x] event registration page
1. [x] price field block
1. [x] newsletter signup
1. [x] user registration in CMS
1. [x] profile create/edit/search
1. [x] contact dashboard
1. [x] contact summary page
1. [ ] CiviReports
1. [ ] Search Forms
1. [ ] Backend registration forms
https://lab.civicrm.org/dev/core/-/issues/3299Make alerts accessible2022-04-22T16:04:58ZJoeMurrayMake alerts accessibleFrom Clare comes a problem statement and some brainstorming ideas:
> A problem for our low vision users is alerts, their AT software doesn't recognise them, so they miss warnings and end up adding duplicates. It would be great to have s...From Clare comes a problem statement and some brainstorming ideas:
> A problem for our low vision users is alerts, their AT software doesn't recognise them, so they miss warnings and end up adding duplicates. It would be great to have some sort of per user control for setting how alerts display, perhaps even adding audio cues.
Use alert role approach suggested at https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/examples/alert/index.html as this will allow audio cues to be given to users of screen readers.
Note more details at https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/#alert and also https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/#alertdialog
https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-no-exceptions.html indicates that there should be no time limits like quickly disappearing alerts.
As a first pass, let's implement a site wide setting to disable alerts from disappearing. We don't have a good design pattern currently for per user preferences. When we do move to per user preferences, the default should be to have alerts not disappear.justinfreeman (Agileware)justinfreeman (Agileware)