When we think about how to make a Drupal website load faster, we often focus on how to make Drupal render the pages faster: optimizing queries, caching entities, and so on. But out of the box Drupal has several layers of caching enabled by default, and many popular Drupal hosts have additional systems in place like memcached and Varnish to further enhance the overall page load. In practice, the load of the page itself is often a small fraction of the overall time and data needed for a visitor to view a page.

Have you ever wondered why your code is running fine on your computer, but not for your colleagues? Can you remember the feeling you had the last time you failed to release an important feature on time because your local LAMP stack or Operating System failed after an upgrade? Who has time to do DevOps, stay up-to-date and secure, fix one-offs, or chase the next missing dependency? The price tag of DIY is very high. 

Acquia Cloud IDE is the best IDE to develop Drupal. It is a fully managed LAMP stack and IDE in the Cloud that is highly available, predictable and reliable. With it, your IDE is identical to your colleague’s IDE–same software versions, same configuration, and same experience. It is that simple.

So what was DDD Ghent like?

You may have noticed that dev.acquia.com was recently relaunched! As part of this refresh, a newly expanded Drupal 10 readiness dashboard was launched. A previous version of this dashboard helped with coordinating work on the update of Drupal 8 contributed projects to Drupal 9. This is how it works and what it offers.

Every week, the Drupal Association runs Upgrade Status on all contributed projects compatible with Drupal 9. The raw data is impossible to comprehend, so we process it and present it on an easy to browse Drupal 10 readiness dashboard.

Drupal 7 will reach end of life on January 5, 2025. The Drupal Association has confirmed that there won’t be any more extensions to the deadline! 

If you haven’t already, make sure you’ve read about the risks of staying on Drupal 7 and our recommended actions. 

If you’re reading this article, chances are you’ve decided your site’s future lies with Drupal 10. That’s exciting news—there are tons of great features waiting for you on the other side of the Drupal 7 to Drupal 10 migration!

So let’s take a look at what it’ll take to get you there. While each migration project is unique, you can generally split it up into the steps below. 

1. Review your Drupal 7 website

Moving from Drupal 7 to Drupal 10 is a big step. So take it as an opportunity to plan your site’s future and assess its structure, content, functionality, and design. 

Here are some questions to get you started:

• What do you want from Drupal 10? Envision how you’ll leverage Drupal 10’s features to enhance and grow your digital presence. Consider setting up a sandbox environment to play around in. 
• Does the current structure work well? Think about how you could improve the information architecture to make your new site easier to navigate. 
• What needs to be migrated? Consider if you need all of the current functionality and content. You might want to optimize or rewrite your content. Creating a data transfer table (DTT) will help you map old and new content structures and reduce the risk of losing data.
• Does the design need a refresh? Explore opportunities to update the look and feel of your site to make your brand shine. 
• Does your code need an overhaul? This is a good time to revisit custom code and bring it up to speed with best practices and modern standards. 
• How big of a job is it? Complex, multilingual, and content-heavy sites often present additional challenges that require more resources and expertise. 

Need some guidance? Consider getting a site audit, digital strategy, redesign, or migration support from an expert partner like Evolving Web. As a Drupal Signature Supporting Partner with 16+ years of experience, we can help you move forward with confidence. 

2. Check Modules Availability

Are you using contributed modules to extend the functionality of your Drupal 7 site? If so, you’ll need to check that they’re compatible with Drupal 10 or find an alternative before you migrate. 

You can do this by manually checking each module’s page on drupal.org, or by using a tool such as the Upgrade Status module.

Even if your existing modules are Drupal 10 compatible, it’s worth taking a look at alternatives as the Drupal community might have created better solutions. If you want a better alternative but there isn’t one available, you can ask an agency with development services to port the module to Drupal 10. 

Also, see what new modules you can use with Drupal 10 that you couldn’t with Drupal 7. For example, take a look at these 5 modules that enhance CKEditor 5, the default WYSIWYG editor in Drupal 10. 

3. Create Your Drupal 10 Website

You’ll need to create a brand new website using the latest version available (Drupal 10.1 at the time of writing). 

Install the modules you selected in the previous step. Remember that the installation process will be different in Drupal 10 than it was in Drupal 7. 

Set up your content structures including blocks, content types, media types, webforms, and menus. Consider taking advantage of Layout Builder—a core module since Drupal 8.5 that replaces the Panels module. Layout Builder’s powerful drag-and-drop functionality makes it easy to build attractive, flexible pages. 

4. Update Your Code

