Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-01-04T22:21:56Zhttps://lab.civicrm.org/dev/core/-/issues/4884"CiviCRM News" on Backdrop has awkward accordions on default themes2024-01-04T22:21:56Ztotten"CiviCRM News" on Backdrop has awkward accordions on default themesOn Backdrop (eg https://bmaster.demo.civicrm.org/civicrm/ ; user: `demo`; pass: `demo`) with default themes, the "CiviCRM News" dashlet is looking weird:
![Screenshot_2024-01-03_at_9.08.21_PM](/uploads/8d22ff7703e5f9eaf856a9e413be66dd/...On Backdrop (eg https://bmaster.demo.civicrm.org/civicrm/ ; user: `demo`; pass: `demo`) with default themes, the "CiviCRM News" dashlet is looking weird:
![Screenshot_2024-01-03_at_9.08.21_PM](/uploads/8d22ff7703e5f9eaf856a9e413be66dd/Screenshot_2024-01-03_at_9.08.21_PM.png)
Theories:
* At first blush, it feels like it would be a regression related to the accordion updates circa 5.69.x (eg https://lab.civicrm.org/dev/user-interface/-/issues/60). However, there's a similar problem in 5.68. This suggests that it's not a simple regression:
![Screenshot_2024-01-03_at_10.21.14_PM](/uploads/ebe6ad88b770ba5337a965cc887d194b/Screenshot_2024-01-03_at_10.21.14_PM.png)
(Note: Slightly different visual appearance with double arrows)
* Could it be that there's always been a bug like this.
* Could it be that the accordion cleanup led to changes in the news feed? In which case, maybe the question is about infra: How to make the feed(s) work with different versions of Civi?
* Interestingly, I went to an old/local copy of `bcmaster`, updated to 5.68+5.69+master, and... it seemed to display fine. But on clean builds of 5.68 and master, it didn't. (This suggests that it might still be some kind of regression.)
* (*It could be that I have a cache of an older feed? This might support the idea of an issue in how the feed works with different client environments?*)5.69.0https://lab.civicrm.org/dev/backdrop/-/issues/8CiviCRM cron via HTTP on Backdrop isn't documented and doesn't work2023-11-18T18:28:38ZRobert J. LangCiviCRM cron via HTTP on Backdrop isn't documented and doesn't workThe problem is that running CiviCRM cron via HTTP is (a) undocumented, (b) doesn't work.
Documentation for CiviCRM cron is at https://docs.civicrm.org/sysadmin/en/latest/setup/jobs/#url-to-cronphp
There's no Backdrop instructions under...The problem is that running CiviCRM cron via HTTP is (a) undocumented, (b) doesn't work.
Documentation for CiviCRM cron is at https://docs.civicrm.org/sysadmin/en/latest/setup/jobs/#url-to-cronphp
There's no Backdrop instructions under "URL to cron.php". One might expect the URL to be the same as for Drupal 7, i.e.,
```
https://example.org/sites/all/modules/civicrm/bin/cron.php
```
but there are several problems with that.
First, `sites/all/modules` is not where CiviCRM is likely to be stored in a Backdrop installation. More likely, it would be `/modules/civicrm` or `modules/contrib/civicrm`.
That would make the URL one of these:
```
https://example.org/modules/civicrm/bin/cron.php
https://example.org/modules/contrib/civicrm/bin/cron.php
```
But even if you use the appropriate URL, Backdrop won't let you load that file, instead directing you to a 404 page. This is because the Backdrop .htaccess file has a rewrite condition that grabs any path ending in `cron.php`. See https://github.com/backdrop/backdrop-issues/issues/3903 for details and workarounds.
[UPDATE: Backdrop fixed the .htaccess issue in versions 1.21.5 and 1.22.0, released 2022-05-15.]
We can work around this without hacking .htaccess by making a copy of this file with a different name, e.g., `backdrop_cron.php`. But at that point, we run into the next problem: the function `civicrm_conf_init()` in file `civicrm.config.php` doesn't necessarily return the right directory for the file `civicrm.settings.php`, so the cron call fails.
Under Drupal 7, this file was commonly in `sites/all/defaults`, right next to D7's `settings.php`. So in Backdrop, where `settings.php` resides at site root, it's a logical choice to put `civicrm.settings.php` in the same directory, so also at site root. But `civicrm_conf_init()` can't handle this location.
We can fix that, too, by editing `civicrm.config.php` to add code to handle this option:
```
// check to see if civicrm is under modules/contrib or modules, and if so,
// see if settings file is at site root.
if (file_exists($currentDir . '..' . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . 'civicrm.settings.php')) {
return $currentDir . '..' . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . '..';
}
elseif (file_exists($currentDir . '..' . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . 'civicrm.settings.php')) {
return $currentDir . '..' . DIRECTORY_SEPARATOR . '..';
}
```
This returns the correct directory, and indeed, with this change, one can almost-successfully run CiviCRM cron from the URL:
```
http://example.org/modules/contrib/civicrm/bin/backdrop_cron.php?name=<user>&pass=<pass>&key=<site_key>
```
Except this generates a host of PHP warnings in watchdog like this:
```
Warning: Cannot modify header information - headers already sent by (output started at /mysite/core/includes/bootstrap.inc:745) in backdrop_send_headers() (line 1638 of /mysite/core/includes/bootstrap.inc).
```
Plus a bunch more notices and warnings (25 in total).
This happens during the call to `CRM_Utils_System::authenticateScript(TRUE)`, which bootstraps the Backdrop site.
Aside from the warnings, the cron job proceeds fully, and the cron run is reported as being run on the CiviCRM status page.
A hacky workaround would be to suppress the warnings just for this run via `error_reporting()`, but this isn't possible, because `bootstrap.inc` does its own call to `error_reporting()`. (And suppressing lots of warnings just to get rid of them is generally a bad thing to do.)
So at this point, running CiviCRM cron from HTTP isn't readily achieved.
A deeper look with a debugger narrows the problem to the CiviCRM function `CRM_Utils_System::authenticate()`, which contains just this:
```
public static function authenticate($name, $password, $loadCMSBootstrap = FALSE, $realPath = NULL) {
$config = CRM_Core_Config::singleton();
/* Before we do any loading, let's start the session and write to it.
* We typically call authenticate only when we need to bootstrap the CMS
* directly via Civi and hence bypass the normal CMS auth and bootstrap
* process typically done in CLI and cron scripts. See: CRM-12648
*
* Q: Can we move this to the userSystem class so that it can be tuned
* per-CMS? For example, when dealing with UnitTests UF, does it need to
* do this session write since the original issue was for Drupal.
*/
$session = CRM_Core_Session::singleton();
$session->set('civicrmInitSession', TRUE);
return $config->userSystem->authenticate($name, $password, $loadCMSBootstrap, $realPath);
}
```
The problem is that the call `$session->set()` starts the session via `CRM_Utils_System_Backdrop->setssionStart()`. But then the next call to `$config->userSystem->authenticate()` (which resolves to `CRM_UTILS_System_Backdrop->autheticate()`) ends up calling `backdrop_bootstrap()`, which will attempt to do a bunch of `ini_set()`s, resulting in the error since the session has already started.https://lab.civicrm.org/dev/backdrop/-/issues/79civicrm_backdrop.css hard-codes the location of the civicrm module2023-11-18T18:12:45ZRobert J. Langcivicrm_backdrop.css hard-codes the location of the civicrm moduleThe file `civicrm_backdrop.css` hard-codes the location of the CiviCRM module in this line:
```
#crm-container .ui-widget-header .ui-state-default {
background: #e6e6e6 url(/modules/civicrm/bower_components/jquery-ui/themes/smoothness...The file `civicrm_backdrop.css` hard-codes the location of the CiviCRM module in this line:
```
#crm-container .ui-widget-header .ui-state-default {
background: #e6e6e6 url(/modules/civicrm/bower_components/jquery-ui/themes/smoothness/images/ui-bg_glass_75_e6e6e6_1x400.png) 50% 50% repeat-x;
}
```
If the CiviCRM module is located anywhere else (for example, at `modules/contrib/civicrm`), this puts missing-file errors into the dblog whenever one visits the CiviCRM dashboard.
There is a global variable, `$civicrm_root`, which specifies the location of the module. That should be used. (Perhaps use `backdrop_add_css()` to dynamically add this bit?)https://lab.civicrm.org/dev/backdrop/-/issues/1Convert member and group to roles sync rules from database to config2023-02-27T16:56:29ZherbdoolConvert member and group to roles sync rules from database to configCurrently they're stored in the database but they smell a lot like configuration. Better to store them in the config json files and drop the database tables.Currently they're stored in the database but they smell a lot like configuration. Better to store them in the config json files and drop the database tables.herbdoolherbdoolhttps://lab.civicrm.org/dev/backdrop/-/issues/73Warning: in_array() expects parameter 2 to be array, null given in civicrm_us...2023-02-17T21:57:51ZRobert J. LangWarning: in_array() expects parameter 2 to be array, null given in civicrm_user_admin_permissions_submit()In the Backdrop version of CiviCRM, there is a check when the Backdrop permissions are edited to see if the anonymous user is getting dangerous permissions; the check is carried out by `civicrm_user_admin_permissions_submit()`.
This wor...In the Backdrop version of CiviCRM, there is a check when the Backdrop permissions are edited to see if the anonymous user is getting dangerous permissions; the check is carried out by `civicrm_user_admin_permissions_submit()`.
This works fine if one is editing the entire permissions matrix, but if one edits any other single permission (e.g., at path `admin/config/people/permissions/authenticated`), then submission stuffs watchdog with many warnings like this:
`Warning: in_array() expects parameter 2 to be array, null given in civicrm_user_admin_permissions_submit() (line 1041 of /mysite/modules/contrib/civicrm/backdrop/civicrm.module).`
The problem is that the code is expecting the form to contain the anonymous permissions, but it doesn't. If the form doesn't contain anonymous permissions, then this function should simply exit.
PR to follow.https://lab.civicrm.org/dev/backdrop/-/issues/10Warning: in_array() expects parameter 2 to be array, null given in civicrm_us...2023-01-05T23:39:33ZRobert J. LangWarning: in_array() expects parameter 2 to be array, null given in civicrm_user_admin_permissions_submit()Also posted in [the GitHub queue](https://github.com/civicrm/civicrm-backdrop/issues/160), where there is [a PR](https://github.com/civicrm/civicrm-backdrop/pull/161).
In the Backdrop version of CiviCRM, there is a check when the Backdr...Also posted in [the GitHub queue](https://github.com/civicrm/civicrm-backdrop/issues/160), where there is [a PR](https://github.com/civicrm/civicrm-backdrop/pull/161).
In the Backdrop version of CiviCRM, there is a check when the Backdrop permissions are edited to see if the anonymous user is getting dangerous permissions; the check is carried out by `civicrm_user_admin_permissions_submit()`.
This works fine if one is editing the entire permissions matrix, but if one edits any other single permission (e.g., at path `admin/config/people/permissions/authenticated`), then submission stuffs watchdog with many warnings like this:
`Warning: in_array() expects parameter 2 to be array, null given in civicrm_user_admin_permissions_submit() (line 1041 of /mysite/modules/contrib/civicrm/backdrop/civicrm.module).`
The problem is that the code is expecting the form to contain the anonymous permissions, but it doesn't. If the form doesn't contain anonymous permissions, then this function should simply exit.https://lab.civicrm.org/dev/backdrop/-/issues/11Add a Views Contextual Filter Plugin for "CiviCRM ID from logged in person"2022-10-11T20:49:58ZlarynAdd a Views Contextual Filter Plugin for "CiviCRM ID from logged in person"We have Views Plugins for the following:
- "User account ID from logged in person"
- "User account ID from URL"
- "CiviCRM ID from URL"
I propose to add this one as well:
- "CiviCRM ID from logged in person"We have Views Plugins for the following:
- "User account ID from logged in person"
- "User account ID from URL"
- "CiviCRM ID from URL"
I propose to add this one as well:
- "CiviCRM ID from logged in person"https://lab.civicrm.org/dev/backdrop/-/issues/6Clean up autoloader and views plugins2022-10-11T19:36:35ZlarynClean up autoloader and views pluginsI was seeing this while trying to edit an unrelated view (the exposed filter modal wouldn't open and this error was in the log):
> Warning: require_once(/app/modules/civicrm/backdrop/modules/views/civicrm/civicrm_plugin_argument_default...I was seeing this while trying to edit an unrelated view (the exposed filter modal wouldn't open and this error was in the log):
> Warning: require_once(/app/modules/civicrm/backdrop/modules/views/civicrm/civicrm_plugin_argument_default_civicrm_id.inc): failed to open stream: No such file or directory in require_once() (line 4054 of /app/core/includes/bootstrap.inc).
I looked in `backdrop/modules/views/civicrm` and it seems that perhaps one of the files is mis-named. I renamed `civicrm_plugin_argument_default.inc` to be `civicrm_plugin_argument_default_civicrm_id.inc` and then the exposed filter modal opened for me again. I haven't tested further beyond that, though.https://lab.civicrm.org/dev/backdrop/-/issues/7Feature request: Layout access conditions that consider query parameters2022-10-10T17:39:36ZlarynFeature request: Layout access conditions that consider query parametersTranscribing [from the Github queue](https://github.com/civicrm/civicrm-backdrop/issues/135) to perhaps get more visibility, this is from @bugfolder:
> [A recent forum post](https://forum.backdropcms.org/forum/how-configure-layout-civic...Transcribing [from the Github queue](https://github.com/civicrm/civicrm-backdrop/issues/135) to perhaps get more visibility, this is from @bugfolder:
> [A recent forum post](https://forum.backdropcms.org/forum/how-configure-layout-civicrm-pages) asked for a way to put a donation block on a single CiviCRM event page. This is an example of a broader need, of being able to customize specific CiviCRM pages with layouts and blocks. Elsewhere in Backdrop, we could use a URL path visibility condition for that, but since CiviCRM uses query parameters to distinguish pages and the URL path visibility condition doesn't consider query parameters part of the URL path, the URL path visibility condition won't work for that. So there is a need for a visibility condition that considers query parameters.
> PR to follow.
----
> Some further explanation (originally intended for a README file).
>
> CiviCRM handles URLs differently from the rest of Backdrop in two ways, which can be illustrated by a typical CiviCRM URL, for example, an event page:
>
> ```
> http://example.com/civicrm/event/info?id=1&reset=1
> ```
>
> 1. CiviCRM distinguishes between different pages by using _query parameters_, which are given by everything that comes after the `?` in this URL.
>
> 2. Backdrop paths typically include multiple words separated by `/`. While it looks like the Backdrop path for this URL would be `civicrm/event/info`, the _system path_ (used internally in Backdrop) for all CiviCRM pages is just `civicrm`.
>
>
> This behavior complicates the problem of creating layout and block visibility conditions for CiviCRM pages in Backdrop.
>
> When creating an alternative layout for a CiviCRM page, the layout must have the path `civicrm` (nothing more) to be considered for any CiviCRM page. But then it will be considered for _every_ CiviCRM page. You can limit it to particular classes of page by using visibility conditions on the layout (or limit its blocks by using visibility conditions on the blocks).https://lab.civicrm.org/dev/backdrop/-/issues/3"Actions > Create User Record" is not working correctly2022-08-18T14:33:52Zlaryn"Actions > Create User Record" is not working correctlyWhen trying to use the "Actions" button menu on a contact screen to "Create User Record", the form that is presented seems to create the user successfully, but then create a new/separate CiviCRM contact for that email address which is co...When trying to use the "Actions" button menu on a contact screen to "Create User Record", the form that is presented seems to create the user successfully, but then create a new/separate CiviCRM contact for that email address which is connected to the new Backdrop user. It then tries to link the new user to the contact that you are working on and clicked the button from, which causes a fatal error since that Backdrop user is already linked in the `uf_match` table. Once you get out of the fatal error screen, you are left with the additional empty contact (email address linked to Backdrop user) and the original contact which is still not linked to any user.
![Screen_Shot_2021-10-22_at_2.42.13_PM](/uploads/ca2edea00baae102c11c540fc1a2e3c2/Screen_Shot_2021-10-22_at_2.42.13_PM.jpg)
> Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
DB Error: already existshttps://lab.civicrm.org/dev/core/-/issues/2201PHP 8.0 Compatibility2021-12-09T16:32:47ZJoeMurrayPHP 8.0 CompatibilityPHP 8.0.0 is scheduled for release Nov 26, 2020.
Backward incompatible changes are listed at https://github.com/php/php-src/blob/php-8.0.0RC5/UPGRADING#L20 for 8.0.0RC5. As one would expect for a major version, it is a long list.
1. [...PHP 8.0.0 is scheduled for release Nov 26, 2020.
Backward incompatible changes are listed at https://github.com/php/php-src/blob/php-8.0.0RC5/UPGRADING#L20 for 8.0.0RC5. As one would expect for a major version, it is a long list.
1. [Create edge CI for PHP8](https://lab.civicrm.org/dev/core/-/issues/2200)https://lab.civicrm.org/dev/backdrop/-/issues/2Profile fields in Backdrop still say "Drupal"2021-10-21T20:23:12ZlarynProfile fields in Backdrop still say "Drupal"When adding/editing a profile, the checkbox options still say Drupal:
![profile-backdrop](/uploads/c0f5620f1b7c64cadaaf39273e038879/profile-backdrop.jpg)
@megaphonejon notes:
> I fixed this elsewhere - [civicrm/civicrm-core#14288](htt...When adding/editing a profile, the checkbox options still say Drupal:
![profile-backdrop](/uploads/c0f5620f1b7c64cadaaf39273e038879/profile-backdrop.jpg)
@megaphonejon notes:
> I fixed this elsewhere - [civicrm/civicrm-core#14288](https://github.com/civicrm/civicrm-core/pull/14288). Moreover, see @mlutfy's criticism, and my comments on [civicrm/civicrm-core#14286](https://github.com/civicrm/civicrm-core/pull/14286). The correct way to handle this would be to create a method on the `CRM_Utils_System_*` classes that returns the name - and ideally a second method for the "User Permissions" URL - so these can all be fixed in a reliable way.
I also noticed that it's done slightly differently in the database integration section, using the generic "CMS" instead of the specific name of the CMS. I'm not sure if we need to standardize these for consistency or not.
![database-backdrop](/uploads/81b42622d75fdf5c196333998da28e7f/database-backdrop.jpg)5.44.0https://lab.civicrm.org/dev/core/-/issues/2200Create edge CI for PHP82020-11-19T15:37:09ZJoeMurrayCreate edge CI for PHP8PHP 8.0.0 comes out Nov 26, 2020.
Create an appropriate set of edge test configurations for PHP8.
It appears that Drupal8 and Drupal 9.0 are not compatible with PHP 8, but that Drupal 9.1+ will be (https://www.drupal.org/node/3180764?u...PHP 8.0.0 comes out Nov 26, 2020.
Create an appropriate set of edge test configurations for PHP8.
It appears that Drupal8 and Drupal 9.0 are not compatible with PHP 8, but that Drupal 9.1+ will be (https://www.drupal.org/node/3180764?utm_source=drupal-newsletter&utm_medium=email&utm_campaign=drupal-newsletter-20201119).
WordPress 5.6 is likely to be compatible (https://make.wordpress.org/core/2020/10/06/call-for-testing-php-8-0/)
Joomla aims to be compatible with minor PHP versions on day of release or within a few weeks but not for a major upgrade.
I'm not familiar with BackDrop's PHP8's compatibility efforts.
So I would start with WordPress and Drupal9.bgmbgmhttps://lab.civicrm.org/dev/core/-/issues/1708Links in mails fail - extern/url.php fails to find configuration via civicrm....2020-10-19T23:34:09Zaydunsaidan.saunders@squiffle.ukLinks in mails fail - extern/url.php fails to find configuration via civicrm.config.phpOverview
----------------------------------------
Links in mails result in an error `Could not load the settings file at: ...`
CiviCRM 5.24.2 Backdrop 1.15.1
Reproduction steps
----------------------------------------
This depends on ...Overview
----------------------------------------
Links in mails result in an error `Could not load the settings file at: ...`
CiviCRM 5.24.2 Backdrop 1.15.1
Reproduction steps
----------------------------------------
This depends on the location of the civicrm module relative to the backdrop root directory. In a default install, the settings file is in `BACKDROP_ROOT` with civi in `BACKDROP_ROOT/modules/contrib/civicrm`
1. Create a mail containing a link
2. Send mail
3. Link should be https://example.org/modules/contrib/civicrm/extern/url.php - click it and browser gives above error
Analysis
----------------------------------------
`extern/url.php` requires `../civicrm.config.php` That has a comment saying "This function has been copied from BACKDROP_ROOT/core/includes/bootstrap.inc" but comparing to the referenced file shows the process to find the conf dir has been updated in Backdrop but not in our copy.
Options
-------
1) An easy fix is to change civicrm.config.php (via backdrop/civicrm.config.php.backdrop) and add another location check
2) More complex and still not great is to refresh the copied functions
3) There has been discussion about getting rid of extern (particularly around extern/ipn.php) - is there a plan for this?
I have a PR-able fix as per 1) but would be good to get an answer re 3)
Comments
--------
This was noted on a new install with current versions and defaults. Don't know whether this worked out of the box previously but does not look to be connected to any recent core changes.
Environment information
----------------------------------------
* __CiviCRM:__ _5.24.2_
* __PHP:__ _7.3_
* __CMS:__ _1.15.1_https://lab.civicrm.org/dev/core/-/issues/1170Fix getLoginURL() for Backdrop2019-08-08T03:16:12ZherbdoolFix getLoginURL() for BackdropBecause of https://github.com/backdrop/backdrop-issues/issues/260, any anonymous visits to `/user` will redirect to `/user/login`. Currently `CRM_Utils_System_Backdrop::getLoginURL()` creates a link to `/user?destination...` and this URL...Because of https://github.com/backdrop/backdrop-issues/issues/260, any anonymous visits to `/user` will redirect to `/user/login`. Currently `CRM_Utils_System_Backdrop::getLoginURL()` creates a link to `/user?destination...` and this URL will automatically try to redirect. And because of Backdrop/Drupal allowing the `?destination` parameter to override other redirects, it will automatically go to that destination instead of staying at `/user` or even `/user/login`
There's probably an easy fix by just changing getLoginURL to point to `/user/login` and no immediate redirect will happen.5.17.0