Drupal blog: Drupal 10.2 is now available

New in Drupal 10.2

The second feature release of Drupal 10 improves content modeling, block management, menu and taxonomy organization, and permission administration. New options to sanitize file names make it possible to clean up the names of uploaded files, and media item revisions now have a dedicated user interface.

Easier content management

10.2 improves the user experience for managing several types of content:

  • Field types for new fields are visually listed instead of a simple select list. Settings for fields are now all included on one form.
  • Menu items and taxonomy terms have a dedicated option to add a child item, which makes item placement easier.
  • Media items now have a dedicated user interface to review and manage older revisions.
  • CKEditor's language selector can now be configured to only show languages supported on the site.

More flexible block placement

A user interface has been added to show or hide each block based on the HTTP response status, so that specific blocks can be added or removed when the page is not found (404) or access is denied (403).

New built-in file name sanitization options

The functionality of one of the most popular contributed modules is now included in core! Replace whitespace in file names, transliterate text, convert to lowercase, and more.

Faster permission management

The permissions page now comes with a filter on the top to make it easy to find the permission you planned to adjust.

Performance improvements

Drupal 10.2 includes numerous performance improvements for content rendering and HTTP responses, as well as improved caching APIs.

Works on the latest PHP

PHP 8.3 was released three weeks ago, and Drupal 10.2 is already compatible with it.

Modern language feature: PHP attributes

Drupal core has started adopting PHP attributes, a modern PHP language feature, to provide better developer experience for plugin annotations. Contributed and custom code can begin adopting this improved API for their plugins, and Block and Action plugins can all be converted to the new API.

Built-in project news updates

To help keep you up to date with project news, the Announcements Feed module became stable and is now installed by default with the standard profile.

Developer experience improvements

Drupal 10.2 comes with a number of developer experience improvements:

  • A PerformanceTestBase was added to support automated testing of performance metrics with support to send OpenTelemetry traces to an open telemetry endpoint.
  • A new DeprecationHelper::backwardsCompatibleCall() method is available that helps write Drupal extensions that are compatible with multiple major versions at once.
  • PHP Fibers support was added to BigPipe and the Renderer, which allows Drupal to potentially run different code while it's waiting for an asynchronous operation to return.
  • Configuration validation was expanded to better support strict testing and make configuration form validation easier to implement.
  • Symfony's autowiring support was adopted for services, based on PHP 8 attributes, making service creation easier.
  • The HTML utility classes and filter system was updated to produce HTML5 syntax instead of XHTML.

Core team updates

Drupal is built by an open source community of collaborators across geographies and organizations. Maintainers assess the work of the community and decide when it's ready to commit to Drupal core. After a period as a provisional committer, Dave Long (at Full Fat Things) was promoted to a full release manager. Kristiaan Van den Eynde (at Factorial) and Adam Bramley (at PreviousNext) have also become core subsystem maintainers. Thanks for stepping up!

Want to get involved?

If you are looking to make the leap from Drupal user to Drupal contributor, or you want to share resources with your team as part of their professional development, there are many opportunities to deepen your Drupal skill set and give back to the community. Check out the Drupal contributor guide, or join us at DrupalCon Portland and attend sessions, network, and enjoy mentorship for your first contributions.

LN Webworks: Why Drupal Is the Best CMS for Government Sites: Top 9 Reasons

Image removed.

Government and public sector websites, powered by Drupal, play a vital role, serving as the virtual hub for a multitude of functions. These Drupal-based sites are not just informative platforms; they function as the digital town square—connecting people, facilitating business transactions, providing updates, and showcasing key attractions.

The responsibility of selecting the right content management system (CMS) falls on government officials. This decision comes with a low margin for error and high stakes. Government websites, designed with Drupal by a proficient Drupal development company, must fulfill numerous criteria, including being secure, scalable, engaging, and more. 

Golems GABB: Getting Started with Drupal Commerce: A Beginner's Guide

Getting Started with Drupal Commerce: A Beginner's Guide Editor Fri, 12/15/2023 - 12:31

