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

• GraphQL

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:

• Acquia
• 1xInternet
• Skilld
• Palantir
• Digital Polygon
• Zoocha
• ImageX

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.

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

• DDEV
• local development

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:

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:

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:

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?

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:)

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:

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

• Philip Norton argues that since Drupal core uses new static, it should be ignored. 
• Discussion in the Drupal core issue queue regarding new static versus new self. 
• Discussion in the PHPStan Drupal issue queue related to whether or not these types of errors should be ignored in Drupal core PHPStan runs
• Discussion in PHPStan issue queue related to the effect on a large code base of changing new static to new self 

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

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...

It’s day 13 and we’ve fewer than half of the doors remaining. For today’s door we’re taking a break from modules to talk about mentoring with Anto Jose (antojose).

I would like to use this calendar day to tell you about my experience mentoring at DrupalCons.

I signed up for mentoring at DrupalCon Lille, not because I thought of myself particularly as mentoring material, but because of the joy I found years back, when trying to help some people get their first taste of contributing, first during DrupalCon Asia 2016, and then during DrupalCon Amsterdam 2019, and then in a couple of online…

Tags

• Mentoring

Drupal 7 is going to retire. Yes, you heard it right! 

Our buddy Drupal 7 is going to retire on January 05, 2025. It has been a trusted CMS partner for thousands of websites but you know, in a space that is forever changing, upgrading to the latest version is not just an optional thing anymore. Your Drupal project must use the most up-to-date version of Drupal for security and performance reasons. 

There won’t be any security release, bug fixes, community support, or addition of new features in Drupal 7 anymore. So it is time to say goodbye to our Drupal 7 buddy as Drupal 10 is here already, loaded with lots of new features & better security for your project. 

We know you may think there is still so much time left. But our dear friend, As you know Preparation is the key to success, and now is the right time to make a successful migration plan for your Drupal site. 

And you know the good news ? 😀

LN Webworks is now a " Drupal Association’s Certified Drupal Migration Partner.