Drupal issueshttps://lab.civicrm.org/dev/drupal/-/issues2020-11-04T20:41:28Zhttps://lab.civicrm.org/dev/drupal/-/issues/105Drupal 8 routes don't rebuild automatically2020-11-04T20:41:28ZjohnkDrupal 8 routes don't rebuild automaticallyI use CiviCRM 5.21.1 with Drupal 8.8. Oftentimes, after I upgrade an extension, I have to run this command:
`drush ev '\Drupal::service("router.builder")->rebuild();'`
My questions are: does this occur automatically for upgrades to Civ...I use CiviCRM 5.21.1 with Drupal 8.8. Oftentimes, after I upgrade an extension, I have to run this command:
`drush ev '\Drupal::service("router.builder")->rebuild();'`
My questions are: does this occur automatically for upgrades to CiviCRM itself? It seems like maybe it does. I think, in that case, it should be automatic for extension upgrades, as well.
At the very least this command needs to be documented somewhere. I did a Google search, and all I found was some of my old bug reports!https://lab.civicrm.org/dev/drupal/-/issues/98CiviCRM session instance not working when Masquerading in Drupal 72021-09-01T21:02:42ZMichael McAndrewCiviCRM session instance not working when Masquerading in Drupal 7Have just upgraded to D7-5.20.1 and noticed that CRM_Core_Session::singleton() does not work when masquerading.
Setting a breakpoint in a Drupal page while masquerading and running `Civi::log()->debug(var_export(CRM_Core_Session::single...Have just upgraded to D7-5.20.1 and noticed that CRM_Core_Session::singleton() does not work when masquerading.
Setting a breakpoint in a Drupal page while masquerading and running `Civi::log()->debug(var_export(CRM_Core_Session::singleton(),true))`
Results in the following in the log:
```
Dec 11 13:08:57 [debug] CRM_Core_Session::__set_state(array(
'_key' => 'CiviCRM',
'_session' =>
array (
'masquerading' => '76',
),
))
```5.23.0https://lab.civicrm.org/dev/drupal/-/issues/91Drupal8: Buggy behavior if user account is created without email address2020-08-07T03:28:13ZJonGoldDrupal8: Buggy behavior if user account is created without email addressIn Drupal 8, the email address isn't a required field. However, if an email address isn't specified, then the `civicrm_uf_match` record isn't created, the corresponding CiviCRM contact isn't created, and this leads to some very buggy be...In Drupal 8, the email address isn't a required field. However, if an email address isn't specified, then the `civicrm_uf_match` record isn't created, the corresponding CiviCRM contact isn't created, and this leads to some very buggy behavior, such as the dashboard showing multiple dashboards (see https://lab.civicrm.org/dev/drupal/issues/54#note_23706), which I imagine is because `civicrm_dashboard_contact` is being queried by contact ID, and finding none, simply loads all dashlets for all users.
I think the correct way to handle this is to use a Drupal hook to make the email address required.5.29.0https://lab.civicrm.org/dev/drupal/-/issues/89Drupal8 - Contact Report does not load any values in the ACL Group/Role field2020-01-15T05:06:39ZjitendraDrupal8 - Contact Report does not load any values in the ACL Group/Role fieldNo values are loaded in Access Tab -> ACL Group/Role field in any contact reports eg `Constituent Summary `
![image](/uploads/476933860e82a4ab629031222dc9d925/image.png)No values are loaded in Access Tab -> ACL Group/Role field in any contact reports eg `Constituent Summary `
![image](/uploads/476933860e82a4ab629031222dc9d925/image.png)5.23.0jitendrajitendrahttps://lab.civicrm.org/dev/drupal/-/issues/88CRM/Utils/System/Drupal8.php autoload.php path issue 5.16.32020-04-22T14:54:19ZndavisCRM/Utils/System/Drupal8.php autoload.php path issue 5.16.3line 419.
Relies on cmsRootPath
Standard drupal installation cms path (cmsRoot) is now [drupal root]/web.
Drupal8.php now looks for autoload as **[cms.root]//autoload.php** (line 419)
Unless you symlink autoload.php from ../vendor/au...line 419.
Relies on cmsRootPath
Standard drupal installation cms path (cmsRoot) is now [drupal root]/web.
Drupal8.php now looks for autoload as **[cms.root]//autoload.php** (line 419)
Unless you symlink autoload.php from ../vendor/autoload.php this fails to find autoload.php.
Suggest an if block that first tries `require_once "autoload.php";` and if that fails (vendor directory is not in php's include_path) *then* look for it in a better place than cmsRoot. As well [cms.root] has a trailing slash so the forward slash in the `$autoloader = require_once $root."/autoload.php"` is unnecessary.
vendor is not supposed to be accessible in the web root, so for anyone who's vendor directory is not the web root, and is in a directory one directory level up (out of web root) Drupal8.php won't find autoload.php.
I'm not sure of the Drupal8.php's history, but changes related to the path to autoload.php between 5.15.1 and 5.16.3 and broke things.
If you change the [cms.root] so Drupal8.php can find autoload.php the rest of civi breaks. If I set this path properly in Drupal8.php everything works.https://lab.civicrm.org/dev/drupal/-/issues/87civicrm/civicrm-drupal-8 repository tags2019-09-17T23:26:00Zndaviscivicrm/civicrm-drupal-8 repository tagsusing drupal module commit 1f33241 results in drush and drupal becoming inoperable when run in drupal 8.7.6/drush 9.7.1.
rolling back to commit 41c855b8bdf15cef9b5578622e53d90b4510b317 fixes issues.
Are there plans to start tagging re...using drupal module commit 1f33241 results in drush and drupal becoming inoperable when run in drupal 8.7.6/drush 9.7.1.
rolling back to commit 41c855b8bdf15cef9b5578622e53d90b4510b317 fixes issues.
Are there plans to start tagging releases of the drupal module? (please o please o PRETTY PLEASE :-)https://lab.civicrm.org/dev/drupal/-/issues/86Group Role sync not mapping users but duplicating users2019-09-13T07:05:05ZacaselliGroup Role sync not mapping users but duplicating usersHi,
The group role sync module doesn't seem to work properly anymore. When I create a new user and I log in for the first time, instead of mapping the Drupal user id with the civicrm user id, the module maps the drupal user id to a new ...Hi,
The group role sync module doesn't seem to work properly anymore. When I create a new user and I log in for the first time, instead of mapping the Drupal user id with the civicrm user id, the module maps the drupal user id to a new user that has everything blank apart from the email.
I checked in the database, and in the table uf_match to confirm and here is (I think) what the module does.
When a user logs in, the checking of the existing user doesn't work anymore, so a new user is created with only the email field and that new user civicrm id is mapped with the drupal id in the uf_match table.
This is causing a lot of problems in our website. I updated to the latest version, 5.17.3 but that didn't fix it either. I noticed this error since version 5.11https://lab.civicrm.org/dev/drupal/-/issues/85Drupal8: Enabling language breaks a fresh CiviCRM install2020-01-26T17:07:09ZRar9Drupal8: Enabling language breaks a fresh CiviCRM installInstalled a fresh D8+civicrm via composer.
composer create-project roundearth/drupal-civicrm-project:8.x-dev MyDomain --no-interaction
setup d8
chmod +w web/sites/default
drush en -y civicrm
Change the "Resource URL" to `[cms.root]/lib...Installed a fresh D8+civicrm via composer.
composer create-project roundearth/drupal-civicrm-project:8.x-dev MyDomain --no-interaction
setup d8
chmod +w web/sites/default
drush en -y civicrm
Change the "Resource URL" to `[cms.root]/libraries/civicrm`
As icons still were not 100% I added to civicrm.settings.php the hard coded ResourceURLs
```php
if (!defined('CIVICRM_UF_BASEURL')) {
define( 'CIVICRM_UF_BASEURL' , 'https://MyDomain');
$civicrm_setting['URL Preferences']['userFrameworkResourceURL'] = '[cms.root]/libraries/civicrm';
$civicrm_paths['civicrm.root']['url'] = CIVICRM_UF_BASEURL . '/libraries/civicrm/';
$civicrm_setting['domain']['userFrameworkResourceURL'] = '[cms.root]/libraries/civicrm';
$civicrm_paths['cms.root']['path'] = '/var/www/vhosts/MyDomain/web';
}
```
Now cleared cache and CiviCRM runs :-)
But when I enable D8 language under extensions the CiviCRM site breaks! :-(
[Screenshot_1](/uploads/b0edfe413622185916d319889f178cd8/Screenshot_1.jpg)
Disabling Drupal language again, will bring back CiviCRM.5.23.0https://lab.civicrm.org/dev/drupal/-/issues/84Drupal7: use label instead of name in membership views2023-11-09T23:27:57ZwdecraeneDrupal7: use label instead of name in membership viewsIn `drupal/modules/views/components/civicrm.member.inc` add two times 'pseudo args' so (translated) labels are used instead of machine names.
```php
//Membership Status
$data['civicrm_membership']['status'] = array(
'title' => t...In `drupal/modules/views/components/civicrm.member.inc` add two times 'pseudo args' so (translated) labels are used instead of machine names.
```php
//Membership Status
$data['civicrm_membership']['status'] = array(
'title' => t('Status'),
'real field' => 'status_id',
'help' => t('The Status of the Membership'),
'field' => array(
'handler' => 'civicrm_handler_field_pseudo_constant',
'click sortable' => TRUE,
'pseudo class' => 'CRM_Member_PseudoConstant',
'pseudo method' => 'membershipStatus',
'pseudo args' => array(NULL, NULL, 'label'),
),
'argument' => array(
'handler' => 'views_handler_argument',
),
'filter' => array(
'handler' => 'civicrm_handler_filter_pseudo_constant',
'allow empty' => TRUE,
'pseudo class' => 'CRM_Member_PseudoConstant',
'pseudo method' => 'membershipStatus',
'pseudo args' => array(NULL, NULL, 'label'),
),
'sort' => array(
'handler' => 'views_handler_sort',
),
);
```https://lab.civicrm.org/dev/drupal/-/issues/81Drupal8: Large export results in logout2019-11-03T16:19:27ZJonGoldDrupal8: Large export results in logoutWhen you attempt a large export of CiviCRM data (~63K contacts, ~15 columns), Symfony kills the session. This is relatively recent behavior (didn't happen in April, for instance). Here are the watchdog logs:
Here are those stack traces,...When you attempt a large export of CiviCRM data (~63K contacts, ~15 columns), Symfony kills the session. This is relatively recent behavior (didn't happen in April, for instance). Here are the watchdog logs:
Here are those stack traces, more readable:
```
Warning: session_start(): Failed to decode session object. Session has been destroyed in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 149 of /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php)
#0 /var/www/crm.agbu.org/web/core/includes/bootstrap.inc(587): _drupal_error_handler_real(2, 'session_start()...', '/var/www/crm.ag...', 149, Array)
#1 [internal function]: _drupal_error_handler(2, 'session_start()...', '/var/www/crm.ag...', 149, Array)
#2 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php(149): session_start()
#3 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(164): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
#4 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(118): Drupal\Core\Session\SessionManager->startNow()
#5 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Session.php(57): Drupal\Core\Session\SessionManager->start()
#6 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpFoundation\Session\Session->start()
#7 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /var/www/crm.agbu.org/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /var/www/crm.agbu.org/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#15 {main}.
```
```
RuntimeException: Failed to start the session in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 150 of /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php)
#0 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(164): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
#1 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(118): Drupal\Core\Session\SessionManager->startNow()
#2 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Session.php(57): Drupal\Core\Session\SessionManager->start()
#3 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpFoundation\Session\Session->start()
#4 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#5 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#6 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#7 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /var/www/crm.agbu.org/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /var/www/crm.agbu.org/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#12 {main}.
```
The first issue is a warning that the session is too large, and so it destroys the session (which causes a logout). The second issue is of "error" severity saying the session can't be found.
Here's someone else having a similar issue in Symfony (not Drupal8): https://github.com/symfony/symfony/issues/26623tottentottenhttps://lab.civicrm.org/dev/drupal/-/issues/80Installing civicrm via drush errors when loading generated data2020-01-14T21:18:49ZherbdoolInstalling civicrm via drush errors when loading generated dataThis was reported here for Backdrop https://github.com/civicrm/civicrm-backdrop/issues/86 and the D7 file is virtually the same. So I suspect the same problem applies. The testing and PR were done by [tabroughton](https://github.com/tabr...This was reported here for Backdrop https://github.com/civicrm/civicrm-backdrop/issues/86 and the D7 file is virtually the same. So I suspect the same problem applies. The testing and PR were done by [tabroughton](https://github.com/tabroughton).
---
When using drush to install civicrm drush civicrm-insall and using the flag --load_generated_data the command errors with sql errors.
Example here:
```
Cannot execute INSERT INTO `civicrm_acl` (`id`, `name`, `deny`, `entity_table`, `entity_id`, `operation`, `object_table`, `object_id`, `acl_table`, `acl_id`, `is_active`) VALUES (1,'Edit All Contacts',0,'civicrm_acl_role',1,'Edit','civicrm_saved_search',0,NULL,NULL,1),(2,'Core ACL',0,'civicrm_acl_role',0,'All','access CiviMail subscribe/unsubscribe pages',NULL,NULL,NULL,1),(3,'Core ACL',0,'civicrm_acl_role',0,'All','access all custom data',NULL,NULL,NULL,1),(4,'Core ACL',0,'civicrm_acl_role',0,'All','make online contributions',NULL,NULL,NULL,1),(5,'Core ACL',0,'civicrm_acl_role',0,'All','make online pledges',NULL,NULL,NULL,1),(6,'Core ACL',0,'civicrm_acl_role',0,'All','profile listings and forms',NULL,NULL,NULL,1),(7,'Core ACL',0,'civicrm_acl_role',0,'All','view event info',NULL,NULL,NULL,1),(8,'Core ACL',0,'civicrm_acl_role',0,'All','register for events',NULL,NULL,NULL,1),(9,'Core ACL',0,'civicrm_acl_role',1,'All','access CiviCRM',NULL,NULL,NULL,1),(10,'Core ACL',0,'civicrm_acl_role',1,'All','access CiviContribute',NULL,NULL,NULL,1),(11,'Core ACL',0,'civicrm_acl_role',1,'All','access CiviEvent',NULL,NULL,NULL,1),(12,'Core ACL',0,'civicrm_acl_role',1,'All','access CiviMail',NULL,NULL,NULL,1),(13,'Core ACL',0,'civicrm_acl_role',1,'All','access CiviMail subscribe/unsubscribe pages',NULL,NULL,NULL,1),(14,'Core ACL',0,'civicrm_acl_role',1,'All','access CiviMember',NULL,NULL,NULL,1),(15,'Core ACL',0,'civicrm_acl_role',1,'All','access CiviPledge',NULL,NULL,NULL,1),(16,'Core ACL',0,'civicrm_acl_role',1,'All','administer CiviCase',NULL,NULL,NULL,1),(17,'Core ACL',0,'civicrm_acl_role',1,'All','access my cases and activities',NULL,NULL,NULL,1),(18,'Core ACL',0,'civicrm_acl_role',1,'All','access all cases and activities',NULL,NULL,NULL,1),(19,'Core ACL',0,'civicrm_acl_role',1,'All','delete in CiviCase',NULL,NULL,NULL,1),(20,'Core ACL',0,'civicrm_acl_role',1,'All','access CiviGrant',NULL,NULL,NULL,1),(21,'Core ACL',0,'civicrm_acl_role',1,'All','access Contact Dashboard',NULL,NULL,NULL,1),(22,'Core ACL',0,'civicrm_acl_role',1,'All','administer Multiple Organizations',NULL,NULL,NULL,1),(23,'Core ACL',0,'civicrm_acl_role',1,'All','delete activities',NULL,NULL,NULL,1),(24,'Core ACL',0,'civicrm_acl_role',1,'All','delete in CiviContribute',NULL,NULL,NULL,1),(25,'Core ACL',0,'civicrm_acl_role',1,'All','delete in CiviMail',NULL,NULL,NULL,1),(26,'Core ACL',0,'civicrm_acl_role',1,'All','delete in CiviPledge',NULL,NULL,NULL,1),(27,'Core ACL',0,'civicrm_acl_role',1,'All','delete contacts',NULL,NULL,NULL,1),(28,'Core ACL',0,'civicrm_acl_role',1,'All','delete in CiviEvent',NULL,NULL,NULL,1),(29,'Core ACL',0,'civicrm_acl_role',1,'All','delete in CiviMember',NULL,NULL,NULL,1),(30,'Core ACL',0,'civicrm_acl_role',1,'All','translate CiviCRM',NULL,NULL,NULL,1),(31,'Core ACL',0,'civicrm_acl_role',1,'All','edit grants',NULL,NULL,NULL,1),(32,'Core ACL',0,'civicrm_acl_role',1,'All','access all custom data',NULL,NULL,NULL,1),(33,'Core ACL',0,'civicrm_acl_role',1,'All','access uploaded files',NULL,NULL,NULL,1),(34,'Core ACL',0,'civicrm_acl_role',1,'All','add contacts',NULL,NULL,NULL,1),(35,'Core ACL',0,'civicrm_acl_role',1,'All','administer CiviCRM',NULL,NULL,NULL,1),(36,'Core ACL',0,'civicrm_acl_role',1,'All','edit all contacts',NULL,NULL,NULL,1),(37,'Core ACL',0,'civicrm_acl_role',1,'All','edit contributions',NULL,NULL,NULL,1),(38,'Core ACL',0,'civicrm_acl_role',1,'All','edit event participants',NULL,NULL,NULL,1),(39,'Core ACL',0,'civicrm_acl_role',1,'All','edit groups',NULL,NULL,NULL,1),(40,'Core ACL',0,'civicrm_acl_role',1,'All','edit memberships',NULL,NULL,NULL,1),(41,'Core ACL',0,'civicrm_acl_role',1,'All','edit pledges',NULL,NULL,NULL,1),(42,'Core ACL',0,'civicrm_acl_role',1,'All','access CiviReport',NULL,NULL,NULL,1),(43,'Core ACL',0,'civicrm_acl_role',1,'All','access Report Criteria',NULL,NULL,NULL,1),(44,'Core ACL',0,'civicrm_acl_role',1,'All','administer Reports',NULL,NULL,NULL,1),(45,'Core ACL',0,'civicrm_acl_role',1,'All','import contacts',NULL,NULL,NULL,1),(46,'Core ACL',0,'civicrm_acl_role',1,'All','make online contributions',NULL,NULL,NULL,1),(47,'Core ACL',0,'civicrm_acl_role',1,'All','make online pledges',NULL,NULL,NULL,1),(48,'Core ACL',0,'civicrm_acl_role',1,'All','profile listings and forms',NULL,NULL,NULL,1),(49,'Core ACL',0,'civicrm_acl_role',1,'All','profile create',NULL,NULL,NULL,1),(50,'Core ACL',0,'civicrm_acl_role',1,'All','profile edit',NULL,NULL,NULL,1),(51,'Core ACL',0,'civicrm_acl_role',1,'All','profile listings',NULL,NULL,NULL,1),(52,'Core ACL',0,'civicrm_acl_role',1,'All','profile view',NULL,NULL,NULL,1),(53,'Core ACL',0,'civicrm_acl_role',1,'All','register for events',NULL,NULL,NULL,1),(54,'Core ACL',0,'civicrm_acl_role',1,'All','view all activities',NULL,NULL,NULL,1),(55,'Core ACL',0,'civicrm_acl_role',1,'All','view all contacts',NULL,NULL,NULL,1),(56,'Core ACL',0,'civicrm_acl_role',1,'All','view event info',NULL,NULL,NULL,1),(57,'Core ACL',0,'civicrm_acl_role',1,'All','view event participants',NULL,NULL,NULL,1),(58,'Core ACL',0,'civicrm_acl_role',1,'All','edit all events',NULL,NULL,NULL,1),(59,'Core ACL',0,'civicrm_acl_role',2,'All','access CiviMail subscribe/unsubscribe pages',NULL,NULL,NULL,1),(60,'Core ACL',0,'civicrm_acl_role',2,'All','access all custom data',NULL,NULL,NULL,1),(61,'Core ACL',0,'civicrm_acl_role',2,'All','make online contributions',NULL,NULL,NULL,1),(62,'Core ACL',0,'civicrm_acl_role',2,'All','make online pledges',NULL,NULL,NULL,1),(63,'Core ACL',0,'civicrm_acl_role',2,'All','profile listings and forms',NULL,NULL,NULL,1),(64,'Core ACL',0,'civicrm_acl_role',2,'All','register for events',NULL,NULL,NULL,1),(65,'Core ACL',0,'civicrm_acl_role',2,'All','view event info',NULL,NULL,NULL,1);:
DB Error: already exists
```
Drush command terminated abnormally due to an unrecoverable error.https://lab.civicrm.org/dev/drupal/-/issues/79Error when upgrading to 5.16.02022-08-12T05:14:12ZJGauntError when upgrading to 5.16.0Not sure if this is the right place to add the issue so apologies in advance.
I've attempted to upgrade three separate sites on three separate servers from 5.14 and 5.15 to 5.16.0 and all three came back with the following error:
Error...Not sure if this is the right place to add the issue so apologies in advance.
I've attempted to upgrade three separate sites on three separate servers from 5.14 and 5.15 to 5.16.0 and all three came back with the following error:
Error: syntax error, unexpected ':', expecting '{' in /home/example/public_html/sites/all/modules/civicrm/vendor/league/csv/src/functions.php, line 33
The three sites are all on Drupal 7 on PHP 7.1 although I did upgrade one temporarily to 7.2 and also 7.3 to see if that made a difference which it didn't.
I'm used to upgrading civi on many different sites all the time so I don't believe it to be a fault of my own.
I tried to upgrade the usual way:
- Delete old codebase
- Unpack new code base
- Run 'drush civicrm-upgrade-db'
It is when I enter the drush command the error flags up and the update fails. I've used the same method countless times in the past so I do think there is an issue somewhere.
Thanks,
Jade5.16.3https://lab.civicrm.org/dev/drupal/-/issues/78Drupal8: cv --user=2019-07-16T16:30:48ZAlanDixonDrupal8: cv --user=Drupal 8.7.4, CiviCRM 5.15.1, php 7.3
When trying to run this command (cli)
cv --user=blackfly --cwd=/var/www/drupal/web api job.process_mailing
I get this:
<code><pre>[Symfony\Component\Debug\Exception\FatalThrowableError] ...Drupal 8.7.4, CiviCRM 5.15.1, php 7.3
When trying to run this command (cli)
cv --user=blackfly --cwd=/var/www/drupal/web api job.process_mailing
I get this:
<code><pre>[Symfony\Component\Debug\Exception\FatalThrowableError]
Call to undefined method Drupal\Core\Session\AccountProxy::get()
</pre></code>
I'm guessing it's cv that is insufficiently booting Drupal.https://lab.civicrm.org/dev/drupal/-/issues/75[regression] `cv` fails on CiviCRM 5.15.02022-04-06T22:13:17ZJonGold[regression] `cv` fails on CiviCRM 5.15.0Any command that attempts to access Civi fails with:
```
[RuntimeException]
Cannot resolve path using "cms.root.url"
```
Civi 5.14.2 works fine.
The issue is `CRM...Any command that attempts to access Civi fails with:
```
[RuntimeException]
Cannot resolve path using "cms.root.url"
```
Civi 5.14.2 works fine.
The issue is `CRM_Utils_System_Drupal8::languageNegotiationURL()`, which was added in 5.15.0. Removing this function restores the correct behavior, but I assume has a detrimental effect on multilingual.
The underlying cause of the error is hidden because of a later PR by @bgm that accounts for the REST API. If you roll back his change, the error becomes:
```
[Drupal\Core\DependencyInjection\ContainerNotInitializedException]
\Drupal::$container is not initialized yet. \Drupal::setContainer() must be called with a real container.
```5.16.0https://lab.civicrm.org/dev/drupal/-/issues/66Recurring contributions fail to be recorded2019-06-03T08:37:17ZBobSRecurring contributions fail to be recordedAfter upgrading from from 5.10.3 to 5.13.4, certain recurring contributions from PayPal began to not be recorded, while others were recorded.
The server log indicated:
* Posts to civicrm/extern/ipn.php were failing with "Call to undefin...After upgrading from from 5.10.3 to 5.13.4, certain recurring contributions from PayPal began to not be recorded, while others were recorded.
The server log indicated:
* Posts to civicrm/extern/ipn.php were failing with "Call to undefined function variable_get() in ...civicrm/CRM/Utils/System/Drupal.php:790"
* Posts to civicrm/payment/ipn/1 were successful.
It appears that during the failed posts, we arrive in civicrm/CRM/Utils/System/Drupal.php::getTimeZoneString() without bootstrapping Drupal and die on a call to variable_get('configurable_timezones', 1).
Failure was confirmed on https://civicrm.demo.civihosting.com (received HTTP status 500 on a post to civicrm/extern/ipn.php).5.14.0https://lab.civicrm.org/dev/drupal/-/issues/65Drupal7: civicrm_rules - Add/Remove contact from CiviCRM Group works with dep...2024-02-27T01:13:41ZVangelisPDrupal7: civicrm_rules - Add/Remove contact from CiviCRM Group works with deprecated method on removal### Problem/Motivation
In the the civicrm_rules module, specifically `drupal/modules/civicrm_rules/civicrm_rules_utils.inc` and on line 64 there's this function `_civicrm_rules_group_contact` that by default uses the 'create' action if ...### Problem/Motivation
In the the civicrm_rules module, specifically `drupal/modules/civicrm_rules/civicrm_rules_utils.inc` and on line 64 there's this function `_civicrm_rules_group_contact` that by default uses the 'create' action if we want to add a contact into a CiviCRM Group which works absolutely fine.
However, when we want to delete a contact, this is what is initially being called:
`civicrm_api('group_contact', 'delete', $params);`
which I believe as an action it is now considered as deprecated and (most probably because of that), it's behaving weird:
It will remove a contact from a static group, but it will not remove a contact from a smartgroup.
### Steps to reproduce
Create a rule so that it has an action that will remove an existing CiviCRM contact from a group on webform submission (or something related to that).
Outcome:
* Rule will apply and contact will be removed if that group that he belongs to is a static group
* Rule will not apply and contact will **not** be removed if that group that he belongs to is a smartgroup
### Proposed resolution
Current function:
```php
/**
* Function to add contacts to group
*/
function _civicrm_rules_group_contact($contactId, $groupId, $action = 'create') {
civicrm_initialize();
$params = array(
'contact_id' => $contactId,
'group_id' => $groupId,
'version' => 3,
);
// This used to be civicrm_group_contact_common($params, $action);
civicrm_api('group_contact', $action, $params);
}
```
Proposed change:
```php
/**
* Function to add/remove contacts to group
*/
function _civicrm_rules_group_contact($contactId, $groupId, $action = 'create') {
civicrm_initialize();
$params = array(
'contact_id' => $contactId,
'group_id' => $groupId,
'version' => 3,
);
if ($action == 'delete') {
$params['status'] = 'Removed';
}
// This used to be civicrm_group_contact_common($params, $action);
civicrm_api('group_contact', 'create', $params);
}
```
Basically we keep the action as 'create' and then we intercept the incoming $action variable.
If it has the 'delete' value, we add to the $params the 'status' = 'Removed' so that it can remove it.
I tried that fix and it works for me but i would ask you to replicate it in your environment(s) as well.https://lab.civicrm.org/dev/drupal/-/issues/64Drupal8/Backdrop: Bad URL on ACL page linking to CMS permissions2020-11-04T20:49:06ZJonGoldDrupal8/Backdrop: Bad URL on ACL page linking to CMS permissions`CRM_Admin_Page_Access::run()` attempts to generate a URL to the CMS permission page. It uses a switch to give a CMS-specific URL.
I wrote a Backdrop and D8-specific code, using `url()` and `\Drupal\Core\Url::fromUri()` respectively - ...`CRM_Admin_Page_Access::run()` attempts to generate a URL to the CMS permission page. It uses a switch to give a CMS-specific URL.
I wrote a Backdrop and D8-specific code, using `url()` and `\Drupal\Core\Url::fromUri()` respectively - but I think this is overcomplicated. Couldn't we just pass a string instead? Or is there some oddball situation (multi-site?) where you need to generate the URL using the Drupal-specific functions?JonGoldJonGoldhttps://lab.civicrm.org/dev/drupal/-/issues/62Possible rework on path checking on function civicrm_user_form_validate for 7...2021-02-05T10:40:39ZVangelisPPossible rework on path checking on function civicrm_user_form_validate for 7.x branchI have had some issues with a civicrm profile validation (even with the default `Name and Address`) when it was being exposed in the drupal user registration page after adding some ajax there.
Problem that appears when you ajaxify the ...I have had some issues with a civicrm profile validation (even with the default `Name and Address`) when it was being exposed in the drupal user registration page after adding some ajax there.
Problem that appears when you ajaxify the form itself, is that contents are getting replaced. When this happens, `civicrm_user_form_validate` doesn't work. Specifically, arg(0) & arg(1) are changing (see below).
Searching a little bit more, I have noticed on [line ~~681~~ 707](https://github.com/civicrm/civicrm-drupal/blob/7.x-master/civicrm.module#L707) that there's an arg() comparison so that Civi can understand what path users are coming from ([here](https://github.com/civicrm/civicrm-drupal/blob/7.x-master/civicrm.module#L694))
May I suggest (i can make a MR) instead of doing a path search using the arg() variable, check the form `#action` or `#user_category` instead, like:
* `$register = (($form['#action'] == '/user/register' || $form['#action'] == '/admin/people/create') ? TRUE : FALSE);`
or
* `$register = (($form['#user_category'] == 'account' || $form['#user_category'] == 'register')) ? TRUE : FALSE);` (This is taken from `user_account_form_validate` [function here](https://api.drupal.org/api/drupal/modules!user!user.module/function/user_account_form_validate/7.x))
This way, validation is always there, as long as the form `#action` or `#user_category` keeps the same name(s).
One relatively easy way to reproduce is this:
On a/any environment having Drupal 7.x:
* Download and enable [bootstrap](https://www.drupal.org/project/bootstrap) as the default theme
* Download and enable [bootstrap_login_modal](https://www.drupal.org/project/bootstrap_login_modal) which will add AJAX to the user login and user register form(s). This will also cause the non-validation issue i am referring to.
* Try to register yourself and don't add a first and last name, validation will not kick-in.
Now change the civicrm.module on line 681 with the above and re-try to register yourself. Validations will now work.
There is another issue there but it'm still looking at it: The warning comes back, eg. First name is a required field but the CiviCRM profile fields do not light up, they don't inherit the class `.has-error`.https://lab.civicrm.org/dev/drupal/-/issues/60Drupal 8 doesn't see routes for mailchimp extension2019-04-26T20:13:29ZjohnkDrupal 8 doesn't see routes for mailchimp extensionsee also: https://github.com/veda-consulting/uk.co.vedaconsulting.mailchimp/issues/321
I get a 404 for all the pages specific to the mailchimp extension, when running under a D8 site.
I'm unsure whether this is a bug in the extension i...see also: https://github.com/veda-consulting/uk.co.vedaconsulting.mailchimp/issues/321
I get a 404 for all the pages specific to the mailchimp extension, when running under a D8 site.
I'm unsure whether this is a bug in the extension itself, or the civicrm-drupal-8 module, so I thought I'd open an issue here, as well.https://lab.civicrm.org/dev/drupal/-/issues/57Editing contribution recorded as "Deleted Activity" when full log is enabled2021-02-04T19:23:38ZtapashEditing contribution recorded as "Deleted Activity" when full log is enabledIf an existing contribution edited when full log is enabled, it records in chage log as "Deleted Activity". Is this how it should be?If an existing contribution edited when full log is enabled, it records in chage log as "Deleted Activity". Is this how it should be?