Drupal Commerce is a user-friendly system developed from tens of thousands of modules. It allows you to build a customized e-commerce store that meets all customer requirements. The framework source code is available to each customer, further simplifying use. 
Drupal 7 software was used to create Drupal Commerce. The developers have added essential features, including product management, a convenient shopping cart, fast checkout, and fulfillment. Also, this commerce platform has a built-in content management system, which some of the world's famous companies use. Let's explore the capabilities with our Drupal Commerce tutorial designed for beginners.

LostCarPark Drupal Blog: Drupal Advent Calendar day 15 - GraphQL

Drupal Advent Calendar day 15 - GraphQL james Fri, 12/15/2023 - 07:00 Image removed.

Once again, welcome to the Drupal Advent Calendar. It’s Day 15, and today Dan Lemon (dan2k3k4) is here to tell us about the GraphQL module.

The GraphQL module for Drupal is a game-changer in the world of web development. With its smooth integration into the Drupal ecosystem, this module opens up new possibilities for building decoupled websites with efficiency and flexibility.

At its core, the GraphQL module is designed to provide a query language for your API, enabling you to request only the data you need. This approach contrasts with traditional REST APIs, offering a more efficient and…

Tags

Promet Source: A Transformative Approach to Drupal Migration

Over the past several months, much of the focus within the Drupal community has concerned the imperative of Drupal migration.  Between the Nov. 1, 2003 end of life for Drupal 9, and the announcement at DrupalCon last Spring that Jan. 5, 2025 was the final, final end-of-life date for Drupal 7, there has been a steady stream of messaging concerning the Why, the When, and the How of upgrading to Drupal 10. 

Drupal Association blog: Pitch-burgh updates end 2023 (November & December)

The year is coming to a close and activity is already ramping down as we approach the Christmas festivities, so this month my PitchBurgh update will cover November and December.

But, before I jump into those updates, and as we are reaching important milestones and PitchBurgh is proving its value to Drupal and the community, let me highlight the importance of the companies that have made PitchBurgh possible, without whom anything of this would have been possible. Those companies are:

As I mentioned, PitchBurgh projects are crossing some important milestones, reaching their midpoint projects, and some are even getting to the end of the projects themselves. Let’s cover some important of the past weeks:

Access Policy

Kristiaan’s work on Access Policy API got merged https://www.drupal.org/project/drupal/issues/3376843

This was a relatively complex project, not just because of the technical side, but also because of what it did imply in terms of communication and coordination with the different people involved, and the fact that it needed approval from the core team to get this work committed into Core.

The big concern with this PitchBurgh project, as well as the JSON API one, was having the investment and all the work done, and preventing the work from getting stuck waiting for approvals and merges for months.

So, seeing how this project is the first to cross the line and get merged to core, is not just a relief, but proof that we can get complex things done as a community. It just takes a little bit of organization and communication between all parties involved, in this case the Drupal Association was the one ensuring that this communication and updates were happening often.

This project was finally committed on 17 November 2023 and will be in Drupal 10.3. You can watch a video/demo of the project here. We are now working to ensure that Drupal core itself also implements the new API by the time 10.3 is released.

JSON API

JSON api has completed their work as well

You can watch their video here:

https://www.previousnext.com.au/blog/pitchburgh-diaries-decoupled-layout-builder-sprint-3-4

Decoupled Layout Builder

Decoupled LB reached project mid point, so right now the work is being reviewed before the funds get released for this part of the project.

You can read all the updates and the rest of the information of the project on their Drupal.org issue:  https://www.drupal.org/project/drupal/issues/3375422  

You can also read the project wrap up here.

Drupal API

It has been an eventful month for the Drupal API Client. 

Reaching a big milestone for the project, we’ve published a 0.1.0 release on npm which represents our Vertical Slice POC. Now that we have a small sample of the client out in the real world, we’ve created an issue for soliciting feedback from the community. Any feedback small or large would be extremely helpful for the project. We’ve also been spreading the word through an ‘Update on the Drupal API Client’ blog post and a session at New England Drupal Camp.

We are also happy to announce that coby.sher and pratik_kamble have joined the project as maintainers. They both played a critical role in making our POC a reality and we’re excited to have their leadership going forward.

