Joris De Groot
Business advisor & MP
Calibrate: Official CiviCRM partner
As a web agency it is important to be an expert in various fields of knowledge. Contact and member management (CRM) is also important to many of our customers. That is why we have chosen to become an official partner of CiviCRM, a powerful Open Source CRM system mainly intended for websites with active member operations. The system supports the member organisation in managing contacts, memberships and events and much more. Calibrate is the only web agency in Belgium that is an official empowering partner of CiviCRM.
What does this partnership entail?
A partnership with CiviCRM is more than just a financial contribution. Together with other partners, we support the growth and stability of the platform. We also contribute to the CiviCRM and Drupal Community on a regular basis with code contributions and sprints.
Dev Sprints by our Experts
On Friday 22/08/2018 our CiviCRM experts: Wouter Hechtermans (CiviCRM Lead), Joris Vercammen (Drupal Developer, Search API maintainer) and Wannes De Roy (Full Stack developer) again contributed to the CiviCRM and Drupal Community with a development sprint.
In preparation for a sprint, the objectives of the sprint are laid down during a planning meeting. The objectives of the last sprint were twofold: on the one hand, we wanted to update the Drupal 8 module, and on the other hand, we wanted to implement CiviCRM with Composer. Once the objectives had been determined, we started coding.
Objectives sprint on 22/08/2018
Objective 1: improvements to the CiviCRM Drupal 8 module:
- Project formats have been adapted to the current Drupal coding standards
- Code was commented on more clearly
- Overall performance improvements
Objective 2 - Implementing CiviCRM with Composer:
- Allows us to automate certain processes, thus saving time and making cooperation more efficient.
The points earned - Warning! Geek stuff ahead!
Improvements CiviCRM drupal 8 module
An overview of all submitted pull requests:
- Convert project to the Drupal Coding standards: read more.
- Use your own error message from the Drupal integration module. This makes it clearer where a possible error comes from: read more.
- Using Dependency Injection in the permission-builder class. This is a best-practice in drupal 8 modules and makes it easier to add tests later: read more.
- Remove file that was not used: read more.
- Check set so that only authenticated users are checked for according CiviCRM contact. This will improve performance for users who are not logged in: read more.
In the making (still to be tested & optimised):
- Makes it easy to understand the logic in the `ThemeNegotiator` by spreading the if-statements over different rules and using early returns to improve performance: read more.
- The same thing we did for the ThemeNegotatiator, but for the `CivicrmBreadcrumbBuilder': spread if-statement and use early returns: read more.
- Again the same approach, making it easier to understand the code by identifying it less deeply and adding early returns: read more.
Because this class has an important function, we have also added a Unit test to ensure that the behaviour is still working correctly. Unfortunately, these tests are not (yet) automated.
In order to do so, we must first succeed in installing CiviCRM in a simple way via composer.
This will make it easier to use [TravisCI], [CircleCI] or something else to perform them.
Delete _CiviCRM session for anonymous users (issue with varnish caching)_
When you visit a Drupal8 website with Varnish, Varnish caching works fine until you get to a public CiviCRM page, then a session is posted. When you leave the page by clicking another link, the session remains and Varnish can no longer be used to serve the pages.
We must therefore make sure that this CiviCRM session is removed when you leave the CiviCRM page. Our solution to this problem is a custom middleware service which, based on certain conditions, will clear this session after a user has been on a CiviCRM page.
Still to be done
- civicrm-drupal-8 module's version requirements for civicrm-core are still at 4.7.*. This should always be the latest stable version. Or a minimum of e.g. 5.4. Here is a pull request from https://github.com/civicrm/civicrm-drupal-8/pull/2 suggesting to use self.version. In this way the civicrm-core and the civicrm-drupal-8 versions would be the same.
Implementating CiviCRM & Composer
Below are the steps taken to add CiviCRM to Composer by Drupal.
For some packages we already use our own forks with certain fixes. Several fixes are already in pull-request but have not yet been implemented in the latest versions of the repositories.
- CiviCRM database: database created, started from sql file (clean install D7/ CiviCRM 5.4.0).
- Add CiviCRM to composer: via post script copy the packages to CiviCRM core folder. Via `cp-rf` the original civicrm-packages will remain and the composer will be informed of any changes.
- Libraries has 'type' & 'installer-name' in their composer.json this makes sure it gets into the Drupal libraries folder. By using these libraries the CiviCRM codebase in the vendor folder can be outside the webroot.
- CiviCRM Drupal 8 module: Adding the CiviCRM drupal 8 module to the composer.json via GIT repository.
- Carrying out patches
- Add CiviCRM extensions via composer.json
This would work if the CiviCRM extensions were available on packagist. And together composer installers and the type `civicrm-ext` it will go directly to the right folder that you can set yourself: read more.
