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.
This problem came out of a recent project I was working on. I had to perform a bunch of API lookups on behalf of a user that could take a minute or so to complete. The results of the API lookups were cached and so once it was done the site would be very quick, unfortunately the initial API lookup slowed down the page load quite considerably so this created a problem.
Drupal's cache system is robust, feature full and extensible. It can be used to cache small blocks of rendered output or the results of more complex calculations. The cache can be stored in a for the page request, in a database or in a different cache system.
From the pages of 'crazy things you can do with Drupal 8' comes this idea that I recently had to implement on a site. This was on a site that had implemented translations, but they needed something a little extra. The central idea was that if you visited a page on the site in a particular language, and that language didn't exist, then to try and give the user a similar language.