drupal

Join us as Andrei Mateescu demonstrates the Workspaces module's powerful capabilities for enterprise-level Drupal sites. Discover how the module allows preview and management of extensive content changes and integrates with core functionalities like translations and Layout Builder. Although currently labeled experimental, Workspaces is already in use in production environments and will become a stable part of Drupal Core.

Welcome, Drupal 11! At a previous DrupalCon Portland Drupal’s creator Dries Buytaert introduced the goal of making Drupal the preferred tool for ambitious site builders on the open web. Recently, Dries shared an updated plan for Drupal 11 which has 3 major focus areas:

Drupal 11 is early! But don’t panic, the new Drupal 10 support model means you are not under pressure to upgrade. Drupal 10 will continue to be supported until mid-late 2026. But as we know, it’s best to be prepared and understand the upgrade process when that time comes for your organization.

Similar to the upgrade from Drupal 9 to Drupal 10, the latest version of Drupal 10 - Drupal 10.3.1 - defined all the deprecated code for Drupal 11. Also like previous modern Drupal major version upgrades there is a recommended set of areas to focus in order to get your applications upgraded as cleanly as possible.

Shanice Ortiz

Director of Projects

Alongside her project management duties, Shanice is passionate about expanding Four Kitchens’ DEI efforts and fostering a culture of advocates and allies.

January 1, 1970

Platform upgrade.

For any IT manager, especially those at large organizations, these two words are enough to cause stress. Even if you just completed a move to Drupal 10, the release of Drupal 11 is around the corner with the latest version available in late July 2024.

What does that mean for your organization? Primarily, your greatest takeaway is that you shouldn’t feel the anxiety of another looming deadline. You still have two years to complete the upgrade. Plus, engineering plans are just starting to come together about how to tackle the upgrade multiple different ways. Time is still on your side.

However, just because a move to Drupal 11 isn’t cause for immediate alarm doesn’t mean you shouldn’t start planning an upgrade. You and your organization will see considerable benefits by addressing this change sooner rather than later.

What the move to Drupal 11 means for your website

In terms of adding new tools or website features, moving to Drupal 11 doesn’t mean much for your organization. Drupal rolls out upgrades differently than conventional software platforms. Version 11 will seem a lot like Drupal 10.3 in terms of new functionality.

Instead, Drupal will be deprecating features to eliminate ‌unnecessary or outdated code from the core platform. For example, in moving from Drupal 9.5 to 10, the CKEditor 4 module was removed to make room for CKEditor 5. For Drupal 11, the Book module will be deprecated.

If your organization doesn’t use this feature, its subtraction amounts to a positive by eliminating unneeded weight to the platform. If you do, then Book will still function in a more nimble way as a contrib module.

Ultimately, your organization won’t see any new features from Drupal 11 until the release of the next version, Drupal 11.1. Does that mean you should wait until then to start planning a website upgrade? You guessed it — absolutely not.

Why get ahead of Drupal 11?

The biggest benefit of planning your upgrade to Drupal 11 early is to avoid the scramble of a last-minute migration. This creates headaches for your team, and you also run into crowded schedules if you rely on a development partner. You don’t just run the risk of incurring unnecessary charges for trying to plan an upgrade at the last minute. You also risk limited availability as development agencies support other clients who also waited until the last minute.

Plus, planning to migrate to Drupal 11 now enables you to sidestep the complications of upgrading after 11.1 is released. Version 11.1 will include new features, and migrating across two versions will be more difficult, especially if you manage multiple websites.

Making the Drupal 11 move now gives you a leaner version of the platform while leaving you better positioned for 11.1. In all, your journey to Drupal 11.1 will be significantly faster and easier if you’ve already completed the migration to Drupal 11.

What stakeholders need to know about Drupal 11

As you plan an upgrade to Drupal 11, you need to keep your stakeholders informed about what to expect. Rather than getting bogged down with deprecations or other elements, you should frame the upgrade as a maintenance release.

