Drupal issueshttps://lab.civicrm.org/dev/drupal/-/issues2019-09-17T23:26:00Zhttps://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/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/77Drupal8: scripts in /libraries/civicrm/extern/ denied2024-01-29T09:55:42ZAlanDixonDrupal8: scripts in /libraries/civicrm/extern/ deniedTesting with CiviCRM 5.15.0, Drupal 8.7.4
Drupal's .htaccess file prevents apache from directly calling scripts except in specific directories.
So, for example, CiviMail links that go to https://domain.org/libraries/civicrm/extern/url....Testing with CiviCRM 5.15.0, Drupal 8.7.4
Drupal's .htaccess file prevents apache from directly calling scripts except in specific directories.
So, for example, CiviMail links that go to https://domain.org/libraries/civicrm/extern/url.php?u=14&qid=11 gets
Forbidden
You don't have permission to access /libraries/civicrm/extern/url.php on this server.
The best solution I've seen so far is to include
<IfModule mod_rewrite.c>
RewriteEngine Off
</IfModule>
in the extern directory.
I suspect this is a new issue due to changes in the .htaccess file in Drupal, but I'm not sure.https://lab.civicrm.org/dev/drupal/-/issues/76Proposal: Don't migrate drush commands to D82020-06-19T16:21:14ZJonGoldProposal: Don't migrate drush commands to D8CiviCRM drush commands are incompatible with modern versions of drush.
I investigated this, and each command will need to be rewritten for drush 9/D8. I've created a framework and ported a couple of my most used commands (e.g. `drush c...CiviCRM drush commands are incompatible with modern versions of drush.
I investigated this, and each command will need to be rewritten for drush 9/D8. I've created a framework and ported a couple of my most used commands (e.g. `drush civicrm-sql-cli`, `drush civicrm-sql-dump`) but there's a compelling argument to simply not rewriting drush and instead making sure that `cv` has feature parity.
For those who DO think we should continue to maintain the drush commands, I have a branch here: https://github.com/MegaphoneJon/civicrm-drupal-8
Klaas has also submitted a PR to add `drush civicrm-api` to this branch.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/72confirmation screen shows internal profile name not public title (reg screen ...2019-08-07T18:07:13ZDLaurysconfirmation screen shows internal profile name not public title (reg screen shows public title)The profile names that appear on the screen when registering for an event don't match between the register screen and the confirmation screen. The register screen uses the 'public title' of the profile, which is great! But then the confi...The profile names that appear on the screen when registering for an event don't match between the register screen and the confirmation screen. The register screen uses the 'public title' of the profile, which is great! But then the confirmation screen shows the internal profile name.5.17.0https://lab.civicrm.org/dev/drupal/-/issues/69Drupal8: Problem with user registration confirm email flow2020-09-18T09:50:52ZwannesderoyDrupal8: Problem with user registration confirm email flowIn our Drupal8 & CiviCRM setup we allow visitors to create accounts, with email verification. These users are created by CiviCRM when they sign up for a membership.
We encountered some issues around the registration process: the user wa...In our Drupal8 & CiviCRM setup we allow visitors to create accounts, with email verification. These users are created by CiviCRM when they sign up for a membership.
We encountered some issues around the registration process: the user was denied permission to the password form. And the onetime login link in the mail was always invalid.
In the CRM/Utils/System/Drupal8.php file we changed some of the user registration logic to be the same as the default Drupal 8 way.
1) First issue was that the user account was not set to 1 (active) when $verify_mail_conf was set to true. In default drupal this is the case.
2) Second issue was the user was logged in immediately after sending the verification mails, this should not happen when the verify_mail_conf setting is true. User may only be logged in when checking the mail and following the onetime login link.
[civicrm-core-d8-create-user-fix.patch](/uploads/876064009461686e9ef556adb5ae4676/civicrm-core-d8-create-user-fix.patch)https://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/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/63Drupal8: drupal_set_message is deprecated (or: Event Cart messages display HTML)2019-06-13T15:07:11ZbgmDrupal8: drupal_set_message is deprecated (or: Event Cart messages display HTML)When using the CiviCRM Event Cart in Drupal8, some status messages display HTML to the user.
[This PR](https://github.com/civicrm/civicrm-core/pull/13959) fixes two things:
* It uses `\Drupal\Core\Render\Markup::create` to handle marku...When using the CiviCRM Event Cart in Drupal8, some status messages display HTML to the user.
[This PR](https://github.com/civicrm/civicrm-core/pull/13959) fixes two things:
* It uses `\Drupal\Core\Render\Markup::create` to handle markup before displaying it.
* It uses the Messenger service, because drupal_set_message is deprecated since Drupal 8.5.x (2017) https://www.drupal.org/node/27749315.16.0https://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/61Menubar css failing to generate with debugging enabled on staging site2020-10-24T21:30:32ZRafaelMenubar css failing to generate with debugging enabled on staging siteI have several CiviCRM instances running on a single server. They are all set up as staging environments.
All systems are running on:
- Ubuntu 16.04
- Drupal 7.66
- CiviCRM 5.13.1
- php7.2
All system had their environment set to s...I have several CiviCRM instances running on a single server. They are all set up as staging environments.
All systems are running on:
- Ubuntu 16.04
- Drupal 7.66
- CiviCRM 5.13.1
- php7.2
All system had their environment set to staging `$civicrm_setting['domain']['environment'] = 'Staging';` inside the `civicrm.settings.php` file.
Upon upgrading from 5.12 to 5.13.1 we encountered an issue with the dynamically generated `crm-menubar.css` stylesheet. Two of the five sites on our server were not generating this file and instead, the following truncated URL was being attached to the page:
`@import url("https://staging.sitename.org/index.php?pr4crf");`
Comparing with the other three working sites the import should have been of the form:
`@import url("https://dmaster.demo.civicrm.org/sites/default/files/civicrm/persist/contribute/dyn/crm-menubar.e90e0a297b223ee5d9ec64abe1b000c1.css?pr4crf");`
As a result of this CSS file not being loaded, the main navigation bar appeared completely unstyled at the bottom of all pages.
Directory permissions and Resource URLs were identical across all servers. All caches - Drupal and CiviCRM - were cleared and the contents of template_c/ manually deleted several times.
Further investigation found the working sites had the Enable Debugging setting set to off. Enabling debugging immediately caused the same truncated error on the unaffected servers and turning it off fixed the issue.
In the case of some sites, the Asset Caching feature had to also be set to Disable and then back to auto along with clearing CiviCRM Caches and Resetting all paths before the change would take effect.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/59deprecate civicrm_engage2021-02-02T00:49:50Zjamiedeprecate civicrm_engageI'd like to propose we begin a process of deprecating and then removing the civicrm_engage module from the civivicrm-drupal repository.
I've just posted a blog outlining replacement extensions that can now be used with some instructions...I'd like to propose we begin a process of deprecating and then removing the civicrm_engage module from the civivicrm-drupal repository.
I've just posted a blog outlining replacement extensions that can now be used with some instructions for anyone still using civicrm_engage:
https://civicrm.org/blog/jamie/civicrmengage-is-dead-long-live-civicrmengage
I'm not sure the best process to take to deprecate a drupal module. Open to suggestions or, if we have already deprecated a drupal module in the past, pointers to the documentation or code changes we made.5.18.0https://lab.civicrm.org/dev/drupal/-/issues/58Add Contact ID operator to the contact reference filter added in drupal view2019-04-24T06:50:11ZjitendraAdd Contact ID operator to the contact reference filter added in drupal viewContact Reference filter in a Drupal view only lets user to filter on sort_name. This field can have duplicate values on multiple contact records. It might be helpful if we could filter the results based on contact id.
Use-case
- Add a...Contact Reference filter in a Drupal view only lets user to filter on sort_name. This field can have duplicate values on multiple contact records. It might be helpful if we could filter the results based on contact id.
Use-case
- Add a contact ref custom field on a custom set extending individual. Eg `Alternate Contact Person`
- Add value to this field eg "Ashlie Adams".
- Suppose the db have more than one contact having the same sort name. eg id 203 and 206
- I need to create a Drupal view filtering values which have `Alternate Contact Person` set to contact id 203.
- The current set of filters will list all contacts for 203 and 206.
- This ticket is to address that limitation.jitendrajitendra