A few people in the Drupal community have expressed difficulty getting started with the Schema.org Blueprints module for Drupal. A while back, I created an installation guide for the Schema.org Blueprints module. The installation guide is helpful, but the Schema.org Blueprints module is a comprehensive solution for leveraging Schema.org’s content models to create the ideal content authoring experience to provide an API-first and SEO-friendly website. The Schema.org Blueprints module includes many sub-modules that can create confusion and trepidation. Most sub-modules manage integrations with other contributed modules, but they are all optional. I’ve found that the best way to help people understand the module is to walk them through a specific task or feature.

Training and walk-through videos can help supplement documentation and examples. Please watch the below walk-through of installing the Schema.org Blueprints module.

The Upgrade Status module is a free and open-source Drupal module that helps you assess the compatibility of your Drupal site with Drupal 10. It does this by checking your site's configuration, modules, and themes for any potential issues preventing you from upgrading to Drupal 10. Let’s understand what the Upgrade Status module is, why it is important for upgrading to Drupal 10, and how to use it. We will also provide some tips for using the module to ensure a smooth upgrade process. 

What is the Upgrade Status module?

The Upgrade Status module, often called with the machine name  "upgrade_status" module, is a crucial tool within the Drupal ecosystem. It is a comprehensive reporting system that evaluates a website's readiness to migrate to a new version of Drupal. 

The world of technology is constantly evolving - striving to create new solutions and improve the old ones. Consequently, the life cycle of any software sooner or later reaches its inevitable end. Such a fate awaits the distinguished and still popular Drupal 7 with the end of its official support by the developers. This is the perfect moment to recall the novelties it brought in relation to the previous versions and shed some light on what's next.

General information about Drupal 7 

Released on 5 January 2011, Drupal 7 was the successor to Drupal 6, obviously. It brought many awaited and, above all, necessary changes. Learn about some of the most important ones.

• The concept of entity was introduced, known from many other solutions. Hereafter, entities can be anything – from a user profile and a node to things like a comment or a taxonomy term.
• Support for multisite appeared
• Content Construction Kit (CCK) became a module in the Drupal 7 core.

In addition, there were many smaller but no less essential improvements, such as: improvement of performance and security, changes in hooks and API, reduction of system requirements, ability to create shortcuts, scheduling tasks using cron, and many, many more.

Drupal 7 end of life - change of date

Originally, Drupal 7 end of support was planned for November 2021. Then, this date has been changed to 28 November 2022 and to 1 November 2023. The Drupal team justified this latest change because many companies and institutions were still using Drupal 7. For this reason, the CMS developers and maintainers didn't want to leave so many websites without security updates.

