Dries Buytaert announced recently that the product name for the result of the Drupal Starshot Initiative will be Drupal CMS. Exciting! Activities on features for Drupal CMS are divided into tracks - a set of deliverables focused to provide valuable solutions for different parts of the product strategy.

Let’s see what’s cooking in the Drupal CMS kitchen as since the announcement of the track leads, quite some work has been done. We are happy to share a brief overview to highlight the progress made!

The Events Track has been busy with transferring the Events recipe to the Drupal CMS and now we’ve got the beginnings of an event system. As with all the Drupal CMS components, the ultimate plan is for each one to be available as its own project, but at the same time all be developed within the same repo. 

The Data Privacy / Compliance Track is busy developing a survey for the international audience. We are looking forward to sharing it with the community very soon.

The Trial Experience Track in coordination with the Drupal Association has devised a solution to leverage GitLab Pages. After checking in with the rest of the Drupal CMS team, it was decided the trial codebase would be added to the monolithic repository. You can find more details at the dedicated blog post by Matt Glaman.

The Starshot Demo Design System initiative is supporting the Experience Builder demo next month by providing Drupal-branded components within a design system theme. The team has made excellent progress and needs more help in the next two weeks to test components within Experience Builder. Learn how to get involved!

The SEO Track managed to add Basic SEO recipe to Drupal CMS. This recipe will be applied by default, is idempotent (can be applied multiple times), and sets the simple best practices configuration we feel every site needs. The team is continuing to work to define an advanced SEO recipe that we will propose to be optional that has more tools for optimizing for search engines.

The Advanced Search Track has drafted a proposal for the track. It is being reviewed by the leadership team and the idea is to provide a recipe for at least two different approaches and collect community feedback. We expect this to happen in September so stay tuned!

The Media Management Track is undertaking discovery to gather common practices and new insights that will lead to a proposal for the features and recipes for media in early versions of Drupal CMS. The track will also propose how improvements and innovations could look for media beyond the launch of Drupal CMS. Tony Barker has created a survey as part of the discovery and welcomes the community to provide their thoughts and feelings on media in Drupal using this form.

We are observing the progress each track team is making with excitement and will keep you up to date on upcoming developments!

PORTLAND, Ore., 29 August 2024—The Drupal Association is pleased to announce Dropsolid as a partner for the Drupal 7 Extended Security Support Provider Program. This initiative aims to support Drupal 7 users by carefully selecting providers that deliver extended security support services beyond the 5 January 2025 end-of-life (EOL) date.

The Drupal 7 Extended Security Support Provider Program allows organizations that cannot migrate from Drupal 7 to newer versions by the EOL date to continue using a version of Drupal 7 that is secure and compliant. This program complements the Association’s Drupal 7 Certified Migration Providers Program, which helps organizations find the right partner to transition their sites from Drupal 7 to Drupal 11.

Dropsolid’s Drupal 7 extended support offers Drupal 7 support beyond 5 January 2024, with Enterprise Drupal specialists with a reputation in the community, access to enterprise Drupal 7 developers to continue development, and much more.

“We’re excited that Dropsolid has stepped up and committed to our Drupal 7 Extended Security Support Program,” commented Tim Doyle, CEO of the Drupal Association.  “Dropsolid has been a tremendous supporter of Drupal and the Drupal Community, and we’re grateful that they’re including bona fide Drupal 7 support among their offerings.” 

As organizations prepare for the transition from Drupal 7, Dropsolid will provide the necessary support to keep their sites secure and operational.

Dominique De Cooman, co-founder and co-CEO of Dropsolid, proudly added: “We are thrilled to qualify for the Drupal 7 Extended Security Support program. Even more so since we're the only European company selected (even though we have offices in US and EU). As an organization of makers contributing towards security of Drupal and Mautic, we want to continue contributing to Drupal as much as possible. It's part of our mission to give Drupal 7 the End of Life it deserves. Beyond EOL support, Dropsolid will continue to deliver robust D7 support at both the code and platform levels. We’re here to back you—past, present, and future.”

More information on Drupal 7 Extended Support from Dropsolid.

About the Drupal Association

The Drupal Association is a non-profit organization that fosters and supports the Drupal software project, the community, and its growth. Our mission is to drive innovation and adoption of Drupal as a high-impact digital public good, hand-in-hand with our open source community. Through various initiatives, events, and programs, the Drupal Association helps ensure the ongoing development and success of the Drupal project.

About Dropsolid

Driven by an open culture and with a passion for open source, Dropsolid shares their knowledge, code, and talent with their clients. Dropsolid designs, builds, hosts, evolves, and creates websites & DXP with results. Equipped with a CMS, marketing automation, personalization, and even AI. Starting from a strong digital strategy with one goal in mind: the best digital experiences for your organization and your customers and stakeholders.

When the value of the placeholder is the same as the value you need in the field, it just looks like a disabled field.

Drupal 11 was released recently. Yay. And with it comes a bunch of minor (and sometimes major) changes to the way Drupal works and the need to update the documentation to reflect those changes.

Exciting news! Tag1 Consulting is proud to be a module sponsor at DrupalCon Barcelona 2024. Join us from September 24-27 for four days of Drupal innovation, collaboration, and community spirit. Our team will be presenting on Gander, Drupal Core development, LMS, DDEV, and more.

In this article, we delve into the process of migrating Drupal fields, building on the knowledge from previous discussions about Drupal fields and their database structures. We begin by addressing the two key components of field migrations: storage and instance settings. This is the first step in a multi-stage migration process that will ultimately involve four different migrations.

