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.
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.
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.
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.
Drupal Views is a great way of exposing data to users via a search interface. This can be done directly via the database or via a Solr server. Plenty of Views plugins exist to allow reacting to the search input and output in a variety of different ways.
The other day I needed to add a personalised message to Views output to inform a user that their search keyword didn't find any results. There is a plugin for Views that allows this, but it only shows a basic search string.
Upon a recommendation from someone in my local Drupal user group I decided to give Tailwind CSS a go. The ultimate aim of this was to replace the base theme I am using here with a more stripped down theme. At the time of writing this I am using the Cog theme, and whilst it has it's merits, I find that it's a little too much for this simple site.
I decided, therefore, to create a new theme and use Tailwind CSS to alter the site a little. This meant an exercise in integrating Tailwind CSS into a Drupal theme.
Whilst searching for an answer to a problem the other day I found a comment that details a command that prints out all of the FieldWidgets available in Drupal 8. This is useful if you are looking for all of the field widget classes in Drupal8.
Here is the command:
I perform a lot of Drupal updates, and they mostly go very well. The code updates without incident and the database updates apply whatever updates they need without a hitch. Every now and then, however, I will come across a project that hasn't received updates in a while, which means there are a lot of database updates to run through.
Having Drupal run 100+ database updates across modules and core can be a bit problematic. Some modules will require core updates to happen first, and when this happens out of order the database update update fails spectacularly.
Drupal's hook system allows modules to interact with various parts of a Drupal application and is part of the power of the application.
One common issue I have found is altering things that have been added by other modules during the hooks process. For example, a hook might be called that involves gathering data from one or more modules. If you need to intercept this configuration there is no guarantee that your module will be called after the module you are trying to intercept.