From time to time I get some really good and motivating feedback on the product I have built, violinist.io. And I want to start this post, which will also have a huge feature announcement, by mentioning a couple of them:

It was wonderfully painless (...) I don’t think I’ve ever experienced a faster setup of a CI tool — I think I said “wait that’s all?” out loud!

overall did the trick of what I was looking for and was very very fast

In other words, easy to set up, and fast results.

Well, today I want to share another product update that will make it theoretically even faster to set up and get results. But first allow me to provide a bit of background on why this new feature came to be.

One recurring question we get is regarding two avenues of a similar aspect:

• Does our code have to make its way to violinist.io infrastructure for us to be able to use the service?
• Can violinist.io access our Self Hosted GitLab which is locked down with a required VPN connection

They might differ a bit in wording or actual focus, but they usually boil down to one of these. And from time to time we find a compromise to both of these questions together, and the person contacting us turn into happy customers. But from time to time these questions also become the actual blocker for them to start using violinist.io. But now, at least, we have an alternative that covers both of these use cases: Self hosting violinist.io runners!

And here is why I am mentioning the feedback regarding quick onboarding in the context of this product announcement. You can literally start an update check with one docker command:

This will run the same update job as if it were running on violinist.io, only using your own computer!

Of course, this in itself is not super useful. Avoiding running commands on your computer is the whole point of using an automatic update service like violinist.io, but now you can do cool stuff like:

• Run the same update jobs as violinist.io without any code entering any third party infrastructure
• Run jobs your CI infrastructure of choice. GitHub Actions, CircleCI, Bitbucket pipelines, Self Hosted GitLab, your totally locked down VPN protected GitLab instance that has a totally locked down Jenkins server. And so on
• Decide your own intervals for running them, probably inside said CI infrastructure. Daily jobs? Weekly jobs? Hourly jobs? Not a problem.
• Compose CI workflows that can do all your repositories in a matrix, all on the same schedule, if useful?
• Expose a webhook to trigger jobs, and run them when new items appear in the Drupal Security Announcements  RSS feed
• And a million other things probably? You decide!

If this sounds useful to you, or your organization, please don’t hesitate to reach out for a free trial. In fact, in the name of smooth onboarding, here is an absolutely free trial for you already without reaching out (as long as you are reading and using this within 2 months of this blog post): A totally free license key, valid for all repositories for 2 months from today (valid until 2024-11-19T19:20:19+01:00):

Now all you need is a repository and a PAT (Personal Access Token), and you are off on your new automatic update adventure. For a bit more documentation than this sparse promotional blog post, please visit the container repository.

Lastly, there are so much more I want to share and address about this. For example the aspect of open source in all of this, the differences between this and violinist.io (the SaaS), the licencing and pricing aspect. But those are all blog posts on their own. For now, I hope you will try it out if it’s useful, and that you want to connect should you have any questions or concerns. Here in the comments, or by reaching out.

Let’s close up this blog post with an animated gif of "runners".
 

As someone who works on multiple Drupal applications, I know it can be tricky to keep on top of all the available updates.

So, I'm building a SaaS project to display all your available updates in one place.

If you're a freelancer or work for an agency or any team that works on multiple Drupal applications, this could be useful for you.

If this is you, I'm looking for alpha testers to help me test it.

If you're interested, reply and let me know.

Next week is DrupalCon in Barcelona.

I'm not speaking this year but if you're there and want to discuss automated testing, test-driven development, static analysis, Sculpin, Tailwind CSS, Nix, or anything else, I'll be there all week and would love to meet up and chat.

I recently sent a database to a client whose new Drupal website I'm building.

I'd populated it with some default users, nodes and menu links that they'd be able to review after they import the database into their hosting.

That worked well, but I've also recently been using the Default Content module which exports entities into YAML and saves them as code alongside the configuration.

Now I can install the website from scratch using the exported configuration to re-add the content types, block types, etc, and by enabling a custom module, all the default content will also be recreated.

I can tear the site down now and rebuild it as often as I like and avoid contaminating my environment with any rogue configuration or content changes.

Everything is reproducible.

I also wouldn't have needed to send the database to the client. They could have installed Drupal and followed the same steps I would do locally and got exactly the same result.

I like this approach and can see me using it more on future projects.

Meet the blökkli starterkit for Drupal.

Spin-up a preconfigured Decoupled Drupal setup with Nuxt 3, GraphQL and blökkli to get started developing within seconds.

Enjoy the powerful and elegant editing experience offered by blokk.li, a fully interactive in-page editor based on the well-known Drupal Paragraphs module.

• Out of the box support experience with local setup using Lando or DDEV

• Drupal Backend Setup with GraphQL, Paragraphs and Paragraphs blokk.li module enabled

• +40 Vue Components and Composables ready to build paragraph based Drupal websites

• Basic Frontend setup with Nuxt 3 and GraphQL Middleware included

• Multilanguage support with language negotation and translation support

• Key-based Texts managed in Drupal combined with translation extraction in the frontend

• SVG Icon Sprite generation with Drupal Media Library integration

• rokka.io Image CDN integration and Drupal media library integration

• Reverse proxy configuration generator included

We are looking forward to getting your feedback in the issue queue and on slack.

If you happen to be in Barcelona for DrupalCon, find us at the following dates:

• Session: Large-scale content creation with Drupal — Delights, Pitfalls and support structures to help editors by Jonathan Noack (Jonock), Thomas Nagy (Thomnagy)
  Wednesday, September 25, 2024 - 11:30 to 12:15
  Room 1 (133-134)