In other words, the migration is primarily a way to improve your organization’s position going forward. Along with creating an easier path toward accessing the new features coming for 11.1, this update also will improve the performance and scalability of the platform for your websites.

How to plan a Drupal 11 migration

Drupal 11 will be released in late July. Consequently, your organization has a long runway toward completing an upgrade. In fact, you have two years until version 10 reaches its end of life in mid- to late 2026.

While that sounds like an eternity from now, your organization has more options at its disposal for planning an upgrade the sooner you begin. With enough lead time, you could include much of the work of preparing for Drupal 11 as part of a Continuous Care program with Four Kitchens.

Depending on your subscription tier, you can allocate your hours differently to support the upgrade. Alternatively, you can plan to allocate additional hours to your tier to complete the upgrade. Or, you can upgrade to Drupal 11 as part of a standalone project separate from your Continuous Care engagement.

The point, ultimately, is to underscore that you have options. At Four Kitchens, we’re already working on our upgrade plan to guide our clients through a seamless transition to Drupal 11. By considering the right approach for your organization sooner rather than later, you can ensure you still have options for navigating this upgrade in a timely, efficient way.

If you’re ready to start planning, we should talk.

The post Why time is of the essence for a Drupal 11 migration appeared first on Four Kitchens.

If you are enthusiastic about Best SEO Practices for Drupal Websites in 2024 and want to grow your website traffic, you are just in the right place! Drupal is like a wise friend on the web who helps you complete tasks quickly without understanding many programming details. Also, it has some cool tricks that make your website both Google-friendly and user-friendly. And here we go, deeper into optimizing your SEO for Drupal!

Drupal SEO Checklist in 2024

All right, let's make a rough Drupal SEO checklist.

Migrating content into Drupal is an extremely useful skill for most Drupal developers. Often, the most difficult step in learning to do migrations is the first one - that of getting everything set up and running your first migration to ensure that everything is working as expected.

Most Drupal migration-related blog posts and documentation that I've seen either completely ignore the setup process or gloss over it before diving into the details of writing migrations. I like to ensure, both here, and when working with participants in our Professional Module Development course, that we ensure a solid understanding of this process to build not only skills, but confidence.

This blog post will explain how to set up and run your first (very simple) Drupal migration. The process I will outline is actually the same steps I do when beginning to write a custom migration - just to make sure I have everything "hooked up" properly before I start getting into the more complex aspects of the project.

I generally write migrations on my local machine, using DDEV as the local development environment. 

Configuration migrations vs. Plugin migrations

When creating a custom migration, one of the initial decisions to be made is whether you'll write the migrations as plugins or configuration entities. I've always used configuration entities, but there are pros and cons to both approaches. Here, we will focus on configuration entity migrations.

There are some minor differences in the workflow presented below when using plugin migrations. For more information on the differences, I recommend Mauricio Dinarte's article. 

Core and contrib modules used

If you're planning on following along with this article, the following modules should be installed and enabled:

Drupal core: 

• Migrate
• Migrate Drupal

Contrib: 

• Migrate tools (for Drush commands) https://www.drupal.org/project/migrate_tools
• Migrate plus (migrations as configuration, additional process plugins, and more) https://www.drupal.org/project/migrate_plus

Source database

This blog post will demonstrate importing a small portion of user data from a Drupal 7 site into a Drupal 10 site. Normally, the first step is setting up the source data: in this case a Drupal 7 database. I normally create a new d7 database on the same MariaDB server as the Drupal 10 site (using DDEV, this is quite easy) and then import the Drupal 7 database into it.

