- 16 Apr, 2020 2 commits
-
-
Mathieu Lu authored
Replace deprecated drupal_set_message
-
demeritcowboy authored
-
- 02 Mar, 2020 1 commit
-
-
Eileen McNaughton authored
dev/drupal#4 - Switch automatic installation to use the civicrm-setup API
-
- 28 Feb, 2020 1 commit
-
-
Mathieu Lu authored
dev/drupal#107 - Fix user<=>contact sync used by installation workflow
-
- 26 Feb, 2020 3 commits
- 25 Feb, 2020 1 commit
-
-
Tim Otten authored
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).
-
- 31 Jan, 2020 1 commit
-
-
Mathieu Lu authored
dev/drupal#39 Remove Drupal Views integration.
-
- 29 Jan, 2020 2 commits
-
-
Mathieu Lu authored
dev/core#183 civicrm_requirements() - Use classloader like civicrm_install()
-
Mathieu Lutfy authored
-
- 11 Nov, 2019 2 commits
-
-
Tim Otten authored
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."
-
Tim Otten authored
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.)
-
- 07 Nov, 2019 2 commits
-
-
Tim Otten authored
Update copyright for 2020
-
Seamus Lee authored
-
- 29 Oct, 2019 4 commits
-
-
Mathieu Lu authored
Add CiviCRM icon to Toolbar
-
Michael O'Toole authored
-
Michael O'Toole authored
-
Michael O'Toole authored
-
- 24 Sep, 2019 1 commit
-
-
Mathieu Lu authored
Update the README.md (status, MIH, contributing)
-
- 18 Sep, 2019 2 commits
-
-
Mathieu Lutfy authored
-
Joris Vercammen authored
* 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.
-
- 23 Aug, 2019 1 commit
-
-
Eileen McNaughton authored
dev/drupal#83 Disable qf key validation for forms interact with CMS
-
- 21 Aug, 2019 3 commits
-
-
Eileen McNaughton authored
civicrm.user.inc - Fix crash when creating user via drush CLI
-
Eileen McNaughton authored
Migrate CivicrmHelper::parseUrl() to CRM_Utils_System_Drupal8::parseUrl()
-
Sunil Pawar authored
-
- 02 Jul, 2019 1 commit
-
-
Tim Otten authored
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.
-
- 28 Jun, 2019 1 commit
-
-
Tim Otten authored
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.
-
- 22 Mar, 2019 2 commits
-
-
colemanw authored
Update README.md to remove out-dated information and refer to Composer project & plugin
-
David Snopek authored
-
- 11 Dec, 2018 1 commit
-
-
Monish Deb authored
Add tray for improved menubar integration
-
- 30 Nov, 2018 1 commit
-
-
colemanw authored
-
- 29 Nov, 2018 1 commit
-
-
Mathieu Lu authored
Fix logout on user create
-
- 27 Nov, 2018 1 commit
-
-
Monish Deb authored
Add core resources before rendering content
-
- 26 Nov, 2018 1 commit
-
-
colemanw authored
The other 4 CMSs all behave this way, so this change is for consistency.
-
- 31 Oct, 2018 1 commit
-
-
Wannes De Roy authored
Call the synchronizeUFMatch directly instead of the synchronize method. Thus avoiding the session reset of the current user.
-
- 30 Oct, 2018 1 commit
-
-
Wannes De Roy authored
Current user get's logged out when creating a Drupal account for a CiviCRM contact.
-
- 13 Sep, 2018 1 commit
-
-
Eileen McNaughton authored
Use any version of CiviCRM, greater than 5.4.0
-
- 03 Sep, 2018 1 commit
-
-
Wouter H authored
So we can install CiviCRM & Drupal 8 via composer.
-
- 30 Aug, 2018 1 commit
-
-
colemanw authored
Improve readability of the breadcrumb builder
-