• BoF: blökkli - Demo, Q&A for the Interactive page building experience with Nuxt
  Thursday, September 26, 2024 - 16:30 to 17:15
  Room BoF 1 (118)

Do one thing, do it well - this week I spent most of my time creating a live preview module for microsites.

Increasing work productivity and effectiveness is key in many professions, including Drupal developers. One of the tools that allows you to achieve this is the Drupal Admin Toolbar module. Thanks to it, you can easily access key administrative functions and navigate through admin panels. In this article, you will learn more about the Drupal Admin Toolbar features, benefits, and configuration methods. You will discover the possibilities that this tool has to offer and how it can streamline your Drupal-based website management.

We matched last week’s record: again 26 MRs merged! :D

Experience Builder (XB) already had a hierarchy view for a while. Lauri worked with the Acquia UX team to change that to match the more common “layers” pattern (used in Photoshop and Figma). Harumi “hooroomoo” Jang made that a reality:

Ben “bnjmnm” Mullins and I (mostly Ben!) collaborated on integrating Media Library! This required expanding some of the lower-level XB infrastructure but most importantly, it means we proved Drupal core’s most complex field widget 1 can work, which is an important milestone:

During the product research phase, Lauri identified that it’s important for Content Creators’ productivity to not have to craft the same combinations of components over and over again. Lauri and the Acquia UX team have labeled such combinations “sections” — similar to Layout Builder’s sections. Creating new ones is out-of-scope for 0.1.0, but conveying what that UX would feel like is in scope. So, Jesse “jessebaker” Baker and Bálint “balintbrews” Kléri worked on a client-only implementation that hardcodes a single section (again: for now):

It takes no designer or expert user to observe that in the above images, the drag-and-drop UX and visualization can be improved. The Figma designs do not have an answer for this. But … we have Bálint! :D He thought, tinkered, experimented and gave the Drupal ecosystem this delightful UX:

… which subsequently enabled him together with danielveza and Jesse to also highlight the slot that a component is about to be placed in:

If that isn’t an epic leap forward on the front end, then I don’t know what is! :D On so many fronts, dragging and dropping components became not only more usable, but also enjoyable.

It doesn’t end there, though:

• Utkarsh “utkarsh_33” updated the styling of text inputs, boolean toggle, etc to match the designs, by mapping more form elements to XB’s React components using the semi-coupled theme engine that Ben introduced in week 10
• Utkarsh, fazilitehreem and Jesse made deleting component instances more intuitive: you can delete the selected one using the keyboard now
• fazilitehreem, Utkarsh and Jesse added right-click support to the selected component
• Jesse fixed a crucial bug that prevented slots in freshly dropped components from working

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!

Back end

Comparatively, the back end progress this week was very non-visual… with one exception: Ted “tedbow” Bowman and I fixed the visually broken “image” components — this was caused by the buggy PoC code I wrote 14 weeks ago — finally this rose to the top of the priorities!

Feliksas “f.mazeikis” Mazeikis and I discovered a critical bug in the auto-generated Component config entities for Single-Directory Components (SDCs) meeting the criteria: the field type and widget for optional props were missing. How could this happen? Because we’ve been racing ahead to make functionality exist, without the foundations being sufficiently thoroughly checked: the Component config entity’s schema is littered with @todos for adding more validation constraints. One of those would’ve prevented this problem … so we fixed not only the problem at hand, but also ensured that it could never reoccur, by introducing a KeyForEverySdcProp validation constraint first, and then fixing the auto-generation logic.

Dave “longwave” Long, Lee “larowlan” Rowlands and Deepak “deepakkm” Mishra updated XB to declare a runtime rather than development dependency on justinrainbow/json-schema — this is what the SDC subsystem uses to validate that the provided props values are considered acceptable by an SDC, and that’s why XB uses it to validate an XB field is valid (i.e. every SDC in the component tree must be renderable and hence trigger no exceptions for provided SDC props values). So that should’ve been marked as an explicit dependency months ago, but we didn’t spot that. Easy enough!

However … Lee pointed out that this is actually unacceptable for Drupal sites that use JSON:API in production, because it causes automatic validation for every JSON:API response against the JSON:API spec if assertions are enabled. That results in a significant performance regression. That being said, having assertions enabled is also a violation of Drupal best practices (and PHP best practices). Still, Drupal should help users even when they ignore/are unaware of best practices, so the XB module warns on the status report when best practices are violated. A core issue was created to improve this upstream: #3472008.

What a week! :D

Week 17 was September 2–8, 2024.

1. For now, that Media Library dialog looks rather stark, because it is, well … using the Stark theme. We plan to load the Claro/Gin styles, but to ensure style isolation, that requires some non-trivial <iframe> shenanigans in #3471978 to avoid loading that CSS/JS in the context of the XB React app. ↩︎

• Drupal
• Acquia
• Experience Builder

• The new "layers" panel, which also allows moving components.
• Using an image from the Media Library.
• The sole "section" available right now: one that contains two predefined hero components.
• A blue line now precedes the ghost while dragging, which conveys both the current position and the target position upon dropping
• The precise destination of a component is has a thick blue line, the containing slot gets a thin outline.
• Images now render as expected in Experience Builder.

Migrating your content to a new CMS can feel daunting. You have years and years of content to sort through and move over, and you have no idea what obstacles might be hiding in the weeds. In the back of your mind, the question looms: “Do we really need all of this content?”

You don’t want to waste time. But you also don’t want to miss anything important.