With Drupal 9 having reached its end of life (EOL) on November 1, it’s time to start planning for an upgrade.
For those already operating on Drupal 9, upgrading to Drupal 10 is not as daunting as earlier upgrades and promises to be easy, reflecting the software’s overall trend towards smaller, more incremental upgrades and faster iterations. According to Drupal, you should "completely update your Drupal 9 site to the most recent version of the modules and theme(s), before updating to Drupal 10."
The deprecated code will be based on Drupal 9 moving into Drupal 10, but there are ways to search your system and update the specified code block.
The first thing to do is to install the drupal/upgrade_status module in your project and enable it. composer require drupal/upgrade_status && drush en upgrade_status, if you have drush installed else go to admin > modules and search for upgrade status and install it. After the module is enabled, go to Admin > Reports > Upgrade Status. This page should contain all the upgrades and code changes necessary before your site can be upgraded to Drupal 10.
Steps to upgrade Drupal 9 to Drupal 10
Migrating from Drupal 9 to Drupal 10 can be easy or can be difficult depending on the project you are involved in. Yes, because every site is different and may present its own unique challenges.
These are the following steps to migrate from Drupal 9 to Drupal 10.
composer require drupal/core-recommended:^9.5 drupal/core-composer-scaffold:^9.5 --update-with-all-dependencies
Now let's look at the tricky part. Drupal 10 has some specific things we have to do to allow us to upgrade to drupal 10.
composer require mglaman/composer-drupal-lenient
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/token"]'
composer remove drupal/console --no-update
After all these are done and ready for upgrade, you can run this command
composer require 'drupal/core-recommended:^10' 'drupal/core-composer-scaffold:^10' 'drupal/core-project-message:^10' --no-update
If drupal/core happens to be part of the composer.json file, remove it. This dependency is included in drupal/core-recommended and may cause problems. If you have drupal/core-dev installed, you can run this
composer require 'drupal/core-dev:^10' --dev --no-update
Now,let us test perform the update with the --dry-run option: this allows us to see if the update will runs smoothly or might encounter some errors.
composer update --dry-run
If you encounter any errors, walk through the process to resolve them. Resume the process when the errors are resolved, run the update with dependencies to update any transitive module.
composer update -W
Don’t forget to run drush updb and drush cex after the upgrade. This means you should run the upgrade on top of an installed and functioning D9 database.
If you have a custom theme that is based on classy,seven or stable then don’t forget to install them as contrib themes - composer require 'drupal/[module_name]'. You should uninstall and remove upgrade status after the upgrade process.
Pathauto has an issue with some config files so, if you have Pathauto installed then you need to update some configs by hand. Namely pathauto.pattern.[name] config files have had their selection_criteria plugins updated. For example node_type becomes entity_bundle:node. or try the following command
drush eval 'include_once(DRUPAL_ROOT . "/modules/contrib/pathauto/pathauto.install"); pathauto_update_8108()'
In summary the whole update process for a site can be very difficult and ranges from project to project. It could have different modules installed, with some even locked to specific dev versions, as well as heavily patched old major versions of modules which needed to be upgraded. You walk through these steps and iterate through if need be to get your upgrade completed.
Support for Drupal 7 will end next year. If you're running your website on this version of the system, now is a great time to figure out what to do with it. Is upgrading to Drupal 10 a good idea? And how about choosing other technologies to migrate your site? Join our free webinar on February 22nd to discover your options as Drupal 7's end-of-life becomes a reality.
Take advantage of Symfony Mailer’s first-class integration with Symfony Messenger brought to Drupal via the SM project, allowing your site to send emails asynchronously.
by daniel.phin / 8 February 2024This post is part 6 in a series about Symfony Messenger.
Since Swift Mailer and its Drupal contrib integration were recently deprecated, many projects have naturally switched to its replacement: Symfony Mailer, either via Drupal Symfony Mailer or Drupal Symfony Mailer Lite.
This post outlines how you can take advantage of Symfony Mailer’s first class integration with Symfony Messenger brought to Drupal via the SM project. This integration allows for dispatching emails off-thread, potentially improving performance of the dispatching (usually web-) thread by offloading email-related tasks to dedicated Symfony Messenger workers. This setup can be considered an alternative to using Queue Mail.
As of writing, of the two Symfony Mailer implementations in contrib, Drupal Symfony Mailer Lite has built in support for Symfony Messenger. Drupal Symfony Mailer does not yet support it, an issue and merge request exist to add it. Apply a patch until the changes are merged.
Symfony Messenger itself does not require any special configuration, other than installing SM.
To run asynchronously, the \Symfony\Component\Mailer\Messenger\SendEmailMessage message must have routing configuration to a transport. Or at least the fallback transport must be configured. Without transport configuration, Emails will still be dispatched through Messenger, however they will be executed synchronously in the same thread they were dispatched.
Opting out
If you happen to have both Symfony Mailer and Symfony Messenger installed but do not want emails to be sent asynchronously, you can configure routing for the \Symfony\Component\Mailer\Messenger\SendEmailMessage message to instead use the synchronous transport.
If you’re using the SM Config submodule:
Emails may be dispatched using the usual Drupal mechanism, or you can dispatch using Symfony Mailer directly by constructing an email object:
$email = (new \Symfony\Component\Mime\Email())
->to('jane@example.com')
->from('john@example.com')
->subject('Hello world!')
->text('Some sample text.')
->html('<p>some <strong>sample</strong> text.</p>');
/** @var \Symfony\Component\Mailer\MailerInterface $mailer */
$mailer = \Drupal::service(\Symfony\Component\Mailer\MailerInterface::class);
$mailer->send($email);After the send method is executed, Mailer checks Messenger is available, creates a new SendEmailMessage message to wrap the \Symfony\Component\Mime\Email object. Then dispatches SendEmailMessage to the messenger bus.
As is typical with Symfony Messenger, email messages must be serialisable. Avoid including any Drupal entities or service references in an email object, and render email contents before sending it.
To process email messages, run the worker with sm messenger:consume. This command will either listen or poll for messages and execute them in a dedicated thread, ensuring quick processing after they are dispatched. For more information on the worker, please refer to post 3 of this series.
In the next post, we’ll explore how to add a user interface to notify users when relevant tasks have been processed.
Authored by: Nadiia Nykolaichuk.
One of the earliest known calendars was created by ancient Egyptians, who used hieroglyphics and carvings to represent the months, days, and important events. Today, visually appealing and user-friendly calendars are easily created on websites, all thanks to powerful CMSs like Drupal. We’ll share some modules in Drupal that are available for calendar creation and management, and carefully walk you through the key steps of building a calendar.
import RadCallout from '../../../components/rad/RadCallout.astro';
As a result of our Pitch-burgh funding, the current focus of the Drupal API Client is to create a fully featured client for Drupal's JSON:API implementation. Even with that goal, we've focused on making our work extensible for other API formats in the future through the implementation of an ApiClient base class. Functionality that could apply to any API client is added to the base class, while anything specific to JSON:API is added to the JsonApiClient class (which extends ApiClient.)
Recently, we have been working on adding Decoupled Router support to our JSON:API Client. I found this implementation to be a great example of the extensibility of the library, so I wanted elaborate on it in a blog post for those who may want to extend the API Client in the future.
The existing JsonApiClient has the following method to retrieve data for a resource:
await client.getResource('node--article', '3347c400-302d-4f6c-8fcb-3e74beb002c8');
Ideally, users of Decoupled Router could also get an identical response by resolving a path:
await client.getResource('/articles/give-it-a-go-and-grow-your-own-herbs');
To achieve this, we first needed to provide a way to reliably get data from Decoupled Router.
With the module enabled, Decoupled Router exposes an endpoint with the following structure:
/router/translate-path?path=<path>
Given a path like /articles/give-it-a-go-and-grow-your-own-herbs the endpoint could provide a response similar to:
{
"resolved": "https://dev-drupal-api-client-poc.pantheonsite.io/en/articles/give-it-a-go-and-grow-your-own-herbs",
"isHomePath": false,
"entity": {
"canonical": "https://dev-drupal-api-client-poc.pantheonsite.io/en/articles/give-it-a-go-and-grow-your-own-herbs",
"type": "node",
"bundle": "article",
"id": "11",
"uuid": "3347c400-302d-4f6c-8fcb-3e74beb002c8"
},
"label": "Give it a go and grow your own herbs",
"jsonapi": {
"individual": "https://dev-drupal-api-client-poc.pantheonsite.io/en/jsonapi/node/article/3347c400-302d-4f6c-8fcb-3e74beb002c8",
"resourceName": "node--article",
"pathPrefix": "jsonapi",
"basePath": "/jsonapi",
"entryPoint": "https://dev-drupal-api-client-poc.pantheonsite.io/en/jsonapi"
},
"meta": {
"deprecated": {
"jsonapi.pathPrefix": "This property has been deprecated and will be removed in the next version of Decoupled Router. Use basePath instead."
}
}
}
While easy to make sense of, this response technically doesn't follow the JSON:API spec, which prevents us from using our existing JSON:API Client without modification. We could write a small amount of custom code in JsonApiClient to fetch and handle data from this endpoint, but this case is exactly what our ApiClient base class is intended for. With a similarly small amount of code we can extend the ApiClient class to add only what is unique to the Decoupled Router endpoint, while getting access to all of the features of the base class at the same time.
So rather than writing code specific to JsonApiClient, we decided to create a new DecoupledRouterClient class that our JsonApiClient could then make use of.
For the sake of example, a simple Decoupled Router client could look like this:
// DecoupledRouterClient.ts
import {
ApiClient,
type ApiClientOptions,
type BaseUrl,
} from "@drupal-api-client/api-client";
export class DecoupledRouterClient extends ApiClient {
constructor(baseUrl: BaseUrl, options?: ApiClientOptions) {
super(baseUrl, options);
const { apiPrefix } = options || {};
this.apiPrefix = apiPrefix || "router/translate-path";
}
async translatePath(path: string) {
const apiUrl = `${this.baseUrl}/${this.apiPrefix}?path=${path}`;
const response = await this.fetch(apiUrl);
return response.json();
}
}
In our constructor, the only modification we need to make is the default value for the API prefix. While the base class doesn't have a default, Decoupled Router uses router/translate-path. Now when instance of DecoupledRouter is created without this option, it will use the default.
We then define a translatePath method that:
Using an instance of this class would look something like:
// main.ts
import { DecoupledRouterClient } from "./DecoupledRouterClient.ts";
const decoupledRouterClient =
new DecoupledRouterClient("https://dev-drupal-api-client-poc.pantheonsite.io");
const translatedPath =
await decoupledRouterClient.translatePath(
"/articles/give-it-a-go-and-grow-your-own-herbs"
);
<RadCallout>Check out this code sandbox for a live version of the example above.</RadCallout>
With this example we already have a functional client, but quite a bit more is possible using the features of the ApiClient class we extended. For example, We can already make authenticated requests using any of the supported authentication methods:
// main.ts
import { DecoupledRouterClient } from "./DecoupledRouterClient.ts";
const decoupledRouterClient =
new DecoupledRouterClient("https://dev-drupal-api-client-poc.pantheonsite.io", {
authentication: {
type: "OAuth",
credentials: {
clientId: "client-id",
clientSecret: "client-secret"
}
},
});
// API requests will now be authenticated
const translatedPath =
await decoupledRouterClient.translatePath(
"/articles/give-it-a-go-and-grow-your-own-herbs"
);
Our example Decoupled Router client could be updated to take advantage of built in caching, logging, or locale support. For example, the following modification would allow us to make use of the defaultLocale option if our Drupal site supports multiple languages:
// DecoupledRouterClient.ts
import {
ApiClient,
type ApiClientOptions,
type BaseUrl,
} from "@drupal-api-client/api-client";
export class DecoupledRouterClient extends ApiClient {
constructor(baseUrl: BaseUrl, options?: ApiClientOptions) {
super(baseUrl, options);
const { apiPrefix } = options || {};
this.apiPrefix = apiPrefix || "router/translate-path";
}
async translatePath(path: string) {
// If it exists, incorporate the default locale
// into the apiUrl
const apiUrlObject = new URL(
`${this.defaultLocale ?? ""}/${this.apiPrefix}?path=${path}`,
this.baseUrl,
);
const apiUrl = apiUrlObject.toString();
const response = await this.fetch(apiUrl);
return response.json();
}
}
Routing is a common problem, so we've added a fully featured getResourceByPath method to our latest @drupal-api-client/json-api-client release. We've also published the Decoupled Router client as a standalone package for anyone who wants to use it separately.
While the caching functionality of the client can lessen the impact, getResourceByPath still makes multiple API calls for uncached data, which leaves room for improvement. We could optimize this in the future by providing support for the subrequests module. That is yet another client for a type of Drupal API that could use the ApiClient base class as a starting point.
We're closing in on the 1.0 release of @drupal-api-client/json-api-client. If you’re interested in contributing, check out our project page on Drupal.org, and join us in the #api-client channel on Drupal Slack.
Instead of showing the original author of a node, show the last person to edit it.
In this second part (check the first part!) of our Tag1 Team Talk on Gander, the new Automated Performance Testing Framework integrated into Drupal Core, we get a live demo from Nat Catchpole (aka. Catch), the lead developer on the project. Nat takes us on a tour through this high-impact tool developed by Tag1 in collaboration with the Google Chrome Team, showing you how you can get up and running with automated performance testing for your projects. Gander is poised to significantly impact Drupal's user experience, performance and Core Web Vitals by creating visibility into how Drupal performs on the front and back end. Catch shares his expert insights into the development and application of Gander and shows how easy it is for developers to start extending and using this today on their projects! Whether you're a Drupal developer looking to improve your project's performance or simply curious about the latest in Drupal technology, this episode offers valuable knowledge and practical advice on getting your Drupal website to perform optimally. With discussions on Gander's immediate benefits and future potential in the Drupal community, this episode is a must-watch for anyone interested in taking their projects to the next level...
Read more Mariano Tue, 02/06/2024 - 05:41The Webform module works as a form of builder and submission manager within the Drupal framework, offering a wide range of levels of flexibility and ease for site builders. This tool empowers website creators to efficiently develop a range of forms, with the added benefit of default settings for quick implementation. Delving into its impressive features, the Webform module is known for its user-friendly interface. Users can swiftly create forms using default configurations or take advantage of the module's customization options to tailor forms to precise specifications.
Beyond this, the Webform module boasts a suite of powerful features, making it a core asset of the Drupal ecosystem. But there’s more to it. Let’s have an overview of the most important features and functionalities of the Webform.
Projects no longer need to rely on unpredictable processing time frames. The SM project can intercept legacy Drupal @QueueWorker items and insert them into the Symfony Messenger message bus, effectively giving existing core and contrib queue workers jobs real-time processing capabilities.
This post is part 5 in a series about Symfony Messenger.
@QueueWorker plugin implementations require no modifications, including the method of dispatch, data payload, or the processItem . The data payload must of course be serialisable. Fortunately, most QueueWorker plugins already comply since their data is serialised and stored to the queue table. As always, avoid adding complex objects like Drupal entities to payloads.
With queue interception, the sm command can be solely relied upon. Legacy runners such as Drupal web cron, request termination cron (automated_cron.module), and Drush queue:run will be rendered inoperable since they will no longer have anything to process. Consider decommissioning legacy runners when deploying queue interception.
Queue interception is a part of the primary SM module. Adding a single line in settings.php is the only action required to to enabling this feature:
$settings['queue_default'] = \Drupal\sm\QueueInterceptor\SmLegacyQueueFactory::class;
SM module will need to be fully installed before this line is added. Consider wrapping the line in a class_exists(SmLegacyQueueFactory::class) to enable in a single deployment.
Existing per-queue backends
Setup may be more complex if projects are utilising per-queue backends or anything other than the default database backend for queues, such as Redis. In that case, carefully evaluate whether to convert all or specific queues to use Symfony Messenger.
Whether per-queue backends are utilised can be determined by looking for queue_service_ or queue_reliable_service_ prefixed items in settings.php.
@QueueWorker jobs are converted to \Drupal\sm\QueueInterceptor\SmLegacyDrupalQueueItem messages in the backend. Knowing this class name allows you to configure transport routing. If routing for this message is not explicitly configured, it will naturally fall back to the default transport, or execute synchronously if there is no routing configuration.
As usual, when a transport is configured, all you need to do is run sm messenger:consume to execute the tasks. The worker will either listen or poll for messages, and execute them in a very short amount of time after they are dispatched, in a dedicated thread. More information on the worker can be found in post 3 of this series.
The next post covers how Drupal emails can be dispatched to messages, so the web thread can execute faster.