Next, we have to tell the Drupal 10 site about the d7 source database. This can be done by adding the following database connection array to the bottom of your settings.local.php file (which I know you're using!):

Note the database key is migrate and the database name is d7. Everything else is identical to the regular Drupal 10 database credentials in DDEV. If you're using Lando or another local development environment, then your database connection array may be different. 

Custom migration module

Next, we need a custom module to house our migration. The easiest way to create one is via Drush's generate command:

Once created, go ahead and enable the module as well:

Migration group configuration

As this blog post will be writing migrations as configuration entities, create a new config/install directory in your new module. 

We'll define a migration group to which all of our migrations will belong - this is what connects each migration to the source d7 database. Create a new migrate_plus.migration_group.my_group.yml file in the new config/install directory with the following contents:

The most important bit of this configuration is the source key of migrate; this links up this migration group with the d7 database, with the migrate key we previously configured. Then, any migration created that is in this group automatically has access to the source d7 database.

Simple sample migration configuration

Next, let's look at a super simple example migration for user entities. This will not be a complete user migration, but rather just enough to migrate something. Many migration blog posts, documentation pages and other sources provide guidance and examples for writing migration configuration files (remember, this blog post is focused on all of the configuration and mechanics that normally aren't covered in other places.) 

Here's the user migration configuration we'll use. Create a new /config/install/migrate_plus.migration.user.yml file in your custom module with the following contents:

Reputable Drupal migration articles and documentation will explain that migrations need a source (extraction,) some processing (transform,) and a destination (where to load the data.) Often these three concepts will be called ETL. Each of these concepts are easy to spot in our sample configuration file:

• The data is coming from the d7_user plugin (provided by Drupal core with the data source being that of the my_d7_migration group which we configured in a previous step.) 
• The processing of the data in this simple migration is just field mapping (to: from.) Many migration configurations have transformations as part of this section, often provided by Drupal process plugins. 
• The destination is Drupal user entities. 

Running the migration

Again, these instructions are specific to Drupal migration configurations when created as configuration entities. Instructions for migration configuration written as plugins are slightly different (and not covered in this article.) 

As we are dealing with configuration entities, they must be imported into the active configuration store - which, by default, is the Drupal database. This is easily accomplished with the drush cim --partial command. This must be run each and every time a migration configuration file is modified. This is one of the (few, in my opinion) downsides of writing migrations as configurations. 

Next, I often check the status of migration via the drush migrate:status command. When using the Migrate Drupal module, it is recommended to always use the --group option otherwise the output of migrate:status can get a bit messy (due to all the default migrations that will be displayed.) 

The drush migrate:import and migrate:rollback commands should be self-explanatory. Each can be used with either the --group option or with a migration name (as shown below.) I almost always use the --update option on migrate:import for updating previously imported data. 

Finally, keep the drush migrate:reset command in your back pocket when writing custom migrations. If the migration crashes, you'll need to use this to reset its status from processing to idle in order to run it again. 

Here's a full set of the command specific to the sample user migration, migration group, and custom module created in this article:

What's next?

What I've presented in this article is 90% of what I regularly use when running migrations. Sure, there are a few edge cases where oddities occur, but I believe this is a solid base of knowledge to start with. 

Once all this makes sense, I encourage you to utilize other blog posts and documentation to extend the user migration we started, or write new ones based on other resources. Once you're comfortable writing additional migrations, learning how to create your own process plugins is the natural next step. As process plugins are written as PHP classes, some knowledge of module development is necessary. 

Interested in learning more about Drupal module development? Check out DrupalEasy's 15-week Professional Module Development course! 

Additional resources

• UnderstandDrupal.com - loads of resources about Drupal migrations from Mauricio Dinarte. 
• Tag1's recent series about migrations (also written by Mauricio Dinarte!): 
• Migration related modules (definitely not an exhaustive list, but a solid start):
  • Migrate plus 
  • Migrate tools 
  • Migrate devel 
  • Migrate process extra - process plugins for migrations.
  • Migrate conditions - additional process plugins for migrations.
  • Migrate source CSV - allows migrations from .csv files.
  • Migration tools - even more process plugins and additional helper classes and methods for migration. 
  • Migrate upgrade - Drush support for the Drupal core migrations from Drupal 6 and 7.

