Drupal issueshttps://lab.civicrm.org/dev/drupal/-/issues2021-02-04T19:26:45Zhttps://lab.civicrm.org/dev/drupal/-/issues/90SMS limit is hardcoded at 460 but should be changeable somewhere2021-02-04T19:26:45ZjasonobrownSMS limit is hardcoded at 460 but should be changeable somewhereTwillio (and probably other sms providers) allows SMS messages up to 1600 characters, but Civi has the limit hardcoded at 460. I've verified that by simply going to CRM/SMS/Provider.php and changing MAX_SMS_CHAR from 460 to 1600 the sys...Twillio (and probably other sms providers) allows SMS messages up to 1600 characters, but Civi has the limit hardcoded at 460. I've verified that by simply going to CRM/SMS/Provider.php and changing MAX_SMS_CHAR from 460 to 1600 the system now accepts (and sends) messages up to 1600 characters. It seems logical that the character limit should able to be adjusted and stored somewhere rather than set as a static value in the code. We are currently using the larger limit, and would really like to see this implemented asap so that we can stop manually updating the code each time we update civi.https://lab.civicrm.org/dev/drupal/-/issues/23[webform_civicrm] - Webform CiviCRM module - Drupal 8 prototyping2020-10-15T16:29:06ZKarinG[webform_civicrm] - Webform CiviCRM module - Drupal 8 prototypingI sat down with Will & David this week to take a look at what D8 Webform-CiviCRM might look like. I've been playing with the Webform 5 module and really love it. We talked about handlers and element types and the pros & cons of those. I'...I sat down with Will & David this week to take a look at what D8 Webform-CiviCRM might look like. I've been playing with the Webform 5 module and really love it. We talked about handlers and element types and the pros & cons of those. I'm still learning the new system so I may revise this, but here are my thoughts so far.
In Webform-CiviCRM D7, there is a massive configuration form for the CiviCRM-related form settings. It configures the data handling and it also auto-generates webform elements and links them to their corresponding CiviCRM entity field. It looks like this:
![Webform-CiviCRM-D7](/uploads/68e92ea62fe22aaf37293c778aa5ee3a/Webform-CiviCRM-D7.png)
Note that checking a box on this form will actually insert a corresponding element into the Webform. I've always thought that was much more user-frieldly than the alternative of making the user create a new element and then go over to a "mapping" screen to link it to CiviCRM. So I'd like to keep that kind of behavior.
But playing around with the D8 interface, I think we could break this monolithic form up by entity and integrate it better with the webform admin screen. Here's my spitball proposal:
1. Create a bunch of new "container" type elements, one per supported CiviCRM entity type (Contact, Participant, Activity, etc).
2. Add a new button on the webform elements page to add these CiviCRM entity containers to the form.
3. Adding one would automatically enable our CiviCRM submission handler.
4. Editing a container would pop up a configuration form specific to that entity - it would look a lot like one of the panes on the webform-civicrm D7 admin screen above.
5. Checking a checkbox on that form would result in a new webform element being added into the container.
6. The admin user would still be free to move elements around and rename them. I don't see any reason why they wouldn't be able to move them outside of the container too. The mapping wouldn't be dependent on that.
7. The entity container itself could be styled to look like a fieldset, flexbox, div, etc.
Here's a photoshopped mockup of what that might look like. Note that in D8, popups float to the right on wide screens, so what you're seeing here would be the result of clicking the "Edit" button on the CiviCRM contact.
![Webform_Mockup_1](/uploads/b369bedbee01eb0f70cce22910c5472d/Webform_Mockup_1.png)https://lab.civicrm.org/dev/drupal/-/issues/6Migrate 8.x branches to separate git repo2020-07-16T17:23:37ZtottenMigrate 8.x branches to separate git repo__Background__: The `civicrm-drupal.git` repo has branches named `8.x-*`. However, these are not detectable/addressable via `composer`/`packagist`.
__Tasks__
* __(a)__: Create new repo `civicrm-drupal-8`. Migrate the `8.x-*` branches, ...__Background__: The `civicrm-drupal.git` repo has branches named `8.x-*`. However, these are not detectable/addressable via `composer`/`packagist`.
__Tasks__
* __(a)__: Create new repo `civicrm-drupal-8`. Migrate the `8.x-*` branches, but remove the `8.x-` prefix.
* __(b)__: Update release process to ensure that these are branched/tagged.D8 General Availabilityhttps://lab.civicrm.org/dev/drupal/-/issues/49Clearing CiviCRM cache not regenerating the angular-modules.js2022-12-02T01:43:08ZshaneonabikeClearing CiviCRM cache not regenerating the angular-modules.js**What Happened**
I realize this //could be// an edge case, but I accidentally deleted the angular-modules.js file when installing D8 with CiviCRM.
**What did I expect**
Either that an error message on /civicrm/a/#/status indicating ho...**What Happened**
I realize this //could be// an edge case, but I accidentally deleted the angular-modules.js file when installing D8 with CiviCRM.
**What did I expect**
Either that an error message on /civicrm/a/#/status indicating how I could rebuild this file and/or when clearing the CiviCRM cache it would be regenerated.
**What I tried**
- Tried to clear the cache (nothing changed)
- Tried to run composer update (nothing changed)
- Wasn't sure where or how to run bower update in order to attempt that part
I would be happy to add additional information on the wiki as well if that helps with relation to this. I just thought that perhaps we could put some additional messages do indicate that angular is not found and therefore some parts might not work properly.https://lab.civicrm.org/dev/drupal/-/issues/36Unfork zetacomponents/mail (also helps Drupal8)2019-01-08T14:53:17ZbgmUnfork zetacomponents/mail (also helps Drupal8)zetacomponents/mail was [forked](https://github.com/civicrm/zetacomponents-mail/tree/1.7-civi) in early 2017 for PHP 7 compatibility. However, the base branch has had updates since which fix the PHP issues, and also add a new features fo...zetacomponents/mail was [forked](https://github.com/civicrm/zetacomponents-mail/tree/1.7-civi) in early 2017 for PHP 7 compatibility. However, the base branch has had updates since which fix the PHP issues, and also add a new features for STARTTLS that might be interesting (and solves issues such as: https://github.com/civicrm/zetacomponents-mail/pull/2)
I encounted this issue while playing around with composer and Drupal8 from scratch:
```
$ composer create-project drupal-composer/drupal-project:8.x-dev myproject --stability dev --no-interaction
$ cd myproject
$ composer require civicrm/civicrm-core:5.7.2 --prefer-dist
./composer.json has been updated
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for civicrm/civicrm-core 5.7.2 -> satisfiable by civicrm/civicrm-core[5.7.2].
- civicrm/civicrm-core 5.7.2 requires zetacomponents/mail dev-1.7-civi -> no matching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.
[...]
```
This can be fixed by specifying the URL of CiviCRM's fork, but eh, if we can remove it, why not?
cc @jackrabbithanna @dsnopekhttps://lab.civicrm.org/dev/drupal/-/issues/35Drupal8: CiviCRM checks assume a single-database installation2020-10-26T15:25:58ZJonGoldDrupal8: CiviCRM checks assume a single-database installationI typically set up CiviCRM in a separate database, with a single MySQL user granted the minimum necessary permissions to change both CMS and CRM.
Drupal8 is incorporating CiviCRM checks into Drupal - but I get the error message (with th...I typically set up CiviCRM in a separate database, with a single MySQL user granted the minimum necessary permissions to change both CMS and CRM.
Drupal8 is incorporating CiviCRM checks into Drupal - but I get the error message (with the permissions below) that I don't have permission to create triggers on my database.
What's actually happening is I don't have permission to create triggers on the Drupal database. I can create triggers on the Civi db.
Below you can see the command I ran that bypassed the issue.
Since this blocks Drupal upgrades, it feels reasonably serious to resolve. I feel a little lost in D8 though - I was looking for `hook_requirement`, which is how I'd ordinarily add a status check in D7, but couldn't find it (except in the install file).
```
mysql> show grants for myorg_test@localhost;
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for myorg_test@localhost |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'myorg_test'@'localhost' |
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, TRIGGER ON `myorg_test_civi`.* TO 'myorg_test'@'localhost' |
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON `myorg_test_drupal`.* TO 'myorg_test'@'localhost' |
| GRANT EXECUTE, ALTER ROUTINE ON FUNCTION `myorg_test_civi`.`civicrm_strip_non_numeric` TO 'myorg_test'@'localhost' |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.00 sec)
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, TRIGGER ON `myorg_test_drupal`.* TO 'myorg_test'@'localhost';
Query OK, 0 rows affected (0.00 sec)```https://lab.civicrm.org/dev/drupal/-/issues/13Contact Image uploaded from Drupal Webform doesn't render on Drupal View as a...2021-09-08T11:25:32ZjitendraContact Image uploaded from Drupal Webform doesn't render on Drupal View as a thumbnail.This is an extension of a fix done recently via https://github.com/civicrm/civicrm-core/pull/11681. As it only contained the fix to render the image on the contact summary page, we also have this issue on a Drupal view which needs to be ...This is an extension of a fix done recently via https://github.com/civicrm/civicrm-core/pull/11681. As it only contained the fix to render the image on the contact summary page, we also have this issue on a Drupal view which needs to be addressed. To replicate, upload an image for a contact using a webform and try to render it as a thumbnail on a Drupal view.
Also, if the filename of the image has a space in it, it fails to load on the view.5.43.0https://lab.civicrm.org/dev/drupal/-/issues/10Keep `civicrm-version.php` up-to-date without running GenCode on all builds2020-07-16T17:23:38ZtottenKeep `civicrm-version.php` up-to-date without running GenCode on all buildsWe aim to allow installing CiviCRM on Drupal 8 via `composer`/`git` without requiring the admin to run `GenCode`.
The file `civicrm-version.php` is generated by `GenCode`. A typical copy looks like this:
```php
<?php
/**
* Get the Civ...We aim to allow installing CiviCRM on Drupal 8 via `composer`/`git` without requiring the admin to run `GenCode`.
The file `civicrm-version.php` is generated by `GenCode`. A typical copy looks like this:
```php
<?php
/**
* Get the CiviCRM version.
*/
function civicrmVersion() {
return array(
'version' => '4.7.30',
'cms' => 'Drupal',
'revision' => '4.7.30',
);
}
```
A simple fix might be:
* Commit the file to `civicrm-core.git` (much like in #1).
* Update `tools/bin/scripts/set-version.php` to maintain this file. (That script is part of the workflow whenever setup a new release.)
There's one catch: the `cms` field varies depending on the local runtime. *However*, we may be lucky here -- in a cursory check, I only found a couple places that relied on it. ~~The task here would be to take a closer look and potentially remove this element.~~ We'd also need to resolve these stale references to `cms`:
* `civicrm.drush.inc` (in `civicrm-backdrop-1.x`, `civicrm-drupal-6.x`, `civicrm-drupal-7.x`, `civicrm-drupal-8.x`)
* Use constants or functions from Drupal/Drush/Backdrop to detect the active environment.
* `install/index.php` and `install/template.html`
* Remove or rewrite any optional sanity checks that rely on this field.
* Use `$installType` to backfill `$civicrm_version['cms']` (like the WordPress conditional does)D8 General Availabilityhttps://lab.civicrm.org/dev/drupal/-/issues/5Add support for Drupal 8 to cv (`Bootstrap.php` and `CmsBootstrap.php`)2020-07-16T17:23:37ZtottenAdd support for Drupal 8 to cv (`Bootstrap.php` and `CmsBootstrap.php`)D8 General Availabilitytottentottenhttps://lab.civicrm.org/dev/drupal/-/issues/4Use `civicrm-setup` to handle installation2020-08-07T03:28:13ZtottenUse `civicrm-setup` to handle installation**Background**: During installation, one must check system-requirements, populate database, etc. To do this, the Drupal 8 integration currently calls some functions from `install/`.
However, the functions in the `install/` folder are t...**Background**: During installation, one must check system-requirements, populate database, etc. To do this, the Drupal 8 integration currently calls some functions from `install/`.
However, the functions in the `install/` folder are too narrowly crafted -- we don't have much ability to add/change/rearrange/remove installer steps. [civicrm-setup](https://civicrm.org/blog/totten/developers-revising-the-civicrm-installer-library-cli-wordpress) aims to redress that limitation and make it easier to iterate on the installer. For any new distribution channels (like D8), we should call `civicrm-setup`.
__Tasks__:
* __(a)__ `civicrm.drush.inc`: The function `drush_civicrm_install()` must use the `civicrm-setup` API (eg `installFiles()`, `installDatabase()`).
* __(b)__ `civicrm.install`: The function `civicrm_install()` must use setup API (eg `installFiles()`, `installDatabase()`).
* __(c)__ `civicrm.install`: The function `civicrm_requirements()` should use the setup API (eg `checkRequirements`, `checkAuthorized`).D8 General Availabilityhttps://lab.civicrm.org/dev/drupal/-/issues/2Implement D8 initialization for civicrm-setup2020-07-16T17:23:36ZtottenImplement D8 initialization for civicrm-setup__Background__: When installing on Drupal 8, settings such as DSN and locale should be autodetected.
__Task__:
* Copy `plugins/init/Drupal.civi-setup.php` or `plugins/init/WordPress.civi-setup.php`
* Create `Drupal8.civi-setup.php`
* A...__Background__: When installing on Drupal 8, settings such as DSN and locale should be autodetected.
__Task__:
* Copy `plugins/init/Drupal.civi-setup.php` or `plugins/init/WordPress.civi-setup.php`
* Create `Drupal8.civi-setup.php`
* Adapt for D8. For source material on how to detect things like DSN, look at `civicrm-drupal@8.x-master` in `civicrm.install` / `drush.civicrm.inc`.D8 General AvailabilityMonish DebMonish Debhttps://lab.civicrm.org/dev/drupal/-/issues/182Drupal 7 modules not ported to Drupal 9 yet2022-09-09T10:08:56Zluke.stewartDrupal 7 modules not ported to Drupal 9 yetCurrently there are a number of Drupal 7 modules that have not been ported to Drupal 9 as a - comes bundled with CiviCRM - code located within the CiviCRM codebase on install.
This can be seen by comparing
https://github.com/civicrm/civ...Currently there are a number of Drupal 7 modules that have not been ported to Drupal 9 as a - comes bundled with CiviCRM - code located within the CiviCRM codebase on install.
This can be seen by comparing
https://github.com/civicrm/civicrm-drupal/tree/7.x-master/modules
and
https://github.com/civicrm/civicrm-drupal-8/tree/master/modules/
Now a number of these modules it doesn't make sense to run in D9:
Views, CiviCRM OG Sync CiviCRM Engage and possibly others?
Some have a D9 module:
CiviCRM Group Roles has been set up as a stand alone project
https://www.drupal.org/project/civicrm_group_roles
CiviCRM Theme has been set up as part of the civicrm-drupal-8 codebase
CiviCRM Member Roles has been proposed as a PR to the drupal-8 repo but this has been stalled for a while now.
https://github.com/civicrm/civicrm-drupal-8/pull/66
I feel like options for modules here are now:
- A) 🍎 Set up as a stand alone project leave it to Site Builders/Maintainers as to whether to install or not.
- B) 🍌 Set up as a stand alone project but require as a dependency via composer so code gets installed when installing CiviCRM
Do we have criteria for deciding which option in general?
Do we have criteria for deciding which option should be applied in the case of CiviCRM Member Roles?
- C) 🥕 Include within the CiviCRM Drupal codebase via the civicrm/civicrm-drupal-8 project
Do we need a general criteria before deciding approach for CiviCRM Member Roles?
I think probably we would not want to use B unless we wanted something in a separate module that was required for the vast majority of installs of CiviCRM to run?
Given that there has been little appetite for CiviCRM Member Roles perhaps the approach is to split this into it's own module on the basis that most D9 sites to date are probably not using - therefore perhaps this code should not be required to be present on all CiviCRM installs.
However - we still have a lot of sites running D7 - and perhaps the sites that would use Member Roles are mainly running D7?https://lab.civicrm.org/dev/drupal/-/issues/178Drupal 8 - End of Life2023-05-13T18:45:09ZtottenDrupal 8 - End of LifeDrupal 8 officially went end-of-life in November 2021 (https://www.drupal.org/psa-2021-11-30). The focus of this issue is to gauge sentiment about (and identify tasks for) ending CiviCRM's Drupal 8.x support.
(_Note: This issue has no i...Drupal 8 officially went end-of-life in November 2021 (https://www.drupal.org/psa-2021-11-30). The focus of this issue is to gauge sentiment about (and identify tasks for) ending CiviCRM's Drupal 8.x support.
(_Note: This issue has no impact on CiviCRM's support for Drupal 7 or Drupal 9 -- both continue to be supported by `drupal.org` and `civicrm.org`._)
Rationale
----------
@DaveD [made the case on Github](https://github.com/civicrm/civicrm-core/pull/23302#discussion_r858700890) as follows
> * There's the 3 reasons already mentioned:
> * Has been EOL for 6 months
> * No security updates.
> * And there have been recent drupal security fixes which would have helped prompt people to move off 8 if they were still on it.
> * Civi works equally as well on 9 as on 8
> * There's support for dropping it in chat, with nobody dissenting: https://chat.civicrm.org/civicrm/pl/qh6t761dt7gsdyp78m6stbmpwo
> * Drupal 8 to 9 is _very_ different than 6 to 7. Drupal 9 is identical to drupal 8.9 except for some deprecated functions. It's not much different than if they had called it 8.10.
> * There were many blog posts about this on the internet, about how easy it would be to upgrade compared to other jumps.
> * There was plenty of awareness ahead of time in the drupal world that drupal 8 would be unsupported.
> * From May 2021 to November 2021, the only updates for drupal 8.9.x were security updates, with repeated notices that 8 was becoming EOL.
> * There was a module available that was pretty good about pointing out what if anything you needed to change.
> * There is no CIVICRM_UF=Drupal9, because it's not needed.
I would add two more items in favor of dropping D8:
* ___Drupal 10 Support___: Preserving D8 may make it harder to add D10. While most changes can be bridged to support 2 versions major (eg D8+D9 or D9+D10), it gets more complicated with 3 major versions (D8+D9+D10). We've encountered at least one issue (involving changes in Symfony Dispatcher / PSR-14) that gets prickly with 3 major versions.
* ___Pingbacks___: There are only ~30 Civi deployments still reporting Drupal 8.x. They represent <1% of Civi-Drupal deployments.
* Note: This is based on directly examining pingbacks from 2022 -- and only counting sites with multiple pingbacks (e.g. to exclude most ephemeral test-sites). The data on `stats.civicrm.org` is confusing in this regard, because Drupal 8.x and Drupal 9.x are lumped together with UF `Drupal8`. My comments are based on examining actual version-numbers and not just UF name.
Tasks
-----
There are a few tasks to do as follow-up:
* Update installation guide
* Remove Drupal 8.x from test infra
Suggested Emojis
----------------
Please do register a quick reaction on D8 EOL. Some suggested emojis:
* :rocket: - Remove Drupal 8 compatibility at the soonest convenience.
* :turtle: - Remove Drupal 8 compatibility... just not quite yet. (Keep it until 5.51 ESR).
* :shield: - Protect Drupal 8 compatibility for a longer period of time.
* :bangbang: - Extra importance modifier. (Add this if the sentiment on the first emoji is strong - eg if you will be significantly impacted by the issue.)
(Flag whichever is the soonest that you think is appropriate/acceptable.)
(Example: If you maintain a site that's been held back on D8 because of some complicated issue and cannot resolve it in the near future, then you could say ":shield: :bangbang:".)
(You may see `totten` on all emojis for a while, since I put them in as placeholders.)https://lab.civicrm.org/dev/drupal/-/issues/154Proposal - fix for How do I add CiviCRM Activity attachment to View2021-02-04T19:20:09ZeileenProposal - fix for How do I add CiviCRM Activity attachment to ViewI'm adding this gitlab to track https://github.com/civicrm/civicrm-drupal/pull/382 which I'm going to close as it stagnated 4 years agoI'm adding this gitlab to track https://github.com/civicrm/civicrm-drupal/pull/382 which I'm going to close as it stagnated 4 years agohttps://lab.civicrm.org/dev/drupal/-/issues/135Use Exception handling for drush (d7) commands - specifically civicrm-upgrade-db2021-02-15T02:50:40ZeileenUse Exception handling for drush (d7) commands - specifically civicrm-upgrade-dbWhen there is a problem upgrading via drush this is how it looks
![Screen_Shot_2020-08-19_at_2.33.52_PM](/uploads/7f3a15ac5a07104926c78d77c9ff168d/Screen_Shot_2020-08-19_at_2.33.52_PM.png)
I think we should set exception handling 'some...When there is a problem upgrading via drush this is how it looks
![Screen_Shot_2020-08-19_at_2.33.52_PM](/uploads/7f3a15ac5a07104926c78d77c9ff168d/Screen_Shot_2020-08-19_at_2.33.52_PM.png)
I think we should set exception handling 'somewhere' & my current best guess as to where is
--- a/CRM/Upgrade/Headless.php
+++ b/CRM/Upgrade/Headless.php
@@ -30,6 +30,8 @@ class CRM_Upgrade_Headless {
set_time_limit(0);
}
+ // As long as the error scope is not deconstructed exceptions will be thrown.
+ $errorScope = CRM_Core_TemporaryErrorScope::useException();
$upgrade = new CRM_Upgrade_Form();https://lab.civicrm.org/dev/drupal/-/issues/119Exception handling - 'Allowed memory size' exhasted issues2020-10-05T22:47:08ZRob_SException handling - 'Allowed memory size' exhasted issuesI'm having issues with Exception handling. I've hit a few places, where rather than getting provided with a useful error message, I am getting WSOD and then in the Apache error logs I am seeing "PHP Fatal error: Allowed memory size of x...I'm having issues with Exception handling. I've hit a few places, where rather than getting provided with a useful error message, I am getting WSOD and then in the Apache error logs I am seeing "PHP Fatal error: Allowed memory size of xxx bytes exhausted (tried to allocate xxx bytes) in Unknown on line 0".
"Unknown on line 0" isn't very helpful. One instance where I am getting this is if I want to view a contribution page, that has "Allow individuals to contribute and / or signup for membership on behalf of an organisation?" selected, but the user does not have the 'CiviCRM: profile create' permission.
It's taken me a while to narrow down the problem following a debug_backtrace() in templates/CRM/Contribute/Form/Contribution/Main.tpl.
I've tracked it as far as CRM_Core_Exception. The constructor method here is working ok, but there is another method, getErrorData() which is somehow getting called, but I cannot figure out where from. It seems to me that there must be some kind of infinite loop thing going on with one Exception class calling another. CRM_Core_Exception extends PEAR_Exception which extends Exception.
I have at least three other instances of WSOD on the site, with the same uninformative 'Allowed memory size ..' errors in the Apache log, but I haven't got as far as tracking them down to see if it is the same thing yet.
Is anyone else having problems like this? Would appreciate any thoughts.5.31.0https://lab.civicrm.org/dev/drupal/-/issues/104Drupal8 + Plesk: User path missing from cmsRootPath()2020-01-15T06:04:53ZRar9Drupal8 + Plesk: User path missing from cmsRootPath()The cmsRootPath() is not able to get absolute path, specifically the user folder portion of the path on Plesk.
This might be caused by multisite setup, function being insufficient or permission.
To fix CRON for plesk the following nee...The cmsRootPath() is not able to get absolute path, specifically the user folder portion of the path on Plesk.
This might be caused by multisite setup, function being insufficient or permission.
To fix CRON for plesk the following needs to be changed
vendor/civicrm/civicrm-core/CRM/Utils/System/Drupal8.php at line 441:
```diff
-return $civicrm_paths['cms.root']['path'];
+return realpath($_SERVER["DOCUMENT_ROOT"]) . '/'.array_slice(explode('/', $civicrm_paths['cms.root']['path']), -1)[0];
```
The cause is that in Plesk all files and directories under a domain document root directory should belong to psacln group and to the sysuser user. Where sysuser is a user of a corresponding subscription.
CIVICRM Cron only expects a chown -R www-data|psaserv .
The way to set correct permission is a correct way to fix the issue for subdomain.
This is described in the article above in step 3. https://support.plesk.com/hc/en-us/articles/115004094934https://lab.civicrm.org/dev/drupal/-/issues/97Status report update for Drupal (similar to what was done for Backdrop)2020-01-29T14:53:02ZlarynStatus report update for Drupal (similar to what was done for Backdrop)I wrote a PR for Backdrop some time back and have been meaning to check if it would be desired for Drupal 7 as well -- if so I would be happy to base a MR here off of what I did there. Here's a visual of how it looks in Backdrop's Status...I wrote a PR for Backdrop some time back and have been meaning to check if it would be desired for Drupal 7 as well -- if so I would be happy to base a MR here off of what I did there. Here's a visual of how it looks in Backdrop's Status Report page (Drupal 7 status report would obviously look a little different):
![Screen_Shot_2019-12-04_at_7.10.28_PM](/uploads/0a83d103f2aec9652797d3ce71c41345/Screen_Shot_2019-12-04_at_7.10.28_PM.jpg)
Would a version of this for Drupal 7 be accepted?https://lab.civicrm.org/dev/drupal/-/issues/96Add user format to CiviCRM Entity2021-02-04T19:28:45ZedvanleeuwenAdd user format to CiviCRM EntityFeature request: I would like to have the following user format added to CiviCRM Entity.
In civicrm_entity.module, function _civicrm_entity_options_username_format:
` 'nick.middle.last' => t('Nick.Middle.Last'),
'nick.middlelast'...Feature request: I would like to have the following user format added to CiviCRM Entity.
In civicrm_entity.module, function _civicrm_entity_options_username_format:
` 'nick.middle.last' => t('Nick.Middle.Last'),
'nick.middlelast' => t('Nick.MiddleLast'),`
[civicrm_entity.module](/uploads/bd29a74959e50bc5fc2411891d0a94e9/civicrm_entity.module)
In civicrm_entity.module, function civicrm_entity_action_create_user:
```
case 'nick.middle.last':
if (!empty($contact['middle_name'])) {
$params['name'] = _civicrm_entity_clean_login_name(trim($contact['nick_name']) . "." . trim($contact['middle_name']) . "." . trim($contact['last_name']));
} else {
$params['name'] = _civicrm_entity_clean_login_name(trim($contact['nick_name']) . "." . trim($contact['last_name']));
}
break;
case 'nick.middlelast':
if (!empty($contact['middle_name'])) {
$params['name'] = _civicrm_entity_clean_login_name(trim($contact['nick_name']) . "." . trim($contact['middle_name']) . trim($contact['last_name']));
} else {
$params['name'] = _civicrm_entity_clean_login_name(trim($contact['nick_name']) . "." . trim($contact['last_name']));
}
break;
```
An adapted file has been attached.https://lab.civicrm.org/dev/drupal/-/issues/93Create access role for importing memberships2019-11-04T08:53:10ZedvanleeuwenCreate access role for importing membershipsAt the moment, there is an access role to import contacts, but not for memberships. The latter shows up in the menu of users who are not allowed to import contacts.
It would be better to have a separate role for this or to attach this a...At the moment, there is an access role to import contacts, but not for memberships. The latter shows up in the menu of users who are not allowed to import contacts.
It would be better to have a separate role for this or to attach this access to the contact import role.