Blog

Monday was a U.S. holiday, which meant I was able to go full-steam ahead on the storage MR for Experience Builder (XB) that I started the prior week. On Tuesday, I continued that work, and spun off a second MR that allows changing the source type and source value … for which I shared a 2.5-minute screencast in #experience-builder late on Tuesday.

In it, you’ll see a hacky-as-hell UI. It’s currently named TwoTerribleTextAreasWidget to convey in no uncertain terms that this is throwaway code :D Its purpose: help stand up infrastructure and get the back-end pieces in place to power the UI (see last week’s screenshot), which is currently using hardcoded data.

Experience Builder (XB) must be able to render single directory components (SDC) … but really any component. Furthermore, to achieve the compromiseless UX we want, we’ll need both client-side and server-side rendering (to avoid network latency): isomorphic rendering. So on Monday May 20, Ben “bnjmnm”, Mateu “e0ipso”, Lee “larowlan”, Théodore “nod_”, Pierre “pdureau” and Tim met in a truly global meeting (from Lee’s Australia to Kris’ U.S. West Coast), with very interesting conclusions.
These are not current concerns for XB, but they will eventually be — this was early alignment to avoid wasting time.

Acquia is sponsoring me full-time to operate as the tech lead for Experience Builder — thanks!

Dries announced the formal start of the Experience Builder initiative at DrupalCon Portland 2024, on May 6. Shortly before DrupalCon, Drupal core product manager Lauri already shared the findings of the deep & wide research he conducted in prior months, which resulted in a set of 64 requirements.

On behalf of Acquia I’m currently working on Drupal’s next big leap: Automatic Updates & Project Browser — both are “strategic initiatives”.

So what was DDD Ghent like?

Statistics

• 137 issues across all projects
• 52 of the 137 (38%) for core, of which 7 already fixed
• 19 of the 52 (37% of core, or 14% of total) on CKEditor 5, 3 already fixed (all discovered at DDD, 2 of which for upgrade path)
• 16 of the 19 discovered at DDD

I’m especially interested in sprinting on the CKEditor 5 module for Drupal core, since that’s what I am currently working on for Acquia, because that is one of the biggest must-haves/blockers for Drupal 10. 86% of issues worked on at DDD Ghent was not CKEditor 5, so … I’m hoping others will do blog posts similar to this one! :D

Together with zrpnr, gabesullice, lauriii, bnjmnm, yashrode and hooromoo in Acquia’s Drupal Acceleration Team, I’ve been working on getting Drupal on CKEditor 5, because CKEditor 4 is reaching the end of its long and productive life.

zrpnr got it started in January 2021. We’ve been meeting with Reinmar ¹ from the CKEditor 5 team to ensure a smooth automatic upgrade path from CKEditor 4: all functionality should be even better! Less than 10 months later, on November 11, 2021, CKEditor 5 was committed to Drupal 9.3!

For the past two years I’ve been working on something less visible but no less important.

Since DrupalCon Amsterdam 2019 (an actual in-person conference — sounds surreal in 2021, doesn’t it?!) I’ve been working on Acquia Migrate Accelerate, or “AMA” for short. In a few days, another DrupalCon Europe is starting … so perfect timing for a recap! :D

Why?

Drupal 8 comes with an awesome migration system built in, originating in the Migrate Drupal 7 module. It standardized many migration best practices. But it still required a huge time investment to learn it.

Of course, there’s the “Migrate Drupal UI” (migrate_drupal_ui) module in Drupal core. But that does not allow for granular migrations. It allows for a one-shot migration: you see which things will be migrated and which won’t. You can click a button and hope for the best. It only works for the very simplest of sites. It is impressively minimal in terms of the code it needs, but unfortunately it also means one pretty much needs to be a expert in migrations to use it successfully.

It will be of little help as soon as you run into important data you want to migrate for which no migration path exists.

Mateu, Gabe and I agreed to sunset the API-first initiative, about which I’ve written a lot in 2016–2019.

We’ve all spent countless hours on it — Gabe and I were able to work on it mostly full time, Mateu contributed an incredible amount of his free time to get the API-first initiative and the JSON:API module ecosystem in particular to where it is today.

I learned a lot from these two lovely people, and we also had lots of laughs!

API-first Drupal with multiple consumers @DrupalConNA :D pic.twitter.com/GhgY8O5SSa

— Gábor Hojtsy (@gaborhojtsy) April 11, 2018

Mateu wrote a great retrospective, which is a superb way to end this project. Quoted here in full:

On 7 January, 2020, the Drupal module JSON:API 1.x was officially marked unsupported. This date was chosen because it is exactly 1 year after the release of JSON:API 2.0, the version of JSON:API that was eventually committed to core. Since then, the JSON:API maintainers have been urging users to upgrade to the 2.x branch and then to switch to the Drupal core version.

We understand that there are still users remaining on the 1.x branch. We will maintain security coverage of the 8.x-1.x branch for 90 days. That is, on 6 April, 2020, all support for JSON:API, not in Drupal core, will end. Please upgrade your sites accordingly.

Thanks to my fellow maintainers Gabe Sullice and Mateu Aguiló for writing this announcement!

2007 is the year of my first DrupalCon, and the year the #1 most wanted end-user feature was Better media handling. 2019 is the year that Drupal will finally have it. Doing things right takes time!

Back then I never would’ve believed I would someday play a small role in making it happen :)

Without further ado, and without using a mouse:

The text editor assisted in producing this HTML:

<p>Let's talk about llamas!</p>

<drupal-media alt="A beautiful llama!" data-entity-type="media" data-entity-uuid="84911dc4-c086-4781-afc3-eb49b7380ff5" class="align-center"></drupal-media>

<p>(I like llamas, okay?)</p>

If you’re wondering why something seemingly so simple could have taken such a long time, read on for a little bit of Drupal history! (By no means a complete history.)