Lead image generated by OpenAI.

Last week was very quiet, July 1–7’s #experience-builder Drupal Slack meeting was even more tumbleweed-y…

… but while that was very quiet, the Acquia UX team’s design locomotive was getting started in the background, with two designs ready-to-be-implemented posted by Lauri — he’s working with that team to get his Experience Builder (XB) product vision visualized:

1. #3458503: Improve the page hierarchy display — with Gaurav “Gauravvvv” enthusiastically jumping on it!
2. #3458863: Add initial implementation of top bar

On top of that, a set of placeholder issues was posted — choices to be made that need user research before an informed design can be crafted:

• #3459088: Define built-in components and categorization for components
• #3459229: Allow saving component compositions as sections
• #3459234: Allow directly creating/editing entity title and meta fields
• #3459098: Define strategy for keyboard shortcuts
• #3459236: Redirect users directly to Experience Builder when creating new content or editing content

More to come on the design front! :)

Missed a prior week? See all posts tagged Experience Builder.

Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!

For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!

Speaking of design, Hemant “guptahemant” Gupta and Kristen “kristenpol” Pol are volunteering on behalf of their respective employers to implement the initial design system prior to DrupalCon Barcelona.

Front end

• Jesse “jessebaker” Baker landed an important refactor (#3456946: Refactor Preview.tsx React component to prevent duplicate backend calls), with reviews from Ben “bnjmnm” Mullins and Lee “larowlan” Rowlands
• Jesse also landed a small foundational piece of the UI: #3458723: Implement context menu for hovered component, which also is a crucial stepping stone for future accessibility work
• Harumi “hooroomoo” Jang got #3456084: Add initial implementation of primary menu landed and filed the follow-up #3458617: Close menu on drag in primary menu — which subsequently spawned an interesting discussion about the design between Jesse and Lauri
• Jesse got #3459235: Implement front-end (React) routing library going, with enthusiastic participation from Bálint “balintbrews” Kléri and Ronald “roaguicr” Aguilar
• Having observed environment setup issues for some, Ben opened #3458369: DDEV support for Cypress tests after witnessing how painful it was for Jesse to get Cypress talking to Drupal inside DDEV

Front-end starting points for contributing to XB

Jesse reported two bugs that would be excellent starting points for contributing to XB:

• #3459333: Undo/redo - user can undo the loading of the initial state (regression)
• #3458535: Middle click + drag doesn’t work correctly if middle click is inside preview iframe

And Lauri added a feature request that builds on top of the aforementioned foundational UI piece Jesse & Ben landed (#3459249: Allow opening the contextual menu by right clicking a component) — that too is a great entry point.

Back end

And, finally, on the back-end side:

• Ted “tedbow” Bowman pushed forward #3456008: Add support for matching SDC prop shape: {type: string, enum: …} but got stuck. He opened #3458580 as a blocker … and upon my return that Friday, I discovered that actually … that was working correctly, but the implementation was very confusing — not surprising, considering this code dated back to a PoC branch from the chaotic origins. So, instead, the logic was made a lot clearer, with better comments. If you’re interested in the deepest parts of how Drupal handles structured data, you’ll probably find it an intriguing commit. 1
• I’d missed it the previous week, but Lee actually did a huge push forward on #3454519: [META] Support component types other than SDC, by turning a high-level concept into a concrete proposal in the form a massive draft MR, with lots of interesting concepts, all rooted in his real-world experience with Layout Builder. An interesting discussion between Alex “effulgentsia” Bronstein and Lee ensued :)

Thanks to Lauri for reviewing this!

1. Sadly, it’s an inevitability that this is still complex: Drupal 8 introduced Typed Data API into the pre-existing Field API, and then later the Symfony validation constraint API was integrated into both. Getting a full picture of what constraints apply to an entire entity field data tree is not something Drupal core provides, so that picture must be manually crafted, which is what that code does. ↩︎

• Drupal
• Acquia
• Experience Builder