Setting up a multilingual website in Drupal opens the door to a global online marketplace, allowing businesses to reach different cultural audiences by presenting content in multiple languages. In this article, we will discuss the process of configuring a multilingual site on Drupal.

The back-end heart of Experience Builder (XB) is its two-property field type. Thanks to Ted “tedbow” Bowman, the tree field property is now strictly validated, which is essential to ensure both data integrity and the ability to evolve the codebase rapidly and confidently. Crucially, this validation constraint is used to validate both content and configuration, just like the validation that was added in week 10.

That validation finally unblocked #3446722: Introduce an example set of representative SDC components; transition from “component list” to “component tree”: now that Ted landed the necessary validation, it makes sense to add Kyle “ctrladel” Einecker’s set of Single Directory Components (SDCs) that Lauri has confirmed to well represent the spectrum of SDC functionality XB must support.
Ted will change the default component tree that XB configures for articles, so that we’ll start seeing Kyle’s two_column SDC by default!

To assist Ted, I updated the XB field type’s computed hydrated property to support hydrating component trees instead of just component lists, and updated the “preview” route to use that logic 1.
Ted already landed validation, I took care of rendering, so now Ted can focus on the remaining bits … because until now, we’d been testing/developing XB with only a handful of sample components — we fully expect this to reveal a bunch of missing things. That’s exactly why getting a representative set of SDCs into the XB codebase is important, even if eventually they may only be used in tests.

Hopefully that will land next week!

Missed a prior week? See all posts tagged Experience Builder.

Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!

For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!

Hearing the term “routing” in a Drupal context typically means “server-side routing”. But for an extensive JS application, client-side routing is important too: it allows sharing a URL with a friend/colleague to invite them to collaborate on a particular bit in the content being created. That’s why Jesse “jessebaker” Baker and Ben “bnjmnm” Mullins landed client-side routing for XB, after having asked for feedback from the community on which direction to take (thanks Bálint “balintbrews” Kléri, Ronald “roaguicr” Aguilar, Kyle and Lee “larowlan” Rowlands for your input!), landed on React Router. The implementation will likely evolve, but a basic implementation is now in place, and includes test coverage.

Related to routing, but on the back-end side: Lee updated XB’s server-side routes to expect an entity type + ID, rather than hardcoding them all to node one. This is a welcome improvement, but would not have happened if not for Lee or somebody else in the community: for the team working full-time on XB this isn’t a priority yet, because we’re prioritizing the hard stuff — the known unknowns. Still, we definitely welcome MRs like these, and will happily review & merge them!

I know y’all are waiting for interesting progress on the experience of using XB — this week’s key progress on that front is brought to you by Ben!
Choosing a component to pick just based on the name might be okay … but an instantaneous visual preview would be better, right? That’s exactly what he landed in #3462636:

The funniest bugfix of the week is brought to you by Utkarsh “utkarsh_33”: the SDC prop labels were present on field widgets, but were invisible :D

Finally, in the “improve DX & velocity” department, the eslint prettier configuration was updated, which gets us closer to Drupal core’s configuration for JS. Thanks to Ivan “finnsky” Berdinsky, Ben, Gaurav “gauravvvv”, Daniel “DanielVeza”, Lee and harumi “hooroomoo” Jang — Harumi captured the impact well:

Looks good! Will save headaches

:)

Computing a StorablePropShape

Back to the back-end side, to end this week’s update in a very deep place (but also a very interesting place!): XB gained the ability to compute a field type + storage settings + instance settings for a given SDC prop shape (the normalized subset of an SDC prop’s JSON schema that affects the shape of data it expects — the title, description, examples etc. in the JSON schema are irrelevant from this point of view; I named this a PropShape).
Until now, XB has only been using matching. But that can only get us so far — for example, SDCs often have props whose JSON schema looks like this:

To populate this SDC prop, XB must store a string (logical choice: Drupal core’s string field type), but not just any string: only primary or secondary. Drupal core has an answer for this too: the list_string field type. But the matching that was hitherto used requires either a field type that allows precisely those 2 values, or an existing list_string field instance that is configured to allow those 2 values. Clearly, that’s likely to result in zero matches, because the chances are vanishingly small that a Drupal site has a pre-existing field instance configured exactly like that. And that is just one example: many SDCs will have different allowed values.

That’s where computing rather than matching becomes relevant: use logic to compute what exact shape (in this case: a type: string that also specifies an enum: […]) requires which field type (list_string) and which corresponding field storage+instance settings (here only storage settings: allowed_values: [ {value: primary, label: primary}, {value: secondary, label: secondary} ]). The computed result is represented by a StorablePropShape.

And that is necessary for XB users to fully benefit from the work Ted is doing on #3446722: many of those representative SDCs are indeed using enum: otherwise you’d not be able to edit component instances that will be placeable once Ted’s done!

This infrastructure also paves the path to something else: allowing those computed field type + widget decisions to be altered. For example, when the Media Library module is installed and a media type that uses the image MediaSource plugin is present, an SDC with a prop that expects an image should no longer use the image field type + widget, but the Media Library widget. So I worked with Ted and Ben to introduce hook_storable_prop_shape_alter(), and made XB implement it on behalf of the media_library module.

This doesn’t mean that matching goes away: that will remain relevant for identifying which existing structured data can be used to populate an SDC prop. Much more work is needed to make XB’s matching ability complete, but that work is for after the 0.1.0 goals for DrupalCon Barcelona.

Week 12 was July 29–August 4, 2024.

1. Instead of having its own logic that was somewhat different: DRY. ↩︎

• Drupal
• Acquia
• Experience Builder

• Previewing a component upon hovering it in the component list. Components temporarily have a loud background color.