I had great fun today expanding what was a proof-of-concept module from last year into a very usable live preview module for LGD Microsites.

Today we are talking about The Config Actions System, What it does, and how it helps with Drupal Recipes with guests Alex Pott and Adam Globus-Hoenich. We’ll also cover the Events recipe as our module of the week.

For show notes visit: www.talkingDrupal.com/467

• Explain Config Actions
• Is this related to the Actions UI
• How are config actions used in Drupal
• How will the average user interact with Config Actions
• What does non-desctructive mean
• Where did the Config Action system come from
• Future of the Config Action system
• How can people help out
• How does the Config Action system help with Drupal CMS

• Event platform
• Config action list

Alex Pott - alexpott Adam Globus-Hoenich - phenaproxima

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Nate Dentzau - dentzau.com nathandentzau

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to set up and configure a robust events system in your Drupal website, in just a few seconds? There’s a recipe for that.
• Module name/project name:
  • Events
• Brief history
  • How old: originally created in Mar 2013 as a distribution, but reborn as a recipe in July 2024
  • Versions available: 1.0.0-alpha3, compatible with Drupal 10.3 and 11
• Maintainership
  • Actively maintained
  • Security coverage? - no stable release
  • Documentation in the works
  • Number of open issues: 1 open issue, which is a bug
• Usage stats: not tracked for recipes
• Maintainer(s): mandclu
• Module features and usage
  • Listeners probably won’t be surprised to hear that Smart Date is at the heart of what you’ll get when you apply the Events recipe
  • You will have an Event content type, and a view to list upcoming and past events
  • The recipe will also set up add-to-calendar links on your event page, making it easy for your site visitors to be reminded of when your event will take place
  • There are companion recipes to add a calendar view, to be able to associate locations (with maps), and to add event registration
  • A modified version of the Events recipe has already been integrated into Drupal CMS, so it will be even easier to apply for a site based on that
  • Internally it makes use of the createIfNotExists and setComponents config actions, which is why I thought it would be relevant to today’s discussion

#OpenDevShop failed because it tried to solve too many problems at the same time.

This directed the energy away from designing for the future. When the future arrived, it was wholly unprepared.

I saw the potential to make #Aegir an all-in-one management console for all your web tech, so I created server management things, and local CLI things, and other silly, not so useful things.

DevShop became a huge burden. Unmaintainable. Un-upgradable. Working untold unpaid hours, self-funded travel and speaking took a major toll on my life, financially and personally.

This is the third article in a series of articles about the Batch API in Drupal. The Batch API is a system in Drupal that allows data to be processed in small chunks in order to prevent timeout errors or memory problems.

So far in this series we have looked at creating a batch process using a form and then creating a batch class so that batches can be run through Drush. Both of these examples used the Batch API to run a set number of items through a set number of process function callbacks. When setting up the batch run we created a list of items that we wanted to process and then split this list up into chunks, each chunk being sent to a batch process callback.

There is another way to set up the Batch API that will run the same number of operations without defining how many times we want to run them first. This is possible by using the "finished" setting in the batch context.

Let's create a batch process that we can run and control using the finished setting.

Setting Up

First we need to create a batch process that will accept the array we want to process. This is the same array as we have processed in the last two articles, but in this case we are passing the entire array to a single callback via the addOperation() method of the BatchBuilder class.

Read more

This week, I spoke with Eirik Morland again on the Beyond Blocks podcast about recent improvements to violinist.io, such as team/multi-user subscriptions.

Listen to the episode now.

I was great to speak to Eirik again and for him to be the first returning guest on the podcast.

Listen to the first episode with Eirik.

A new record week: 26 MRs merged! :D Too much to cover, so going forward, I will only write about the most notable changes.

The simplified zoom interface landed thanks to Jesse “jessebaker” Baker and Gaurav “gauravvvv” — with not only better controls, but also a much smoother UX:

Bálint “balintbrews” Kléri, Jesse and Ben “bnjmnm” Mullins integrated the existing “undo” functionality with the component props form, resulting in the UX you’d hope:

Your browser does not support playing videos. You can download it instead.

Now that many fundamental pieces exist, it’s time to build upon the foundations that we have. Five weeks ago, Ben added Redux integration to the component props form, resulting in live updates. That started out with a limited set of form elements supported. Harumi “hooroomoo” Jang added support for one more this week: <select>.

(By the way: Bálint’s epic video showing undo/redo above? That’s also powered by the Redux integration!)

Bálint and Gaurav improved the UX by removing six lines of CSS: instead of an abstract placeholder being dragged and visualized in the currently hovered drop target, now a ghost of the component being moved is visible:

Two weeks ago, we gained support for actual trees. This revealed a number of bugs in the UI that had up until that time, been ahead of the back end. Another one of those was squashed this week by Bálint, Ted and I: you can now actually drag components into empty slots :D

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!

Empowering SDC developers

Less visible, but equally important because it boosts the productivity of the fine folks working on the Starshot Demo Design System by making XB be more explicit about what Single-Directory Components (SDCs) prop shapes it provides a complete UX for. Since last week, a sibling Component config entity is auto-generated for every SDC meeting the minimum criteria. This week, Feliksas “f.mazeikis” Mazeikis expanded the list of criteria:

1. Since #3469461, any SDCs that we know for sure won’t work well in XB (yet!) no longer show up in the XB UI. (In more detail: when we have no way to store a particular prop shape yet: XB does not yet support type: array prop shapes yet, for example.)
2. Since #3470424, SDCs marked as obsolete won’t get a Component config entity auto-created. But if it already exists (and hence may be in use), the config entity is not deleted, just disabled.

Evidently that could lead to surprising situations, especially while developing SDCs. So, he’ll be adding a UI that lists the reason for an SDC not being available in XB next.

In the background, back end folks empowering the front end

Ted “tedbow” Bowman helped the back end race ahead of the front end: while we don’t have designs for it yet (nor capacity to build it before DrupalCon if they would suddenly exist), there now is an HTTP API to get a list of viable candidate field properties that are able to correctly populate a particular component prop. These are what in the current XB terminology are called dynamic prop sources 1 2.

Travis “traviscarden” Carden and I made XB’s use of OpenAPI go much further than it did when it landed 3 weeks ago): rather than only validating API response bodies, it now also validates request bodies — hence catching an entire category of bugs on the client-side automatically. Clearer errors = faster iteration!

Week 16 was August 26–September 1, 2024.

1. Dynamic Prop Sources are similar to Drupal’s tokens, but are more precise, and support more than only strings, because SDC props often require more complex shapes than just strings. ↩︎

2. This is the shape matching from ~3 months ago made available to the client side. ↩︎

• Drupal
• Acquia
• Experience Builder

• Smooth zoom with pinch and using the slider!
• Real-time updates of the props form and preview when undoing.
• Ghost of the component at the drop target: better visualization of what is about to happen.
• SDC prop shapes using `enum` now work thanks to expanded Redux integration.

If you've experienced issues or are worried about deploying changes to production, on a Friday or another day, when did you last deploy something?

Can you make deployments smaller and more frequent?

Deploying regularly makes each deployment less risky and having a smaller changeset makes it easier to find and fix any issues that arise.

I'm much happier deploying to production if I've already done so that day, or at least that week.

Any time more than that, or if the changeset is large, the more likely there will be issues and the longer it will take to resolve them.