Drupal

I like working with DrupalVM and I've worked with Ansible based Vagrant setups for years and so I'm very familiar with it's setup. More than that, I find I have very few problems with running it. I normally run it with Vagrant, but you can run it with Docker if you like.

When starting a new site project I normally add DrupalVM to the codebase so that I can get the site up and running quickly. This is especially useful if something like Solr is involved as setting that up is a pain. I thought I would go through the steps involved in adding DrupalVM to your codebase as it's pretty simple and will get you up and running with a Drupal site in about 10 minutes.

Start out with a Drupal site in a composer setup. I normally run the Drupal recommended composer setup file so that I have a up to date Drupal codebase, so let's do that here.

I've been using composer with Drupal for a few years now and I've picked up a few things along the way that have really helped me out. Following on from my post about the anatomy of the recommended Drupal 9 composer file I thought it would be good to expand on that to present some tips.

Here are 7 tips that will help you out when using composer with Drupal.

Automatic Patches With Composer

One of the most useful things I have found is using composer to manage patches to projects. This is possible using a project called composer-patches. You can require this into your project like this.

According to the official Drupal documentation, to create a new site using composer you should use a composer template project called drupal/recommended-project. This has a default composer.json file setup with some values that will help you get up and running swiftly with a new Drupal project.

It's a good initiative to get you up and running with a standard Drupal site pretty quickly. I've used this composer project a number of times now, but I haven't really looked at what's in it. I thought I would dive in and see exactly that's in there and dissect it line by line.

To reiterate what's in the Drupal documentation, to create a brand new Drupal project using composer use the following command.

I recently needed to add functionality to the Password Policy module so I thought I would outline the steps I took in a blog post. The Password Policy module is used to enforce a stricter password policy on users on a Drupal site. This means that when a user creates or changes their password they must conform to certain rules like the password length, or if it contains upper and lower case characters. There are a set of rules to chose from and they can be fully customised by the site administrators. It's a good module, you should check it out.

One gotcha when importing configuration to a Drupal site can be a message that tells you that the configuration you are trying to import is from another site.

Here is the error that can be seen on the Configuration Synchronize page.

The staged configuration cannot be imported, because it originates from a different site than this site. You can only synchronize configuration between cloned instances of this site.

This error happens because the UUID of the site (in the database) is different to that in the configuration (in the code). The UUID in the code is stored in the configuration file system.site.yml. The reason for this check is to ensure that your don't destroy your Drupal site by installing configuration that was created from another site.

Installing a Drupal site from configuration is useful when running tests or if you don't have a copy of the database. You'll get a copy of the Drupal site without any content that will act in the same way as the live site. You can use modules like default content to add content into the mix so your newly installed site acts a little bit more like the live version.

Since there are some prerequisites to get this up and running I thought I would run through what is needed to get this working and how to run it.

A change that was snuck into Drupal version 8.8.0 and wasn't mentioned in the 8.8.0 change notes was a small change to the setting that controls the placement of the configuration directories. The alteration deprecated the $config_directories setting from the settings.php file and move the configuration into the $settings array. You can see the detail behind this change on the Drupal change record.

The fix for this is very easy and only needs a single line of code to change in your settings file.

Change this:

$config_directories['sync'] = '../config/sync';

To this:

Spam is a constant problem for any site on the internet that has a publicly available form, but automatically preventing spam can be tricky. The idea is to prevent the automated spam bot from being able to submit data to your site, but not at the detriment of the users. There is a careful balance between preventing spam and prevent real content being submitted by real users. Manually moderating blog comments is usually a good idea, but many websites contain contact forms and user registration forms that are often targeted by spam bots.

Whilst Drupal does have a number of protections against cross site submissions or denial of service attacks and even has build in user and comment moderation. It does, however, need a little bit of help with preventing spam.

Drupal has a number of modules to deal with automated spam and they fall mainly into a number of different categories.

Continuing my review of some Drupal PaaS hosting platforms I am taking a look at Dropsolid.

What I'm not doing is a massive deep dive on all platforms. Ultimately, your milage will vary and what you get out of these platforms will be different for most people. You will know the requirements of your project and what you need to accomplish.

Also, if you want to know more about a platform, then please contact them directly. I'm sure they will be happy to hear from you.

Based in Gent, Belgium, Dropsolid is a Drupal development agency who have built a Drupal hosting platform. The Dropsolid Experience Cloud is a platform built from years of experience in hosting and maintaining Drupal.

I met a few of the team at DrupalCamp London 2020 and they were kind enough to supply me with a key to evaluate the platform.

Continuing my review of some Drupal PaaS hosting platforms I am taking a look at Platform.sh.

What I'm not doing is a massive deep dive on all platforms. Ultimately, your milage will vary and what you get out of these platforms will be different for most people. You will know the requirements of your project and what you need to accomplish.

Also, if you want to know more about a platform, then please contact them directly. I'm sure they will be happy to hear from you.

Platform.sh is a PaaS site created by Commerce Guys, who are the main driving force being the Drupal Commerce suite of modules. They split off in 2016 and have grown to become a very respectable company in the PaaS space. They have also expanded their service to support a lot more than Drupal so you can easily deploy your Drupal and WordPress sites side by side.