Try and use existing contributed modules where possible to reduce the need for custom code. Any custom themes will need to be recreated from scratch. Check out our guide on how to use a Single Directory Components approach to theming.

Use best practices and modern coding standards. Remember, Drupal 10 requires at least PHP 8.1 and has updated database requirements. Check out our guide to porting CKEditor plugins to Drupal 10.

Implement your custom modules and themes on your Drupal 10 website. 

5. Migrate Your Data

If you don’t have much content, you might be able to manually migrate it from the old site to the new one. Otherwise, you’ll probably want to automate the process. 

If you do an automated migration, you can use the Migrate API to move over content and configurations. Make sure you understand its limitations and have a plan for managing them. For example, you may need to recreate views with the views migration module.

Other helpful modules for migration include Migrate Plus, Migrate Tools, and Migrate Scanner.

Complete migration for one content type and before starting to work on others. This will save time as you’ll be able to use the first completed migration as a template for the rest of them.

If you need to migrate a huge amount of content, it’s better to run migrations via Drush than UI so that it’s easier to roll back and rerun them quickly.

Before you migrate:

• Clean up content and data on your Drupal 7 site 
• Update your old site to the latest Drupal 7 version
• Back up your data in case something goes wrong 
• Announce a content freeze so that nobody updates the old site during migration
• Make sure old URLs are redirected to avoid 404 errors

6. Test Your New Site

Systematically test and QA your new website to ensure it’s secure, performant, and accessible across various devices. Check that all of the content and data have been migrated correctly. Finally, get approval from the necessary stakeholders.

7. Launch! 🚀 

Let your audiences know about the upcoming change. This is a nice opportunity to show off and explain how it benefits them! 

Update your site's DNS settings to point to your Drupal 10 website. Re-implement any old redirects or custom URLs, and watch for any 404 errors or other warnings in your logs. 

Lock down your old Drupal 7 site so that it’s secure and can’t be accessed by the public. You may want to eventually create a static copy and a backup for reference. 

8. Continue to Evolve Your Site

• Train your team to use Drupal 10. Give them the skills and confidence to independently update your site with our custom training or Drupal Learning Tracks.
• Keep your new site secure. Implement security patches as soon they’re released. You may be able to use the Automatic Updates module to make the job easier (this module won’t work if you’re using a hosting platform such as Acquia or Pantheon.) 
• Nurture your digital presence. It should be a living thing that’s always adjusting to stay relevant and valuable. Keep UX/UI considerations at the front of your mind.
• Explore new modules. The Drupal community is continuously creating fresh solutions. You can easily search modules within the Drupal 10 admin UI using Project Browser.

Embrace innovation. Drupal is gearing up for radical transformation that’ll bring you even more possibilities, such as the adoption of AI technologies.

A round-up of our learning and conversation shared at DrupalCon Lille.

At DrupalCon Pittsburgh, a team of interested community members submitted The Drupal API Client Project to be considered for funding as part of the Pitchburgh Innovation Contest. (If you missed it, check out our pitch video below, along with the original proposal.)

Are you a proud Drupal website owner who dreams of a smooth and seamless upgrade process? Migrating your website to a newer version of Drupal can seem like a daunting task, but with the right techniques, it can be done in a snap. In this blog post, we'll discuss a different approach to Drupal migration that will save you time, hassle, and potential headaches.

Welcome to the third edition of the Pitchburgh Diaries, a regular update on progress as we work on our plan for a decoupled Layout Builder with React.

Sprints 5 and 6 were our final sprints in the project. Keep an eye out for a final wrap-up and summary of the next steps, which we’ll publish in the coming weeks.

Bundling and extending

In this sprint, we focused on the nuts and bolts of how contrib and custom code will extend decoupled Layout Builder functionality.

We began by creating a new Drupal 10-compatible version of the React module. Thanks to @corbacho for adding us as co-maintainers for the project! 

When we bundle the decoupled Layout Builder code for use in the browser, we don't include React. Instead, we rely on the React module to load it. This allows other modules that need React (e.g. Gutenberg) to use a shared version of React. React doesn't work if two versions are loaded on the same page.

The new version of the React module makes use of a relatively new browser API called import maps. Import maps allow you to write ECMAScript modules (ESM) with naked imports and have the browser resolve the dependency for you.

So, for example, our bundled code still has import React from 'react' in it. With an import map, the browser can resolve that to a Javascript file and load it for you.

To support this functionality, we wrote and released an import maps module which both the Decoupled Layout Builder API and React module make use of. We believe this functionality belongs in core because you can only have one import map on a page. So we opened a core feature request for that too.

