Drupal issueshttps://lab.civicrm.org/dev/drupal/-/issues2023-02-08T16:48:07Zhttps://lab.civicrm.org/dev/drupal/-/issues/11Cleanup unnecessary files when running composer in D8 conext2023-02-08T16:48:07ZseamusleeCleanup unnecessary files when running composer in D8 conextCiviCRM's `composer.json` delegates to a post-install script to remove unnecessary and potentially dangerous files (e.g. demo scripts that shouldn't in the public web root). When adding civicrm to composer in Drupal 8, the post-install s...CiviCRM's `composer.json` delegates to a post-install script to remove unnecessary and potentially dangerous files (e.g. demo scripts that shouldn't in the public web root). When adding civicrm to composer in Drupal 8, the post-install scripts do not run automatically (ie `composer.json` does not recursively invoke post-install scripts). Therefore, we may be left dangerous content.D8 General Availabilityhttps://lab.civicrm.org/dev/drupal/-/issues/174Change message so it doesn't say Drupal8 on Drupal9 site2022-09-20T22:27:16ZJoeMurrayChange message so it doesn't say Drupal8 on Drupal9 siteThere was a message today on page for Synchronize Users to Contacts (/civicrm/admin/synchuser:
Synchronize Drupal8 Users
This was on a Drupal9 site, and the client got concerned about what they were running.
Please adjust the message s...There was a message today on page for Synchronize Users to Contacts (/civicrm/admin/synchuser:
Synchronize Drupal8 Users
This was on a Drupal9 site, and the client got concerned about what they were running.
Please adjust the message so that it either refers to just Drupal or ideally emits the correct major version of Drupal, eg Drupal9, Drupal10, etc.5.55.0Monish DebMonish Debhttps://lab.civicrm.org/dev/drupal/-/issues/171Drupal 10 requires Guzzle 72022-07-10T15:27:07ZDaveDDrupal 10 requires Guzzle 7It doesn't seem like there is any major change but I'm not super-familiar with everywhere civi uses guzzle: https://github.com/guzzle/guzzle/blob/master/UPGRADING.md#other-backwards-compatibility-breaking-changes
The main thing at the m...It doesn't seem like there is any major change but I'm not super-familiar with everywhere civi uses guzzle: https://github.com/guzzle/guzzle/blob/master/UPGRADING.md#other-backwards-compatibility-breaking-changes
The main thing at the moment is you need to do something like `composer require guzzlehttp/guzzle:"6.3.0 as 7.4.0"` just to get the civi files downloaded, but that's obviously not the right thing to do.5.52.0https://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/7Problem: How to address `civicrm.config.php` without running `GenCode`2020-10-01T00:47:38ZtottenProblem: How to address `civicrm.config.php` without running `GenCode`We aim to allow installing CiviCRM on Drupal 8 via composer/git _without_ requiring the admin to run `GenCode`.
The file `civicrm.config.php` is currently produced by `GenCode`, and it's required by various backend scripts (`extern/*` a...We aim to allow installing CiviCRM on Drupal 8 via composer/git _without_ requiring the admin to run `GenCode`.
The file `civicrm.config.php` is currently produced by `GenCode`, and it's required by various backend scripts (`extern/*` and `bin/*`). A naive approach might be to simply commit this file -- however, that's problematic because there are ~4 variants of this file (for `civicrm-drupal`, `civicrm-wordpress`, `civicrm-joomla`, and `civicrm-backdrop`).
There are a couple ways we might do this:
* (a) Audit each entry-point (`extern/*`, `bin/*`). For each, figure out some alternative way to address it without needing `civicrm.config.php`.
* __Challenge__: There are several entry-points, and each will likely have its own series of issues/patches. In this approach, it's hard to control the scope of work.
* (b) Import the universal CMS boot script from `cv.git` or `civicrm-wordpress.git` to `civicrm-core.git` (related: #5). All backend scripts (`extern/*`, `bin/*`) should use a fallback-behavior. (*"If `civicrm.config.php` exists, call it. Otherwise, call the universal boot script."*)
* __Challenge__: People like to do funny things with their builds, and there's no fixed spec for "all possible builds". A "universal" CMS boot script will probably be broken for someone.
* (c) `composer.json` integration -- for anyone installing Civi via `composer`, tell them to put some extra script calls in their root `composer.json`. The script creates `civicrm.config.php`.
* __Challenge__: This makes the installation experience more complicated.
* (d) Update all backend scripts (`extern/*`, `bin/*`) to use a fallback-behavior. (*"If `./drupal/civicrm.config.php.drupal` exists, call it. If `../civicrm.config.php.wordpress` exists, call it. Ad nauseum."*)
* __Challenge__: People like to do funny things with their builds, and there's no fixed spec for "all possible builds". A "universal" CMS boot script will probably be broken for someone.D8 General Availabilityhttps://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/21Drupal8: CiviCRM menu does not use the correct locale2020-07-16T17:23:38ZbgmDrupal8: CiviCRM menu does not use the correct localeHow to reproduce:
* Create a bilingual Drupal site, with the locale module
* Setup CiviCRM as multilingual, bilingual, using URL prefix language detection (example.org/fr/civicrm)
Result: the menu is always in the default CiviCRM langu...How to reproduce:
* Create a bilingual Drupal site, with the locale module
* Setup CiviCRM as multilingual, bilingual, using URL prefix language detection (example.org/fr/civicrm)
Result: the menu is always in the default CiviCRM language (or default Drupal language?).
Debugging the issue, in Drupal, the menu JS would be called this way:
`https://example.org/en/civicrm/ajax/menujs/2/en_US/1/5H7zVVcT`
However in D8 it is being called without the language prefix:
`https://example.org/civicrm/ajax/menujs/2/en_US/1/5H7zVVcT`
I suspect it is related to `CRM_Utils_System::languageNegotiationURL()`, which seems to test for the `locale` module.
cc @JoeMurray @monish.deb5.16.2