Recently, the Drupal team has announced the new date of Drupal 7 end of life - 5 January 2025. With this update also came the information about the reduced support for medium critical Drupal 7 issues. Such tasks will be added to the public issue queue (if only they aren't mass-exploitable) for resolution. Also, in the situation when - from the beginning of August 2023 - some contributed module or theme is marked as unsupported, it won't be available for the new maintainer.  

Drupal 7 specification

Drupal 7, compared to its predecessor, is distinguished primarily by a more thoughtful approach to content management, which translates into changes in how data is stored, structured, and entered. Entity is an element that has remained with us to this day until Drupal 10.

Why do you need to perform a Drupal 7 migration?

Migrating Drupal 7 to a higher version is essential for many reasons. Here are the most important ones:

• The end of support for Drupal 7 - in practice, this also means no security updates. Consequently, this exposes the website owner to the need to accept a higher risk of hacking attacks and deal with their possible consequences. It also involves incurring additional costs of buying paid services from companies offering support to work on security vulnerabilities.
• Complying with the new SEO standards of higher Drupal versions - search engines have changed their algorithms over the past ten years and promote content differently than they used to. If you want your website to appear higher in search results, a Drupal update will help. New versions of Drupal handle the latest SEO standards much better. This is because they stand out with improved performance over older versions, better support for mobile devices, and improved website accessibility for people with disabilities.
• A more pleasant content editing process after the migration - although content editing was user-friendly in the years following the release of Drupal 7 (especially compared to Drupal 6), the UI world has moved on, and over the following years, the approach to working on content in this system version has become less and less in line with the latest trends and editor habits. Upgrading to Drupal 10 will optimize the content creation process, especially with the new Claro skin or contrib solutions such as Gin.

Drupal 7 vs. Drupal 10 and other system versions 

You cannot compare Drupal 7 with Drupal 10, not to mention intermediate versions. The introduction of Drupal 8 was a tremendous and significant change in the direction of system development. Let's look at some of the most important changes and improvements over the previous version.

• Drupal has been rewritten using the Symfony framework. For those unfamiliar with the topic, Symfony is one of the most popular PHP frameworks. Therefore, from the very beginning Drupal could boast that it gets a lot of support from the community and creators associated with Symfony. This change is actually so big, because the earlier Drupal versions weren’t based on any such powerful frameworks.
• A new engine for creating templates has been introduced - the well-known and popular Twig (this is the result of switching to Symfony, where this engine is also used). This streamlines the work when creating templates, and brings the way of implementing them closer to modern standards, abandoning the previous themes and PHP templates.
• The lack of a sensible text editor in Drupal 7 has been solved in version 8 with CKEditor - an extremely powerful and multifunctional tool for working with content.
• The Views module has become a part of the system's core.
• Drupal 8 brought almost 200 changes and patches that you can read about on Drupal.org.

You may also be interested in: 10 tricks to work efficiently with the Composer in Drupal 8

How does the matter look in further versions? Moving from Drupal 8 to Drupal 9 allowed updating dependencies and removing code marked as deprecated. So, migrating an application written in Drupal 8 to version 9 involved removing deprecated elements from the code and updating modules.

Drupal 10, on the other hand, introduced more significant changes that required more community involvement to make modules and skins compatible with this system version. Drupal 10 swapped the default admin skin from Seven to Claro, the skin from Bartik to Olivero, introduced CKEditor 5, updated Symfony to version 6, removed some JavaScript components using jQuery, and replaced them with more modern versions.

So, is the change from version 7 to version 10 a good idea? To put it simply: YES! 

From the very beginning, the transition to Drupal 8 seemed like a necessary move. The number of innovations and possibilities that version 8 introduced at the time was staggering, and the already outdated solutions known from Drupal 7 were beginning to be a crutch when juxtaposed with the rampant development and progress in web development. Versions 9 and 10 only widened the gap.

Then what is the cause of such a large number of websites (about 380 thousand active installations - as of August 2023) still operating on Drupal 7 and of the many years of support from the developers provided for such an old software version? It's all the result of how great a revolution Drupal 8 was and what significant changes have been made to the very logic that underlies the entire system. The introduction of Symfony as the base framework for Drupal was a double-edged sword. Although it actually brought only good changes, it led to practically no compatibility with the previous versions.

Upgrading from Drupal 7 to 8 couldn’t be done automatically, and sometimes even required rewriting the entire page from scratch. As you can imagine, this could be very problematic for systems maintained over the years, not to mention the cost that such a change could generate.

Today, however, we are already richer with years of experience. Upgrading from 7 to 8 doesn't have to be as titanic a job as it initially was. There are many tools on the market that can help us with the migration and make it easier.

Drupal 7 EOL - professional help

Since we have already established that moving to the latest version of Drupal is actually a necessity, and we’ve gained some additional time with the move of the planned end date of support, we’ll introduce you to this process. If you don't feel up to it, we recommend that you contact the professional Drupal support team for help. Using the services of specialists experienced in this type of migration can significantly shorten the entire process, as well as dispel any doubts related to it.

Drupal 7 to 10 migration - how to conduct the process?

Migration is a multi-stage process that includes time for preparation, implementation, and post-migration activities. Let’s discover the following steps. 

How to prepare for Drupal 7 to 10 migration?

When preparing, you should first determine which functionalities are essential to you and must be maintained. Elements can be sorted by priority. Here, it’s important to remember to keep dependencies between functionalities so that you don’t exclude some critical parts. Dependency mistakes will most likely be caught during the migration process but can then introduce confusion, which can be avoided by conducting a solid planning stage. 

The preparation stage is also a great time to plan for additional functionality you have always wanted to introduce, but for some reason, it wasn’t possible in the old system version. In this case, even potential functionalities should be discussed during migration planning, as they can affect the process going forward. 

In addition to functionality, you should also determine which content should be migrated. Migration is also an excellent time to refresh the look of your website - the skin will have to be rewritten anyway due to its almost complete lack of compatibility with newer versions of Drupal. Therefore, the additional outlay of resources will be less than if you postpone this investment until after the migration.

On the technical side, it's a good idea to review the available modules and ensure that everyone you have uses them. For contrib modules, make sure they support Drupal 10. Custom modules must be rewritten, so choosing only the necessary modules will save you time and money. 

It’s also crucial to plan the infrastructure on which you’ll run your website. The infrastructure must be compatible with Drupal 10 requirements, and it should allow you to easily scale your resources to accomplish your task in case of higher demand.

How to implement Drupal 7 to 10 migration?

After decent preparation comes the implementation stage. It’s worth ensuring that your Drupal 7 is updated to the latest possible version. This should minimize any difficulties in moving the configuration. Next, we usually start by moving the entity structure to prepare a place for data import. 

If the Drupal 7 application will continue to be used throughout the rewriting process, then you should consider implementing incremental content migration, a way to determine which data has been migrated and which has not yet. Typically, this is done by recording the export date of the content of a given type and comparing it to the date the content was last edited to export only those items whose last modification occurred later than the previous export. 

On the technical side, modules such as Migrate, Migrate Drupal, Migrate Upgrade and Migrate Plus will help you with the migration. 

Importantly, before each data import, you should make security copies so that you can make the appropriate corrections and try again in case of failure. 

After data migration comes the stage of installing and configuring the remaining contrib modules and skins and rewriting custom modules and skins. This stage requires (in the case of custom modules and skins) several steps. The first is to understand the Drupal 10 architecture to be able to rewrite the code correctly and according to standards. It’s also crucial to update the documentation so that the purpose and use of the module are clear to both developers and website administrators.

What should you keep in mind after Drupal 7 migration?

After the migration (in the case where the Drupal 7 website is active), it’s necessary to determine the moment when the so-called content freeze occurs, that is, the time when no content is added to the site. This is when we import the last content increment to the new web page on Drupal 10 and update the modules. 

Drupal 10 is a rapidly developing system. Module updates are released every day. Staying up to date allows you to eliminate as many bugs as possible and also enables you to use the system's latest features.

Drupal 7 end of life - summary

Migration to the latest version of Drupal is essential for many reasons. Depending on the website's characteristics, size, popularity, and several other factors, the process of preparation, implementation, and post-migration activities vary significantly. 

If your website needs to be migrated to a higher version, get help from professionals. Our team of developers specializing in Drupal 7 to 10 migration has experience in processes carried out with complete success.

The Drupal Business Survey invites business leaders worldwide to share their insights and metrics on the Drupal business ecosystem. Relevant topics to many digital service providers include business development, community, marketing, and human capital. The results of this survey are analyzed and aggregated into a comprehensive report and presented at DrupalCon Europe, the yearly Drupal summit. Participants can support anonymously.

The Drupal Business Survey is about sharing business insights between Drupal service providers worldwide. Drupal’s open source ecosystem thrives by a collaborative community of tens of thousands of professionals worldwide, working together on the popular digital experience platform. Drupal has an Open Web objective, allowing anyone to work with the web or contribute to it. The Drupal Business Survey gives meaningful data for Drupal experts to make business decisions for the coming years.

The survey allows Drupal service providers and independent professionals to share insights on various topics. Its comprehensive results on business outlook and customer engagement has been a valuable guide for digital service providers, even to those working with other technologies but Drupal. Data is coming in from all continents, with most of the companies being in business for 10 years or more.

Drupal business booming

In 2022, over 15% of the respondents indicated seeing a significant impact on their digital business by the pandemic. Covid-19 clearly was a catalyst for investments in the digital market. At the same time, the size of deals made grew by almost a third. Non-Profit and Government made the leading markets for Drupal last year, with Education at the top with over 60% of agencies working with these sectors. However, comparing all the industries over the past 5 years, the number of Drupal projects in Non Profit shows a significant decrease. Acquiring new talent is constantly challenging and business leaders need to find new ways to get the right people in.

The survey revealed that open source software, like Drupal, has maintained its popularity, which will not come as a surprise to those following the industry. Janne Kalliola: “One of the most significant advantages of open source compared to similar SaaS solutions is the flexibility and manageability of pricing. Organizations can easily adapt their use of Drupal to changing circumstances, such as the pandemic or the energy crisis, and they can use Drupal without large license fees.”

CEO Dinner

The Drupal market is looking forward to how digital service providers are using Drupal and how the Drupal market has evolved this year. The results of the 2023 Drupal Business Survey will be presented at the CEO Dinner at DrupalCon Europe. DrupalCon Europe is the yearly Drupal summit where over 1500 Drupal users and professionals meet to exchange ideas and further evolve Drupal. DrupalCon Europe is from 17-20 October in Lille, with the CEO Dinner on Tuesday, October 17th.

About the Business Survey

The Drupal Business Survey supports Drupal businesses worldwide and is organized by a team of industry experts Imre Gmelig Meijling (React Online), Janne Kalliola (Exove) and Michel van Velde (independent) in collaboration with the Drupal Association. The 2022 results can be viewed here.

Drupal is the open source Digital Experience Platform used organisations including Amnesty International, Tesla and DHL.

Participate and share your insights

Drupal experts are invited to share their Drupal business insights through the Business Survey anonymously and come to DrupalCon Europe to review the results together.

You can participate in the Drupal Business Survey anonymously here.
The survey closes on 4 September.

Site speed is crucial, particularly nowadays, when modern websites are more dynamic and interactive. The traditional approach of serving pages is notably inefficient in this context. Numerous techniques exist to achieve optimal performance, and one such method is the BigPipe technique, originally developed at Facebook. The good news is that the BigPipe module, which incorporates the same functionality, has been integrated into Drupal 8 core since version 8.1.

How does Drupal BigPipe work?

The general idea of the BigPipe technique is to decompose web pages into small chunks called pagelets and pipeline them through several execution stages inside web servers and browsers. 

At a high level, BigPipe sends an HTML response in chunks:

1. One chunk: everything until just before - this contains BigPipe placeholders for the personalized parts of the page. Hence this sends the non-personalized parts of the page. Let's call it The Skeleton.
2. N chunks: a tag per BigPipe placeholder in The Skeleton.
3. One chunk:  and everything after it.

This is conceptually identical to Facebook's BigPipe (hence the name).

How does Drupal BigPipe differ from Facebook's technique?

Drupal module differs significantly from Facebook's implementation (and others) in its ability to automatically figure out which parts of the web page can benefit from BigPipe-style delivery. 

Drupal's render system has the concept of “auto-placeholdering.” What does it mean? The content that is too dynamic is replaced with a placeholder that can be rendered later. 

On top of that, it also has the concept of “placeholder strategies.” By default, placeholders are replaced on the server side, and the response is blocked on all of them being replaced. But it's possible to add additional placeholder strategies. BigPipe is just another one. Others could be ESI, AJAX, etc. 

BigPipe implemented by Facebook, can only work if JavaScript is enabled. Instead, the Drupal BigPipe module makes it possible to replace placeholders without JavaScript “no-JS BigPipe.” This isn’t technically BigPipe at all, but it's just the use of multiple flushes. 

This allows us to use both no-JS BigPipe and “classic” BigPipe in the same response to maximize the amount of content we can send as early as possible.

So basically, that is happening during the page rendering process:

• The personalized parts are turned into placeholders &token=6NHeAQvXLYdzXuoWp2TRCvedTO2WAoVKnpW-5_pV9gk">. The placeholder contains information about which callback to call and the arguments to pass to it. The renderer then continues traversing the array and converting it to HTML. The resulting HTML, including placeholders, is cached. Then, depending on the rendering strategy being used, the placeholders are each replaced with their dynamic content.
• The replacement of the placeholders is done using JavaScript. The callback starts looking for replacement script elements once a special element is printed and found.
• At the very last moment, it’s replaced with the actual content. This new strategy allows us to flush the initial web page first and then stream the replacements for the placeholders.

When to use a lazy builder?

As a rule of thumb, you should consider using a lazy builder whenever the content you're adding to a render array is one of the following types.

• Content that would have a high cardinality if cached. For example, a block that displays the user's name. It can be cached, but because it varies by user, it's also likely to result in cached objects with a low hit rate.
• Content that cannot be cached or has a very high invalidation rate. For example, displaying the current date/time, or statistics that must always be as up-to-date as possible.
• Content that requires a lengthy and potentially slow assembly process. For example, a block displaying content from a third-party API where requesting content from the API incurs overhead.

Using lazy builders in practice

To provide a comprehensive example of implementing lazy builders, let's consider a scenario with a custom profile widget block placed on a web page. The block contains the user's picture, full name, and profile menu.

In order to ensure that every user sees their personalized information, we can implement specific strategies, such as setting the “max-age” to 0 or utilizing user contexts and tags. However, it's important to note that setting “max-age” to 0 will lead to the rest of the web page being uncached.

Thanks to the concept of “auto-placeholdering,” Drupal considers this block as a personalized part and turns it into a placeholder.

The only problem here is that we have the entire block replaced by a placeholder afterward:

=profilewidget&args%5B1%5D=full&args%5B2%5D&token=QzMTPnxwihEGO
itjJB_tahJj8V-L-KopAVnEjVEMSsk">

Nonetheless, it's worth noting that specific data within the block might remain static or consistent for all users, like this:

To make our block more granular, we can transform dynamic parts into placeholders while the other block content remains cacheable and loads during the initial page load.

Step 1. Creating lazy builders

Lazy builders are implemented using the render array of the #lazy_builder type, just like other elements. The render array must contain a callback as the first element and an array of arguments to that callback as the second element.

Lazy builder render elements should only contain the #cache, #weight, and #create_placeholder properties. 

Step 2. Implementing TrustedCallbackInterface

Before we go any further, we need to ensure that our lazy builder implementation can call the lazyBuilder() method. To do this, we need to implement the TrustedCallbackInterface to tell Drupal that our lazy builder callback is allowed to be called.

When implementing this interface, we need to add a method called trustedCallbacks(), which will be called automatically by Drupal through the detection of the interface. The return value of this method must be any methods within this class that can be used as callbacks.

Here is the basic implementation of this for our block:

As a result, the cached block will look like:

Normally the lazy builder callback will be executed on every page load, which is the intended behavior. But in certain cases, it may also be necessary to cache placeholders. To achieve this, we need to include cache keys along with the cache context, as in the example below:

Step 3. Ensuring a smooth visual page load experience

Because Drupal BigPipe lazily loads certain parts of the page, it could result in a jarring page load experience. It depends on our theme and the location of the lazily loaded content.

The simplest solution is to have the lazily loaded content appear in a space reserved for them that avoids reflowing content. Alternatively, we can apply a “loading” animation to all BigPipe placeholders in our theme with some CSS.

The last possible option is to define an interface preview that will be populated by BigPipe, using a Twig template.

Let’s compare the final result of the custom lazy-builder strategy (1) vs. “auto-placeholdering” strategy (2).

Custom lazy-builder strategy (1)
 

Drupal "auto-placeholdering" strategy (2)

Both strategies work just fine, but you can see the cons of auto-placeholdering, like jarring page load experience (drastic layout shift).

More examples:

1. Statistics block with static part loaded immediately and dynamic content loaded later:

2. Views with skeleton:

Troubleshooting lazy builders

If you’ve implemented a lazy builder and it isn't speeding up your Drupal page load or just isn't working as expected, then there are some things you can try:

• Be sure the Drupal BigPipe module is active. 
• Check the cache settings of your lazy builder callback method. By default, Drupal will make some assumptions about how it should be cached, which isn't always right for your use case. Instead, you can explicitly set the cache settings.
• An upstream CDN or Varnish layer might be caching your entire web page, so all of the output of the BigPipe rendering process will be served simultaneously. You'll need to find another mechanism to work around this.

Drupal BigPipe - summary 

In this article, we’ve explored an alternative rendering strategy that allows us to defer the rendering of highly dynamic content only after the static parts of the web page have already been loaded from the cache.

BigPipe, the Drupal module, can automatically enhance our website performance thanks to improved render pipeline and render API, particularly the cacheability metadata and auto-placeholdering.

However, it’s essential to note that using Drupal BigPipe doesn’t substitute for addressing underlying performance issues. Implementing lazy builders to mitigate the impact of slow code on your web page will only mask the problem rather than resolve it entirely. By implementing these techniques effectively, you can optimize performance and enrich the overall user experience on your Drupal-powered websites.