GitLab

Replace deprecated drupal_set_message

dev/drupal#4 - Switch automatic installation to use the civicrm-setup API

dev/drupal#107 - Fix user<=>contact sync used by installation workflow

Overview
--------

This fixes a bug which primarily manifests for the administration during a new Civi-D8 installation.

See: https://lab.civicrm.org/dev/drupal/issues/107

Before
------

Two ways to look at this:

(A) Main symptom - After enabling CiviCRM on D8, you navigate to the CiviCRM dashboard and get a weird error like:

> Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing
> DB Constraint Violation - contact_id should possibly be marked as mandatory for DashboardContact,create API. If so, please raise a bug report.

(B) Formal description - If (for whatever reason) a D8 user is not linked to a Civi contact, then any attempt to work with the active user/contact will fail.

After
-----

(A) Main symptom - After enabling CiviCRM on D8, you can start using CiviCRM.

(B) Formal description - If (for whatever reason) a D8 user is not linked to a Civi contact, and if they try to use a `civicrm` page, then a
contact will be created and linked.

Technical Details
-----------------

This same technique has been active in Civi-D7 for years.

The code for this technique was present in Civi-D8, but it had some comments indicating that its significance wasn't understood at the
time of porting, and it was run at the wrong time (i.e. *after* the page-execution).

dev/drupal#39 Remove Drupal Views integration.

dev/core#183 civicrm_requirements() - Use classloader like civicrm_install()

The proximate aim is to support the previous commit and 15796, though this
is counter-intuitive.  The previous commit doesn't actually change the requirements.
But the upstream 15796 would.

This is the closest (imperfect) approximation we have in the current
structure to saying, "This version of civicrm-core and civicrm-drupal-8 go
together."

Overview
--------

This is an off-shoot of https://github.com/civicrm/civicrm-core/pull/15796
inspired by https://lab.civicrm.org/dev/core/issues/183.  In 15796, the
`Civi\Install\Requirements` class would be updated to use another helper
class.  This relies on autoloading, and that currently fails in D8.

Before
------

* `civicrm_install()` locates Civi code (`ClassLoader.php`) and sets it up
* `civicrm_requirements()` locates Civi code (`ClassLoader.php`) and manually
  loads a specific class file.

After
-----

* `civicrm_install()` and `civicrm_requirements()` use the same process
  to locate Civi code (`ClassLoader.php`) and initialize the classloader.

Comments
--------

I have one reservation here - the edge-case in which someone has tweaked out
`civicrm.settings.php` with a non-default value of `$civicrm_root` (i.e.
wherein `$civicrm_root !== _civicrm_find_civicrm()`).  Such a scenario may
become more prone to duplicate-class-definition errors if
`hook_requirements` runs in a pageview where CiviCRM is initialized.

Some possible resolutions are:

* Do nothing else. The edge-case may not even be real for any D8 sites.
* Further refactor so:
    * In pre-install environments, `civicrm_install()` and `civicrm_requirements()`
      use the same process -- calling `_civicrm_find_civicrm()` and loading the classloader
    * In post-install environments, `civicrm_requirements()` and `\Civicrm::initialize()`
      use the same process -- loading `civicrm.settings.php` and `CRM/Core/ClassLoader.php`.

(NOTE: I personally don't care about 15796 enough to do the second anytime
soon -- I'd be just as happy letting it wait.  But since I put a bit of time
into testing 15796, it seemed prudent to share this iteration.)

Update copyright for 2020

Add CiviCRM icon to Toolbar

Update the README.md (status, MIH, contributing)

* Refactor determineActiveTheme to be easier to grok
* Update CivicrmThemeNegotiator.php

Fix the admin theme check: return the admin theme if it's not a public theme.

dev/drupal#83 Disable qf key validation for forms interact with CMS

civicrm.user.inc - Fix crash when creating user via drush CLI

Migrate CivicrmHelper::parseUrl() to CRM_Utils_System_Drupal8::parseUrl()

For test/triage/demo sites, we must generate a couple user accounts via drush CLI, e.g.

```
cv core:install --cms-base-url="$CMS_URL" --plugin-path ~/src/d8plg -f
drush8 en civicrm
drush8 -y user-create --password="$DEMO_PASS" --mail="$DEMO_EMAIL" "$DEMO_USER"
```

This addresses a crash.

Before
------

The `user-create` step crashes while handling `civicrm_user_insert()`.
Specifically, the call to `\CRM_Core_BAO_UFGroup::getEditHTML()` fails
because the D8 CLI environment doesn't have an active session.

After
-----

`civicrm_user_insert()` only calls `UFGroup::getEditHTML()` if it's
likely the user-insertion occured on a relevant web-form.

Technical Details
-----------------

The technique is ported from the CiviCRM-D7 module. In particular,
`civicrm_on_user_page()` is copied verbatim; and in both cases,
`civicrm_user_insert()` calls `civicrm_on_user_page()` to decide whether
`getEditHTML()` will run.

The overall call-path in the D7 module is *slightly* different.

* D7: `civicrm_user_insert()` => `civicrm_register_data()` => `getEditHTML()`
* D8: `civicrm_user_insert()` => `getEditHTML()`)

... but the substance of the test is similar.

This fixes a bug which manifests during CLI installation. It corrects a dependency issue.

Before
------

Consider this sequence from `cv core:install` docs. (For simplicity/legibility, the example
is minimalist.)

```
$ cv core:install --cms-base-url=http://example.com/
$ drush -y en civicrm
```

Towards the end of the `core:install` step, it rebuilds the menu and winds
up calling some `url()` functions.  But that crashes on running
`CivicrmHelper::parseUrl()` -- because `CivicrmHelper` lives under the
`civicrm-drupal` module, and Drupal hasn't brought the module online yet.

After
-----

That crash does not happen.

Technical Details
-----------------

You might wonder: Will this be a flip-floppy problem?  Perhaps there's some
dataflow through `drupal/core => civicrm-drupal/src/Routing/Routes.php`
where the new call to `CRM_Core_Config::singleton()->userSystem->parseUrl()`
cannot be processed because `civicrm-core` isn't available yet?

This hypothetical can be dispensed by reading `src/Routing/Routes.php`.  The
function already begins with `\Drupal::service('civicrm')->initialize();`,
which boots all the core Civi services (like
`CRM_Core_Config::singleton()->userSystem`).  The system is already online
before the relevant code is called.

Update README.md to remove out-dated information and refer to Composer project & plugin

Add tray for improved menubar integration

Fix logout on user create

Add core resources before rendering content

The other 4 CMSs all behave this way, so this change is for consistency.

Call the synchronizeUFMatch directly instead of the synchronize method. Thus avoiding the session reset of the current user.

Current user get's logged out when creating a Drupal account for a CiviCRM contact.

 Use any version of CiviCRM, greater than 5.4.0

So we can install CiviCRM & Drupal 8 via composer.

Improve readability of the breadcrumb builder