Drupal issueshttps://lab.civicrm.org/dev/drupal/-/issues2022-11-18T15:01:20Zhttps://lab.civicrm.org/dev/drupal/-/issues/180Naming: Drupal "8" references are anachronistic on Drupal 9/102022-11-18T15:01:20ZtottenNaming: Drupal "8" references are anachronistic on Drupal 9/10If you install CiviCRM-Drupal on D9/D10, some of the technical-names have anachronistic references to D8, eg
* The git repo name (`civicrm-drupal-8.git`)
* The composer package name (`civicrm/civicrm-drupal-8`)
* The UF name (`Drupal8`)...If you install CiviCRM-Drupal on D9/D10, some of the technical-names have anachronistic references to D8, eg
* The git repo name (`civicrm-drupal-8.git`)
* The composer package name (`civicrm/civicrm-drupal-8`)
* The UF name (`Drupal8`)
* Any classes based on the UF name (`CRM_Utils_System_{$UF}`, `CRM_Utils_Hook_{$UF}`, `CRM_Core_Permission_{$UF}`)
This is an off-shoot from discussion with @AlanDixon on https://lab.civicrm.org/dev/drupal/-/issues/178#note_74093https://lab.civicrm.org/dev/drupal/-/issues/9Problem: Easily allow 'vendor' directory not under the webroot2020-09-30T12:35:40ZtottenProblem: Easily allow 'vendor' directory not under the webrootThis is currently possible, but requires some patches and a build process.
**Here's the patches and process currently used by myDropWizard for Roundearth.io:**
*Patches:*
1. Find CKEditor relative to the resource URL: https://github.c...This is currently possible, but requires some patches and a build process.
**Here's the patches and process currently used by myDropWizard for Roundearth.io:**
*Patches:*
1. Find CKEditor relative to the resource URL: https://github.com/mydropwizard/civicrm-core/commit/9fc3877e2eb14e2829b530445c5e5491afc4bbe
2. Look for vendor directory above web root: https://github.com/mydropwizard/civicrm-core/commit/f57954392f8026d17b7f19f7c01ceeb65e703384
Both of those could probably be merged upstream?
*Process:*
1. Build process to copy web assets to `WEBROOT/libraries/civicrm` so they are web accessible. Here's the version from [roundearth's build process](https://gitlab.com/mydropwizard/roundearth-drops-8/blob/master/rebuild.sh#L74):
```
# Copy CiviCRM assets
asset_source=./vendor/civicrm/civicrm-core
asset_dest=./web/libraries/civicrm
mkdir -p $asset_dest
rsync -mr --include='*.'{html,js,css,svg,png,jpg,jpeg,ico,gif,woff,woff2,ttf,eot} --include='*/' --exclude='*' $asset_source/ $asset_dest/
rm -rf $asset_dest/tests
cp -r $asset_source/extern $asset_dest/
cp $asset_source/civicrm.config.php $asset_dest/
cat << EOF > $asset_dest/settings_location.php
<?php
define('CIVICRM_CONFDIR', '../../../sites');
EOF
```
2. Set the "Resource URL" to `[cms.root]/libraries/civicrm/`
**Getting support for this upstream:**
1. I think the patches might be good to just commit upstream? They don't seem controversial
2. The build process could be put in a PHP class in civicrm-corm which could be referred to as a script in a sites composer.json
3. We should be able to detect that we're using the vendor outside the webroot - could we somehow make the necessary "Resource URL" the default?5.5.0https://lab.civicrm.org/dev/drupal/-/issues/8Problem: How to address Bower dependencies installable via `composer`2020-07-16T17:23:37ZtottenProblem: How to address Bower dependencies installable via `composer`D8 General Availabilityhttps://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 Availability