With this module in place, bundling for contrib and custom code that wants to add additional components to the decoupled Layout Builder becomes much simpler. Essentially the build configuration needs to mark imports of React, React DOM, the JSX runtime and the decoupled layout builder components as 'external'. This ensures the bundled code retains the original import statements. Both Vite and Webpack support this feature. 

For those who recall how we built ES6 code in Drupal 9, you would know we had scripts in core's package.json and webpack configuration to transpile it into code that worked in older browsers like Internet Explorer. With Drupal 10, we removed that step as all of our supported browsers have native support for ES6 code. Similarly, if you've built a CKEditor 5 plugin, you would know it also uses Webpack for bundling.

As a result, Webpack felt like the natural choice for bundling here too. WordPress uses it to bundle block components for their Gutenberg editor. However, the web landscape moves quickly. The tool we chose N years ago may no longer be the best choice. With all modern browsers supporting ESM, the bundling landscape has changed. 

Those who follow front-end web development would know that many projects are actively moving away from Webpack towards Vite. Storybook added support for Vite in v7, and just last week, Remix had a major announcement about Vite support. CKEditor5 has also added Vite support. For this reason, we evaluated both Vite and Webpack for use in our utility Drupal scripts package. Thispackage is designed to make writing and bundling code for use with the decoupled Layout Builder simpler. Based on our evaluation and the broader front-end landscape moving towards Vite, we chose it for our bundling.

As a result, we have an npm package @drupal/scripts that we will release in the coming weeks with the following features:

• A simple build step. No need to manage your own bundling configuration - just add a dependency on @drupal/scripts (more on that below) and add this to your package.json for building - drupal-scripts build -o js/dist js/src 
• A simple setup process - if you install the package globally, you can run drupal-scripts init to have it automatically update your package.json with the required changes
• Support for scaffolding components for use with decoupled Layout Builder - just run drupal-scripts generate and follow the steps.

Feature development

In our first four sprints, we focused on building the Layout Editor in a decoupled application. We were mocking APIs so development could occur without a Drupal site.

In these two sprints, we switched to instantiating the Layout Editor in an actual Drupal site.

The Layout Editor uses React components that mirror Blocks, Formatters, Widgets and Layout plugins from Drupal. We have always intended for these to be the extension points for the application. If you need to change how any of those work in a project, you should be able to swap in your own custom React component.

To facilitate this, the entry point for the decoupled Layout Builder is the Layout Editor component. It takes a map of components for each of the Blocks, Formatters, Widgets and Layout plugins. This map is keyed by the plugin ID (same IDs as in Drupal). The values of the map are a function that return a promise, that will resolve the components. What each component comprises depends on the type. 

For example, a Block component needs an Edit and Preview component but might also need a Settings component. You can read more about what each component comprises in the storybook documentation.

In order to boot the Layout Editor, Drupal needs to construct these maps. To do this, we make use of existing plugin definitions and extend them to add an entry for the decoupled Layout Builder. 

Here's an example of nominating the path to a React component for a layout plugin:

In this example, the file MyLayout.js would be scaffolded with the drush-scripts generate command and updated according to the documentation for a Layout component.

In the Decoupled Layout Builder API module, we replace the default LayoutBuilder render element with a decoupled one. When this component is rendered, it loops over all of the block, formatter, widget and layout plugin definitions and builds up a mapping from ID to component path. This is then stored in drupalSettings. The element also attaches some Javascript to boot the React application that reads this value back and turns the file paths into promises using the browser's native import operator.

With all this in place, we were able to boot the new Layout Builder in Drupal 🎉. Here's a screenshot of that for the Recipe content-type in the Umami demo profile:

Other key highlights

So, while we've focussed mainly on the big ticket items, we were also able to complete a fair few of our other wish list items in these final sprints, including:

• Fallback rendering when no React component exists - as seen above, we're able to fallback to Drupal rendering where no React component exists yet
• Support for layout builder restrictions so that you can only drag and drop components into supported regions
• Support for saving changes in Drupal - including autosaving
• General improvements to Drag and drop so that it was easier to drag new components into existing regions
• General normalisation improvements so that section and region UUIDs are generated Drupal side and stored in third-party settings.
• GitLab CI integration so that Storybook builds on every push.
• Additional documentation and tests.
• Layout settings pane

Where to next

We've reached the end of our sprints for Pitchburgh. But that doesn't mean the work stops. We plan to continue working on the project and have quite a backlog of new features we'd like to add.

In our next post, we'll recap each of the completed stories for our Pitchburgh grant statement of work, go into more detail about our future plans and let you know where you can help.

Tagged