As we gather feedback, we’ll continue work on the JSON:API Client 1.0 release meta issue. We could still use contributors. If you’d like to participate, join us in the #api-client channel in Drupal Slack.

Gutenberg in Drupal

Gutenberg project is progressing well. After the different conversations and alignments with the team in Automattic, there is a date for the workshop and a provisional agenda. Here is a sneak peak at said agenda:

  • In depth go-through of how we built Drupal Gutenberg
  • The Wordpress build scripts
  • Handling permissions within Gutenberg
  • Short term structured data with JSON field
  • Possible long term structured Gutenberg
  • Gutenberg for single field editing
  • Collaborative editing

Across each of our progress we've paid out a total of 38,037.75 for milestones achieved, with 2 projects already finished, one that has crossed midpoint, and the rest advancing at a good pace.

LostCarPark Drupal Blog: Drupal Advent Calendar day 14 - DDEV

Drupal Advent Calendar day 14 - DDEV james Thu, 12/14/2023 - 07:00 Image removed.

It’s day 14, and we’re wrapping up the second week with a big topic. Ryan Price (liberatr) joins us to talk about DDEV, the local development environment.

When you first boot up your computer and start working on a local copy of your site, what does that look like? Is it easy? Is it a chore? (please tell me you’re working locally if you’re doing any theme or module development)

If you got a new laptop tomorrow, would you know how to get your local copies of your sites running on that machine? The idea of setting up a new machine for development used to scare me. Now that I use docker-based tools…

Tags

DrupalEasy: How best to handle "Unsafe usage of new static()" PHPStan errors

Image removed.As a Drupal module developer, if you're as big of a fan of PHPStan as I am, then you'll no doubt have run across the Unsafe usage of new static() error that PHPStan throws when analyzing code at level 0. In this article I will describe what causes this error and provide four possible solutions, weighing the pros and cons of each.

Generally, this will occur in a create() method when you are injecting a dependency into a class using either ContainerFactoryPluginInterface or ContainerInjectionInterface using the common (simplified) Drupal pattern of:

class baseClass { public function __construct(array $configuration, $plugin_id, $plugin_definition, ModuleHandlerInterface $module_handler) { parent::__construct($configuration, $plugin_id, $plugin_definition); $this->moduleHandler = $module_handler; } public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) { return new static( $configuration, $plugin_id, $plugin_definition, $container->get('module_handler'), ); } }

Basically, PHPStan is warning you that there could be an issue if the class is extended and the new class overrides the constructor with different arguments. For example, if the Token service class is added:

class newClass extends baseClass { public function __construct(array $configuration, $plugin_id, $plugin_definition, Token $token, ModuleHandlerInterface $module_handler) { parent::__construct($configuration, $plugin_id, $plugin_definition); $this->token = $token; $this->moduleHandler = $module_handler; } }

At this point, when newClass is instantiated by the container, it will fail because its inherited create() method no longer matches its overridden constructor. This is bad.

Now, this coding pattern is all over Drupal core and contributed modules, and we are generally very careful about breaking things (thank you, automated tests.) Regardless, PHPStan isn't cool with it, so let's look at some alternatives. 

Dig hole in sand, stick head in it

Easiest, but probably not a good long-term solution.

PHPStan provides the ability for certain errors to be ignored, and this is definitely a good candidate for ignoring. Additionally, it is simple enough to do with a quick addition to your phpstan.neon configuration file:

parameters: level: 0 paths: - web/modules ignoreErrors: - '#Unsafe usage of new static\(\)#'

Generally, I'm not a big fan of ignoring any code quality issues, whether they are from phpcs, PHPStan or any other code quality tool.

Pros

  • PHPStan error goes away

Cons

  • That nagging feeling that you really didn't fix anything.

Prevent others from extending the class

Easiest for custom code, with limitations.

If using new static is only an issue when the class is extended, then why not just prevent the class from being extended with the addition of the final keyword?

final class baseClass { … }

This definitely solves the issue, and in many cases, is a valid solution. I almost always use final when writing a custom module - especially when I am in control of the code base.

