Ever feel annoyed by .htaccess files showing up in your Drupal project, only to realize that Nginx (or IIS, or any non-Apache server) ignores them? I know I do.

Those files aren't empty stubs—they pack all the usual Drupal rules (security guards, PHP-execution blocks, directory-listing bans, etc.). Great for Apache, but total clutter elsewhere—and sometimes they even throw obscure errors during deploys or status checks.

Good news! 

As of Drupal 11.3.0, you can stop that auto-creation in its tracks. Just add this to your settings.php:

$settings['auto_create_htaccess'] = FALSE;

Now Drupal won't drop .htaccess files where you don't need them. Your repo stays clean, your CI logs stay quiet, and you'll never chase random htaccess warnings again.

If your Nginx (or IIS) config was already handling script blocking, directory-listing prevention and any custom rewrites, you're all set—nothing else changes. If you haven't locked down those directories yet, take a quick look at Drupal's filesystem security guide before flipping the switch.

And let's be honest: this issue was first opened in 2009—and only now, in 2025, has it finally been resolved. It's wildly frustrating to see core development move at such a glacial pace, waiting years for what should have been a simple toggle.

That's it—non-Apache devs, rejoice! Flip the switch, keep your codebase tidy, and let your web server handle what it does best.

Drupal is unifying its backend appearance by replacing the long-standing Claro admin theme with the fully matured Gin theme for all new sites.

This change takes effect in Drupal 11.3, slated for release in December 2025, at which point Gin will become the default admin theme in core.

Thanks to Gin's modular architecture and flexible component system, site builders gain a refined toolbar, improved typography, and higher-contrast form elements out of the box—all designed for clarity and accessibility.

Claro vs Gin theme - "Content overview page" look and feel:

Claro vs Gin theme - "Add content page" look and feel:

Existing Drupal 11 sites will continue to include Claro for backward compatibility, but all new installations from 11.3 onward will load Gin by default, ensuring a consistent, modern admin experience.

This update is officially announced on Drupal.org: Drupal core will adopt Gin admin theme to replace Claro

Bonus Note: Gin Login Module

You might not have heard of this, I sure didn't until recently, but the Gin Login contrib module brings Gin's sleek styling to your site's login page. It offers custom branding options and responsive layouts, so your very first interaction with Drupal feels as polished as the admin itself.

Two months ago, I installed Drupal CMS for the first time when it was released. Since then, I haven't done any testing or made any changes. Today, I decided to try updating the Drupal core using the CMS interface.

I was running Drupal core version 11.1.1, while the latest available version is 11.1.4. To start the update, I went to /admin/reports/updates/update and saw the button Upgrade to 11.1.4.

Because I was testing on a local project, I didn't create any backups of either the code or the database. However, if you're doing this on a live site, be sure to follow the recommended instructions and create backups first.

After clicking the blue button, a batch process started, performing the necessary operations to update Drupal to the latest version.

Once the batch process finished, I had to click through a few more prompts to complete the core update and update the database. That was it—Drupal was updated without any issues.

When I checked my Git status, I noticed that the update process changed the Composer files, ensuring everything is accounted for. You just need to commit these changes to your repository, and you're good to go.

I'm very satisfied that everything worked smoothly. This functionality is a huge help—maybe not for hardcore developers, but for site builders and site owners who might not be deeply familiar with Drupal coding.

I ran this update manually, but Drupal also supports doing it automatically in the background without any user interaction.

That's something I plan to test in the future as well. 

Important things to keep in mind:

• This module (Automatic Updates) only updates Drupal core, not contributed modules.
• For this module to work, Drupal must modify its code, but many managed hosting platforms, like Acquia and Pantheon, don't allow this; instead, use Automatic Updates locally and push changes to the host.
• If you want to update contrib modules as well, you need to enable the submodule called Automatic Updates Extensions. Then, go to the following page: /admin/reports/updates/automatic-update-extensions and update the modules manually. This will also modify your composer files, so you will need to commit the changes to the repository.

That's a wrap—stay tuned for more Drupal experiences and insights coming soon!

I just tried the new Drupal CMS released today. While I probably won't be using it much myself, I have to say it feels much nicer and far more beginner-friendly compared to Drupal Core.

First impressions:

• The dashboard is clean and easy to navigate.
• The sidebar menu is well-organized and intuitive.

Project Browser: The last time I tried this feature, it didn't work for me, but that's no longer the case! I tested installing the Entity API module, and it worked flawlessly. The module installed seamlessly and was properly added to the composer.json file.

Unlike Drupal Core, which only includes two default content types, Article and Basic page, Drupal CMS comes with a wider selection of predefined content types.

Automatic Updates: This module is now included and sounds like a game-changer for non-technical users. I haven't tested it yet, but I'm excited to give it a try soon!

Pre-installed modules: Drupal CMS comes packed with some useful modules. These include Scheduler, ECA, Captcha, Smart Date, Autosave Form, Linkit, and more. A solid foundation for anyone building a site with this version of Drupal!

Here is the complete list of all installed modules. I selected all available content types during the installation process!

