Site spam is a thing that most Drupal developers have to deal with.
Privacy and terms of use policies seem to be in constant state-of-flux due to various legal jurisdictions often updating requirements for businesses that operate in their area. Keeping up with all the changes is challenging, to say the least.
If you've been a user of Visual Studio Code for your custom Drupal development, then you're probably (hopefully) familiar with this
If you use DDEV and PhpStorm, then the DDEV Integration plugin should definitely interest you (especially if you're into code quality tools like phpcs and PhpStan). If you don't use DDEV and PhpStorm, then the DDEV Integration plugin might entice you to take a fresh look...
Have you been in the situation where you've added a new field to a Drupal content type and you want that field to appear somewhere in the sidebar of the node add/edit page for that content type (instead of in the main column along with all the other fields)?
If you manage a Drupal site that has constantly changing content, you may have concerns about the size and contents of the /sites/default/files/ directory. For most Drupal site maintainers, this can often be a source of anxiety, not ever really knowing what it contains and what, if any of the uploaded files are obsolete.
This may be the quickest quicktip we've ever written - if your site doesn't require the "Request new password" functionality, the No Request New Password module makes it pretty easy to remove it.
Before:
If you're like most modern Drupal developers, you use the excellent Address module to collect country-aware address data on entities that require it. But, what do you do with the output of address data?
I like to think of this module as something you don't realize you need until you understand exactly what it does. With that in mind, let's start with an example…
After teaching folks how to use Composer effectively over the past couple of years, I figured it was time for me to (finally) update DrupalEasy.com to use Composer 2. I figured it would be a pretty easy process, and I was correct.
I've had a few people ask me about the process, so I thought I'd write up what it took to update this site to Composer 2. First a few facts about this codebase:
If you write custom Drupal 8 (or 9) modules, then you've probably used the entity QueryInterface - which is accessible from the Drupal::entityQuery() static method. If not, then you're missing out on this incredibly useful tool that allows you to easily query a Drupal site for entities of any kind.
When creating a Drupal 8 or 9 project using the drupal/recommended-project Composer template, you may notice during certain Composer commands that the scaffolding files are copied from an "assets" directory inside of Drupal's core directory to their proper place in the codebase.
The standard Drupal 8 block visibility page settings allow you to either include the listed paths (via "Show for all listed pages" or exclude the listed paths (via "Hide for all listed pages") - but you can never include and exclude at the same time. The Block Exclude Pages module provides a solution to this.
If you use the Drupal Composer Drupal Project template for managing your Drupal 8 site’s codebase, and you commit dependencies to your Git repository, then you’ve probably run into issues involving cloned dependencies. Sometimes when requiring a dependency via Composer, you end up with a cloned version (which includes a .git directory) instead of a release version.
I recently decided to begin rebuilding the various landing pages on DrupalEasy.com using Layout Builder, introduced as a stable module to Drupal 8.7 core. Prior to this, the various landing pages on the site had been built using Paragraphs module.
While I appreciate what Paragraphs module can do as a layout tools for individual entities, I learned the hard way that perhaps it isn't the best tool for the job of building landing pages.