Using final in core or a contributed module is a bit trickier, as in most cases the assumption does have to be made that someone somewhere is going to extend that class for reasons you haven't thought of. Being the co-maintainer of several contributed modules, I'm experimenting with using it - to see if anyone opens an issue letting me know that it is blocking them in some way or another. Time will tell.

Pros

  • PHPStan is happy.
  • Code protection against someone extending the class and not properly overriding the constructor and create() methods (if necessary).

Cons

  • The class cannot be extended, possibly limiting its usefulness.

Change new static to new self

Most correct, but with potential repercussions.

Recommended by a Drupal.org documentation page, but with little explanation, this change looks like this (from our example above:)

public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) { return new self( $configuration, $plugin_id, $plugin_definition, $container->get('module_handler'), ); }

In this case, if the class is extended and the constructor is overridden, then the code will always fail unless the create() method is also overridden. Curiously, the documentation page also suggests adding final to the class. I suspect that the documentation page should be updated, but I'm not confident enough in what is the best way to handle this to make a suggestion. Yet.

Pros

  • PHPStan is happy.
  • This is probably the "most correct" solution.

Cons

  • While the class can be extended, less experienced developers might not always recognize that they must override the create() method when overriding the constructor, potentially leading to a bug that can be tricky to figure out. For example, if the create() method isn't overridden, then the result would be that the base class is created and not the (expected) extended class. 

Make the constructor final

Similar to marking the entire class "final".

I haven't spotted this potential solution in a Drupal community discussion, but on the PHPStan blog, one of the suggestions is to just make the constructor final. Again updating our code sample from above:

final public function __construct(array $configuration, $plugin_id, $plugin_definition, ModuleHandlerInterface $module_handler) { parent::__construct($configuration, $plugin_id, $plugin_definition); $this->moduleHandler = $module_handler; }

This seems like a slightly more flexible solution than making the entire class final or changing from new static to new self, but still would limit anyone extending the class. Maybe this is a reasonable middle-of-the-road solution? I haven't seen it implemented in Drupal yet.

This method would allow the class to be extended, but the constructor wouldn't be allowed to be overridden - which means no dependency changes can be made. Obviously, this limits what extended classes would be able to do.

Similar to this method, the blog post also suggested adding the constructor signature to an interface, which would have the same effect of locking it down so that it cannot be changed.

Pros

  • PHPStan is happy.
  • Code protection against someone extending the class and not properly overriding the constructor and create() methods by not allowing those methods to be overridden. 

Cons

  • If the constructor can't be overridden, then while the class can be extended, its dependencies cannot be changed, potentially limiting its usefulness. 

Summary

So where does that leave us? Hopefully, with the ability to make a more informed decision on how to handle this particular PHPStan error. As I mentioned above, I'm not a big fan of ignoring PHPStan errors, so for now, I'll be adding final most of the time 😉.

Additional reading

Thanks to Professional Module Development course alumni James Shields and Hanane Kacemi as well as Ryan Price for reviewing this blog post.

Tag1 Consulting: Gander: Performance Testing Made Easy

Join us for an update on Gander, the automated performance testing framework making waves in Drupal Core. Developed by Tag1 Consulting and the Google Chrome team, Gander is set to transform how we approach performance testing. In this Tag1 Team Talk Mariano Crivello, Nat Catchpole, and Michael Meyers share the story behind Gander's development. Learn how it's simplifying performance testing for developers, reducing the burden on maintainers, and becoming a game-changer for organizations using Drupal. Part one of our two-part series dives into Gander's history, benefits, and roadmap. Stay tuned for part two, where we'll give you a hands-on demo of Gander in action. Ready to level up your Drupal game? Dive into the Gander story now! Links: - Gander Announcement: The Future of Drupal Performance & Scalability - Google’s Core Web Vitals - Core Web Vitals: Google & Tag1 Improving Drupal’s Performance, User Experience, and Your Bottom Line - from DrupalCon Pittsburgh --- For a transcript of this...

Read more michaelemeyers Wed, 12/13/2023 - 05:00