Like a lot of other people in the Drupal community, I exclusively use DDEV for local development. I am regularly impressed by the breadth of features it offers out-of-the-box, and the add-on architecture means you can easily bring in additional capabilities as you need them. Recently, I even decided to vibe-code my own add-on to make it easy to run code validation checks and automated tests locally before pushing code.
In the first instalment of this blog series I talked about the technical aspects of my recording setup. I thought I should also talk about some things I’ve done (and some additional things you can do) to optimize the physical space for recording.
The Voice of the Driesnote Demos
For a couple of years now, I’ve been fortunate to help produce the demo videos in Driesnote presentations, often one of the more anticipated parts of each DrupalCon. Sometimes people assume that because they can hear my voice, I am responsible for the compelling story these videos tell. That’s flattering, but the truth is that each time there is a team of people whose combined efforts come together to produce what can be seen in the videos.
As I made my way home from my first in-person DrupalCamp Asheville, I was still awash in warm memories of lively discussions and laughs with a Drupal community that increasingly feels like an extended family. I got to catch up with good friends I've known for years, and meet new people I hope to see again.
Earlier this year I made the difficult decision to step down as Events Recipe track lead in the Starshot initiative. Having successfully delivered the requirements for a 1.0 release of Drupal CMS, I decided my skills and expertise could have more impact elsewhere.
I loved the opportunity to collaborate with so many of the best minds in the Drupal community. But there was important work needed on a different initiative, the Drupal Event Platform.
In my recent work on the Drupal Event Platform, one of the most ambitious changes has been changing the architecture to support multiple events. That means that an annual Drupal camp can retain the content of previous years while collecting session submissions for an upcoming event. It also means that the platform can support multiple events per year if needed, similar to events.drupal.org.
Since I started working on the Drupal Event Platform initiative, a request that I've heard more than once is for a configurable theme. I have considered making a subtheme of Olivero that would expand the number of configuration options available, to allow for more options in the overall site styling, potentially including things like spacing, border-widths, and border-radius.
In my last update about the Drupal CMS Events Recipe, I shared my concerns about the Fullcalendar View module, and in particular the move towards a paid model for sites to make use of commonly-requested features, even those that have seen patches posted by the community. This post will give a deeper dive on the progress to date, how the newer FullCalendar module compares, and a glimpse at the road ahead.
With DrupalCon Barcelona fast approaching I thought it was time to share some more updates on the progress of the events recipe for Drupal CMS a.k.a. the Starshot initiative.
When I first heard the vision for Starshot (now Drupal CMS), I knew exactly how I wanted to contribute. For years I have been working on trying to make it easier to quickly build Drupal sites following established best practices. I had been working on a set of modules I called Configuration Kits, but they were conceptually very similar to Recipes, albeit in a simpler (and less flexible) form.