fidzu : cms

12 Jan 2026 7:55pm GMT

Today we are talking about Recording Podcasts, The tech used, and How Drupal Can help with guest Stephen Cross. We'll also cover Chosen as our module of the week.

For show notes visit: https://www.talkingDrupal.com/535

Topics

• Podcasting and Second Signal Media
• Evolution of Podcasting
• Tech Essentials for Podcasting
• The CEO's Video Strategy Transformation
• Overcoming the Fear of Speaking on Camera
• The Importance of Consistency in Content Creation
• Editing vs. Authenticity in Video Content
• Choosing the Right Environment and Equipment
• Setting Realistic Goals for Your Podcast
• Recording Workflow Recommendations
• Tools and Tips for Improving Audio Quality

Resources

• Basic Editing with Kdenlive
• Audio clean-up tools
• Izotope
• Secret sounds

Guests

Stephen Cross - stephencross

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Andy Giles - dripyard.com andyg5000

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to give users on your Drupal site a more intuitive alternative to native HTML multiselect widgets? There's a module for that.
• Module name/project name:
  • Chosen
• Brief history
  • How old: created in Jul 2011 by shadcn but recent releases are by Bálint Nagy (nagy.balint) of Hungary
  • Versions available: 3.0.6, 4.0.3, and 5.0.3, the last of which works with Drupal 10.2 or 11
• Maintainership
  • Actively maintained
  • Security coverage
  • Test coverage
  • Number of open issues: 221 open issues, 4 of which are bugs against the 5.x branch
• Usage stats:
  • Almost 38,000 sites
• Module features and usage
  • With the module installed, your Drupal site will selectively replace select elements with a more intuitive widget, leveraging the Chosen library. In the module's configuration you can specify how many options should trigger Chosen, and also specify form field selectors to explicitly include or exclude.
  • The three active branches of the module reflect usage of different forks of the Chosen library. Notably, the 5.x versions use a fork that no longer requires jQuery, and allows Chosen to be enabled for mobile devices.
  • In addition to the module configuration, you can also force a custom form's select element to use the Chosen library simply by adding the "chosen-select" class to the form array.
  • Back in episode #409 we talked about Tagify, which in some ways is similar, but is designed specifically to work with entity reference fields. That makes it less "general purpose", though Tagify does also include some additional capabilities, such as being able to include labels or icons on results based on a property of the result.
  • Years ago I used another popular project called Select2 for turning multiselects into listboxes that included a search filter, but that project relied on a library that required jQuery but is incompatible with jQuery 4. So, Select2 has been officially replaced by Tagify, but Chosen could also be useful if your field is not an entity reference.
  • There are a variety similar modules you can also look at, including Choices.js, Selectize, and Selectify, but Chosen is by far the most widely used, even if you're only looking at numbers for the 5.x branch

12 Jan 2026 7:00pm GMT

Twenty years ago, I argued passionately that breaking backward compatibility was one of Drupal's core values:

The only viable long-term strategy is to focus exclusively on getting the technology right. The only way to stay competitive is to have the best product. [...] If you start dragging baggage along, your product will, eventually, be replaced by something that offers the same functionality but without the baggage.

I warned that preserving backward compatibility would be the beginning of the end:

I fear that this will be the end of Drupal as we have come to know it. Probably not immediately, maybe not even for several years, but eventually Drupal will be surpassed by technology that can respond more quickly to change.

Twenty years later, I have to admit I was wrong.

So what changed?

In 2006, Drupal had almost no automated tests. We couldn't commit to backward compatibility because we had no way to know when we broke it. Two years later in 2008, we embraced test-driven development.

By 2016, we had built up significant test coverage, and with that foundation we adopted semantic versioning and committed to backward compatibility. Semantic versioning gave us a deprecation policy. We can mark old code for removal and clear it out every two years with each major release. The baggage I feared never really accumulated.

Today, according to the Drupal Core Metrics dashboard, Drupal Core has more than twice as much test code as production code. I didn't fully appreciate how much that would change things. You can't promise backward compatibility at Drupal's scale without extensive automated testing.

Our upgrades are now the smoothest in the project's history. And best of all, Drupal didn't end. It's still a top choice for organizations that need flexibility, security, and scale.

I recently came across an interview with Richard Hipp, SQLite's creator. SQLite has 90 million lines of tests for 150,000 lines of production code. That is a whopping 600-to-1 ratio. Hipp calls it "aviation-grade testing" and says it's what lets a team of three maintain billions of installations.

I suspect our test coverage will continue to grow over time. But Drupal can't match SQLite's ratio, and it doesn't need to. What matters is that we built the habits and discipline that work for us.

In 2006, I thought backward compatibility would be the end of Drupal. In 2026, I think it might be what keeps us here for another twenty years.

Thank you to everyone who wrote those tests.

It does make me wonder: what are we wrong about now? What should we be investing in today that will slowly reshape how we work and become an obvious advantage twenty years from now? And who is already saying it while the rest of us aren't listening?

12 Jan 2026 5:07pm GMT