add_content_by_bundle
address
addtocal_augment
automatic_updates
automatic_updates_extensions
autosave_form
better_exposed_filters
bpmn_io
captcha
coffee
crop
dashboard
date_augmenter
easy_breadcrumb
easy_email
easy_email_override
eca
eca_base
eca_config
eca_content
eca_misc
eca_modeller_bpmn
eca_render
eca_ui
eca_user
focal_point
friendlycaptcha
geocoder
geocoder_address
geocoder_field
geocoder_geofield
geofield
gin_toolbar
honeypot
jquery_ui
jquery_ui_resizable
klaro
leaflet
leaflet_views
linkit
login_emailusername
mailsystem
menu_link_attributes
package_manager
project_browser
redirect
redirect_404
sam
scheduler
scheduler_content_moderation_integration
smart_date
svg_image
symfony_mailer_lite
token
trash
eca_form
pathauto
selective_better_exposed_filters

AI Assistant: By default, the AI assistant is not installed, but it can be easily installed using the recipe called AI Assistant. Ensure you have an API key ready for OpenAI or Anthropic.

As a test for the AI assistant, I used an example where I add a field to the Blog Post content type that references a taxonomy called Categories. Let's see what creating this field looks like using the AI chatbot.

Overall, it's looking pretty great so far. I'm curious to see how it will be received by Drupal site builders with limited coding experience and those who have never used Drupal before. I hope this project will open doors for greater acceptance of Drupal.

Drupal 11.1 was released yesterday, and one of the most important things in this release is the addition of a new EntityReference filter for Views.

Before this version, if you wanted to add an exposed filter to an entity reference field — in my case, as shown in the image below, it's the field_related_articles field — the filter would be a simple text input field.

Now, it can be a select box or an autocomplete field, as shown in the second image.

What I don't like is that this filter isn't used by default; instead, you need to write a hook_views_data_alter() for that. In my example, it would look like this:

/**
* Implements hook_views_data_alter().
*/
function MY_MODULE_views_data_alter(array &$data): void {
  $field_name = 'field_related_articles';
  $data['node__' . $field_name][$field_name . '_target_id']['filter']['id'] = 'entity_reference';
}

Read more in the change record.

Taxonomy terms have been revisionable for quite some time now. If you take a look at the change records, you'll see that several years have passed since terms began supporting revisions.

The only issue was that Drupal core did not provide a User Interface (UI) for managing these revisions. However, this changes with the release of Drupal version 10.3, where a user interface for revision management has finally been introduced.

Change record: https://www.drupal.org/node/3396786

Drupal 10.3.0 is scheduled for release in the week of June 17, 2024.

It's not exactly a feature peak, but it is a new feature in Drupal that is still relatively unknown, so I'm writing about it.

Every time I created a social share image for my blog post in Canva, I had to change the file name after downloading to replace spaces with a middle dash, and convert uppercase letters to lowercase. However, starting with Drupal 10.2, this is no longer necessary. From this version onwards, there is an option for file name sanitization.

You can find this option on the following page: /admin/config/media/file-system.

The file name is changed during the file upload, either through the UI or via REST. For more information, please refer to the change record.

Starting with Drupal version 10.2, it will be possible to use PHP attributes instead of annotations for some plugins. Currently, this applies to Action and Block plugins. For more information, please see the following change record:

https://www.drupal.org/node/3395575

Let's take one of my modules, Facets Block, as an example. Here's how the block plugin would look with annotations and with attributes.

Before:

/**
 * Provides a 'Facets Block' block.
 *
 * @Block(
 *  id = "facets_block",
 *  admin_label = @Translation("Facets Block"),
 * )
 */
class FacetsBlock extends BlockBase implements ContainerFactoryPluginInterface {
  ...
  ...
}

After (Drupal 10.2+):

use Drupal\Core\Block\Attribute\Block;
use Drupal\Core\StringTranslation\TranslatableMarkup;

/**
 * Provides a 'Facets Block' block.
 */
#[Block(
  id: 'facets_block',
  admin_label: new TranslatableMarkup('Facets Block')
)]
class FacetsBlock extends BlockBase implements ContainerFactoryPluginInterface {
  ...
  ...
}

To make this work, don't forget to add the appropriate classes (Block and TranslatableMarkup) in the use section and to clear the cache.

Using PHP attributes, rather than annotations that are essentially PHP comments, for adding structured metadata to classes is more appealing to me. So, I definitely plan to use this in the future.

The Project Browser aims to simplify the process of finding and installing modules for both site builders and developers. You've got two options: First, you can use the browser to search for modules and see the necessary Composer and Drush commands for installation. Second, you can actually install modules directly using the UI.

Right now, the module is in beta, and the feature for installing via the UI is still experimental. I gave it a try and encountered some errors, so it seems we'll need to wait a bit longer for it to be fully reliable. That said, the Project Browser is already a handy tool for browsing modules. It's more user-friendly than drupal.org, thanks to improved search and filtering options.

This Project Browser is part of a larger effort to make Drupal more accessible, especially for those who are new to the platform.

In Drupal, adding fields via the UI can challenge both beginners and seasoned users. Thankfully, Drupal 10.2 is set to offer a more intuitive process with detailed explanations for each field type.

Drupal 9 vs Drupal 10.2 field creation:

This is part of a broader initiative to enhance the field creation experience. For more details, check out the following issue on Drupal: https://www.drupal.org/project/drupal/issues/3346539