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:
After:
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.
I often work on migrations that involved dates that need to be migrated into Drupal 8. While many times the dates are for entity created and updated dates, and therefore in Unix timestamp format, sometimes (when migrating events, for example), I'll need to migrate a date in some other format into Drupal's date field.
One of the pillars of the consulting side of the work we do here at DrupalEasy is data migration into Drupal sites. Over the past few years, we've been focused on migrating data into Drupal 8 using the most excellent core migrate modules along with contrib modules like Migrate Tools, Migrate Plus, and Migrate Source CSV.
Code flows up, data flows down.
I repeat this phrase in just about every workshop I teach - it is one of the basic principles of being a professional web developer. The idea is that we should be working locally, then pushing our changes (using Git) up to the project's dev, then QA, the live environments. As for the project's data (database and files directory for Drupal sites), the direction is opposite, we should only be moving data "down" - from live to QA, or live to dev, or live to local.
If you've adopted a Composer-based Drupal 8 workflow (hopefully using the Drupal Composer/Drupal Project template) where you're keeping dependencies in your project's repository, then you've no-doubt experienced the annoyance of a rogue .git directory ending up in one of your project's dependencies. This will always happen when you're using the -dev version of a Drupal module.
Drupal 8's text format system provides a way for developers to manage user generated content, regardless of if the user is trusted staff member or an anonymous commenter. With intelligent configuration of various text formats for the various roles on the site, the security and usefulness of a site can be maximized.