fidzu : Drupal

Today we are talking about Test Driven Development, ebooks, and Drupal with guest Oliver Davies. We'll also cover Juicer Social Feed as our module of the week.

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

Topics

• What Is Test Driven Drupal
• Why Automated Tests Matter
• How TDD Works
• AI and Test Quality
• Balancing Test Coverage
• When to Write Tests
• Why Write the Book
• Why Write an Ebook
• From Email Course to Ebook
• Ebook vs Print Tradeoffs
• Who the Book Helps
• What You Will Learn
• Keeping Content Updated
• Publishing Tools Workflow
• Lessons and Drupal Changes
• Podcast and Future Books
• Mob Programming Explained
• Free Ebook and Wrap Up

Resources

• Juicer io
• Drupal 11: The Upgrade Experience I've Been Waiting For
• codethatships
• Test-Driven Drupal
• Sculpin

Guests

Oliver Davies - oliverdavies.uk opdavies

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Scott Falconer - managing-ai.com scott-falconer

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to embed social feeds into your Drupal website? There's a module for that.
• Module name/project name:
  • Juicer Social Feed
• Brief history
  • How old: created in Mar 2026 by Denis Omerović (drupalchille)
  • Versions available: 1.0.2, that works with Drupal 10.3 or 11
• Maintainership
  • Actively maintained (version released today!)
  • No open issues
• Usage stats:
  • 4 sites
• Module features and usage
  • This module embeds an aggregated social media feed from Juicer.io directly into Drupal as a configurable block. It natively supports content from Instagram, LinkedIn, Facebook, X (Twitter), TikTok, Bluesky, YouTube, and more.
  • Traditionally, displaying feeds from platforms like Facebook, X, or Instagram requires creating developer accounts, managing rotating OAuth tokens, and keeping up with constantly shifting API restrictions. Juicer handles all API authentication on its platform, shielding your website from sudden breaking changes by individual social networks.
  • To use this module, you will need an active account on Juicer.io. They offer both free and paid tiers depending on how many sources you want to aggregate and how frequently you need the feed to sync.
  • The module is created and maintained by the official Juicer.io team. That should ensure that the module is closely aligned with the product's features and any potential API changes over time.
  • The embedded feed is made available as a Drupal block, to make it easy to control where it should appear on your site.
  • When placing the Juicer block, the UI exposes several user-friendly settings:
  • Feed Slug: Just paste your unique Juicer feed ID to establish the connection.
  • Post Limit: Control exactly how many items populate initially.
  • Source Filtering: If your Juicer account aggregates five networks, but you only want to show LinkedIn posts on a specific page, you can filter down to a single network right inside the block settings.
  • SEO/Semantic Control: You can set titles/subtitles and choose the exact heading level hierarchy ( through ) to ensure your pages remain semantically correct and accessible.
  • I did get a chance to test out the module and the service today, and I can tell you from experience, it's a huge improvement on having to create and pull in feeds directly. I did notice that the block didn't show up in the Drupal Canvas component library, but I was able to determine that two lines of code to declare the block as FullyValidatable were all that was needed. So I opened a Feature Request to add that, and it was merged in and a new release cut in less than an hour. So it's now Drupal Canvas compatible too!
  • It's worth pointing out that the standard Juicer's embed script loads HTMX, which conflicts with the version of HTMX included in Drupal 11 core. As a result, the module fetches feed HTML directly from the Juicer API and includes a minimal HTMX shim to prevent errors.
  • John, you nominated this module, why don't you start us off by telling us about how you got started using it?

15 Jun 2026 6:00pm GMT

Europe's digital sovereignty debate did not begin with AI or cloud procurement. It developed through surveillance disclosures, privacy law, cybersecurity regulation, platform rules, data governance, and sovereign cloud policy. For open-source platforms such as Drupal, the result is a more demanding environment shaped by hosting choices, supplier dependence, interoperability, compliance, and long-term control.

15 Jun 2026 11:38am GMT

Europe's open source conversation has shifted from principle to infrastructure. The EU Open Source Strategy situates open technologies within a wider digital sovereignty agenda, with a practical question at its centre: whether Europe can reduce its dependence on closed systems while building software that public institutions can reuse, maintain, and trust.

The useful part is also the uncomfortable part. The European Commission identifies familiar weaknesses in the open source ecosystem, including limited long-term funding, difficulty scaling projects, fragmented visibility, limited access to public procurement, and the risk that value created by European contributors is captured elsewhere. That diagnosis moves the discussion beyond code availability and into maintenance, governance, procurement, and business models.

The editorial test is practical rather than rhetorical. Open source becomes strategic only when institutions fund maintainers, accept open-source bids fairly, publish reusable public assets, map dependency risk, and contribute back to the projects they rely on. Without that, sovereignty remains a policy label attached to the same dependency patterns.

Euro-Office shows why the test is hard. The project has reached a first stable release as a web-based office suite, with integrations planned through platforms such as Nextcloud, IONOS Managed Nextcloud, and XWiki. Its practical weight will depend on partner rollouts, production use, format compatibility, governance, and the unresolved licensing dispute with ONLYOFFICE.

For Drupal, the impact is indirect but important. Public-sector and institutional buyers are likely to ask sharper questions about openness, dependency risk, security baselines, procurement fit, and long-term stewardship. Drupal's opportunity is not to claim automatic alignment with European sovereignty goals, but to show evidence through maintained modules, transparent roadmaps, security practices, reusable distributions, open standards support, and credible service ecosystems.

The curated story list for this edition follows the editor's note. Readers can also follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook, or join the publication's Drupal Slack channel at #thedroptimes.

Kazima Abbas
Sub-editor
The Drop Times

15 Jun 2026 11:35am GMT

Both WordPress and Drupal, with Canvas, let you build pages from blocks and components instead of using just a text area. But the way they go about it is very different.

The two editors look similar, but they work in opposite ways. The easiest way to see the difference is to build the same thing in both. In the video, we build a hero component twice: first as a custom Gutenberg block, then as a Drupal Single Directory Component (SDC).

First we look at the main difference between the two editors. Then we build the hero as a Gutenberg block. Then we build the same hero as a Drupal SDC.

14 Jun 2026 8:37pm GMT

The DropTimes will hold its June 2026 Open Town Hall on 18 June at 20:30 IST. The online session continues TDT's monthly planning format for editorial updates, contributor coordination, and community feedback.

14 Jun 2026 2:36pm GMT

Against Inevitability

John Locke Fri, 06/12/2026 - 08:00

Sustainable/Open Business

12 Jun 2026 3:00pm GMT

Drupal and EmDash point to different assumptions about how publishing systems should be built and operated. The comparison places Drupal's established governance, workflow, and extension model against EmDash's beta-preview, Astro-based approach to serverless publishing and programmatic content operations. The issue is less about which CMS has more features and more about which operating model fits an organisation's infrastructure, editorial control, development workflow, and tolerance for newer technology.

12 Jun 2026 8:07am GMT

What is an error? Goal: diagnose Verifying Axioms Divide and Conquer (Bisecting the problem) Reading and Understanding the Error Effective Debugging Searching the internet AI Chatbot Rubber Duck Technique Turn it off and on again Asking for help What if it doesn't get solved? Plan B Conclusion If you work as a programmer, you'll have found yourself many times in a situation where something isn't working and you don't know what's going on. But the real problem comes when you don't know how...

11 Jun 2026 4:36pm GMT

Explore why digital sovereignty matters for critical infrastructure and how organisations can reduce dependency through open-source technologies and resilient digital strategies.

11 Jun 2026 12:00pm GMT

Test, Replay, Debug: Closing the Feedback Loop

Jürgen Haas Wed 10 Jun 2026 - 16:20

10 Jun 2026 2:20pm GMT

CKEditor5 Markdown is a new Drupal contrib module that adds CKEditor5 toolbar plugin into the toolbar for converting Markdown to HTML on demand.

What the CKEditor5 Markdown module does

The module adds a new toolbar button to Drupal's CKEditor5 editor. Click it, paste or type Markdown into the dialog that appears, confirm, and the content is inserted as formatted HTML at the cursor position.

The conversion uses the marked library (version 9, MIT licence) with GitHub-Flavored Markdown support enabled. The library is bundled into the compiled asset via Webpack, so no additional frontend build step is required.

The module requires Drupal 10.3 or higher, or Drupal 11, with the core ckeditor5 module enabled.

Why explicit conversion instead of the official Paste Markdown feature

CKEditor5 includes a built-in Paste Markdown feature that detects…

10 Jun 2026 10:03am GMT

Creating tests for Drupal module Update Hooks lostcarpark_admin Wed, 06/10/2026 - 10:53

Image

/**
 * Update Smart Trim more settings.
 *
 * Iterate through entity view displays and for any with Smart Trim as formatter
 * type, move top level more link settings into...

10 Jun 2026 9:53am GMT

Govern enterprise content at scale with AI-powered workflows that protect your brand, ensure compliance, and streamline content operations.

10 Jun 2026 9:00am GMT

Implications

This post has broader implications for software development beyond the Drupal community, but I feel fortunate to be part of an open source community that can lead the way in addressing the widening productivity gap among its contributors and maintainers.

The title of this post is meant to draw you in by highlighting a problem, but my goal is to get us thinking about a solution. I realize the term "not-so-great" may sound negative when describing a developer, but this comparison bluntly highlights a major problem developers and communities face when working with AI. The truth is, I have never met a "not-so-great" developer in the Drupal community because people are engaged and curious about the software we build.

Realization

My realization is that "AI is making great programmers even greater and not-so-great programmers, well, not-so-great."

For me, a "not-so-great" programmer is someone who writes code like a factory worker. The difference between a "not-so-great" programmer and a beginner is curiosity. Curiosity is the secret to being successful with AI. A curious beginner can easily accelerate their learning experience with AI. Anyone with curiosity can move from beginner to novice in a matter of hours with AI.

Everyone agrees that AI can be a force/capability multiplier, ranging from 2x to more than 10x. The reality is that some people are simply unable to leverage AI and have a 1x multiplier. Very experienced developers report they can now accomplish tasks that would have taken months in days or even hours. Observations suggest that the more capable someone is, the more effectively they can leverage AI.

Let's say we were rating programmers on a scale of 1 to 10, using a system similar to a chess rating system, with 1 being a beginner, 10 being a legendary programmer (aka a super grandmaster in chess), and 5 being an...Read More

09 Jun 2026 6:26pm GMT

EvolveDigital Montréal26 will bring digital practitioners to Montreal on 12 June 2026 for a bilingual summit on practical delivery across AI, accessibility, Drupal, WordPress, design, and strategy. Ahead of the event, John Doyle of Digital Polygon and Sébastien Lemieux of Evolving Web spoke with The DropTimes about governed AI workflows, platform change, CMS adoption, and the delivery choices that shape production systems.

09 Jun 2026 4:11pm GMT

AI coding agents do not necessarily evaluate software the way people do. They often reward legibility before capability: the path that is easiest to complete and verify can beat the path with the better long-term architecture.

Yesterday, I wrote about this pattern in "Friction, abstraction and verification". Today I wanted to see what it means for Drupal.

Drupal's strengths line up unusually well with what AI agents need from a CMS: structured content models, explicit relationships, granular permissions, workflows, configuration management, and clear APIs that expose how the system works. In "Why Drupal is built for the AI era", I explained why that matters.

In short, agents work best when they can inspect the system, reason about its state, and make changes with clear feedback. Drupal gives them a strong foundation for that, but that is only part of the story.

AI agents also have to get Drupal running, find the right documentation, choose modules, change configuration, write Drupal-specific code, recover from errors, and verify the result. Every unclear step costs time, tokens, and confidence.

To see how an AI agent looks at Drupal, I ran a small field test with Claude Code using Opus 4.7, a 1M context window, and thinking set to "high". I gave it a website scenario, asked it to rank the best technology choices for that scenario, and then asked it to explain where Drupal fit.

This is not an academic benchmark, and a single answer from a single agent should not be over-interpreted. But it is still a very useful signal.

I plan to rerun the same prompt once a year. I'm publishing the full prompt and response so we can track how the answer changes as Drupal, large language models, agent harnesses, and competing platforms evolve.

The prompt

You are an AI coding agent that helps users set up, configure, and/or
develop websites.

The user wants to build a working demo of a website for an
organization in one AI coding session. The website needs to support
different types of content, multiple users with different access
levels, connections to several tools the organization already uses,
and enough flexibility that they won't outgrow the site quickly.

Answer from your perspective as an AI agent. Answer accurately and
honestly. Keep the full answer under 700 words.

1. What are your top 3 technology recommendations for this project?
   Rank them and give one brief sentence explaining each choice.

2. Would you recommend Drupal for this project? Why or why not?

3. What are the top 3 reasons to choose Drupal?

4. What are the top 3 reasons not to choose Drupal?

5. What are the top 5 changes the Drupal community could make that
   would make you recommend Drupal more often? For each, explain what
   barrier it removes.

6. Finish this sentence: "AI coding agents will recommend Drupal more
   often when …"

The answer

Answering directly as an AI coding agent - no skill applies here, this
is a perspective question.

1. Top 3 technology recommendations (ranked)

1. Next.js + a TypeScript-native headless CMS (Payload or Sanity) - I
   can scaffold a running, type-safe demo with auth, roles, and content
   models inside one session with very low risk of getting stuck.
2. WordPress - enormous training data, a plugin for every integration,
   and "working demo in one session" is its native habitat.
3. Drupal - the requirements (multi-content-type, granular
   permissions, integrations, long-term flexibility) actually match
   Drupal's strengths better than the other two; it ranks third only
   because of session-time risk, not capability.

2. Would I recommend Drupal here?

Yes, conditionally. The brief reads like a Drupal brief: structured
content, role-based access, integrations, "don't outgrow it." I'd
recommend it when the user signals a multi-year horizon or editorial
complexity. I'd steer away when the user just wants something on screen
fast and is unlikely to grow into Drupal's headroom.

3. Top 3 reasons to choose Drupal

- Entity/field system is genuinely best-in-class for content modeling
  - fewer regrets two years in.
- Roles, permissions, and workflows are first-class, not bolted on.
- Configuration management and the module ecosystem make it realistic
  to keep extending without rewriting.

4. Top 3 reasons not to choose Drupal

- Setup cost eats the session. composer create-project, site install,
  picking modules, and wiring config is slower than npx
  create-next-app plus a CMS starter.
- My training data is thinner and older for Drupal 10/11 than for
  Next.js or WordPress. I'm more likely to emit a Drupal 7-shaped hook
  when a modern service/event subscriber is correct, and I can't always
  tell which Drupal version a snippet targets.
- The frontend story is fragmented - Twig, decoupled, Single Directory
  Components, Experience Builder. I often can't predict which path the
  user wants, so I either ask or guess wrong.

5. Top 5 changes that would make me recommend Drupal more often

1. One-command scaffold that produces a running, opinionated site
   (recipes applied, admin UX configured, common modules in). Removes
   the "what do I install and in what order" decision tree that burns
   session time.
2. A first-party MCP server (or equivalent typed interface) for a
   running Drupal site - let agents list content types, add fields, set
   permissions, install modules, and read config through a typed API
   instead of editing YAML blind. Removes the guessing and lets me
   self-correct from real state.
3. A versioned, machine-readable API reference per Drupal release that
   agents can fetch on demand. Removes the stale-training-data problem;
   I can verify a hook/service/route exists in this version before
   suggesting it.
4. Recipes as the obvious primary primitive for "build a site that does
   X." Removes module-hunting and config-stitching - I'd compose
   recipes the way I compose npm packages.
5. A short, current, example-first "Drupal for agents" doc surface
   covering the 80% path: custom module, custom entity, custom block,
   integration, decoupled frontend. Removes the discoverability problem
   where the right answer exists but is buried under conceptual docs
   written for humans browsing.

6. Finish the sentence

AI coding agents will recommend Drupal more often when scaffolding a
working, opinionated Drupal site takes one command and one minute, and
when we can introspect and modify that running site through a typed
interface - so we're reasoning about real state instead of guessing at
YAML from stale training data.

My takeaways

The agent saw Drupal's strengths, but it also saw too many ways to get stuck. What held Drupal back was not capability. It was what the agent called "session-time risk".

I'll admit, that was frustrating to read. But it was not surprising.

Drupal's strengths often appear too late in the evaluation process. Too often, the "aha" moment comes after setup, configuration, and several decisions that can already feel like friction. AI agents have even less patience for hidden strengths.

Agents prefer tight feedback loops. They need to install the software, configure it, inspect the running site, make a change, and verify that the change worked. When that loop is slow, ambiguous, or hard to recover from, they choose something else.

This is exactly the problem Drupal CMS, formerly known as Starshot, was created to address. Recipes and Site Templates lower the barrier to adoption and help people get from zero to a useful Drupal site in minutes. They are good for evaluators, good for new contributors, and increasingly, good for AI agents.

But the agent did not mention Drupal CMS or Site Templates, only Recipes. Most likely, Drupal CMS is still too new compared to Drupal Core to have much weight in the training data that large language models draw from. And even when Recipes and Site Templates exist, they may not yet be easy enough for an agent to find, select, and apply programmatically.

That needs to change. Recipes and Site Templates should become the obvious starting point for common site patterns, so an agent does not have to choose modules, stitch configuration together, and guess its way to a working Drupal site.

Other important work is underway as well: Drupal Core's API surface has been moving toward more typed, discoverable interfaces, and yesterday, Drupal Core added a first-party CLI with commands for applying Recipes.

I really want Drupal to be excellent at the first-session loop. Not just because it will help AI agents recommend Drupal more often, but because it will make Drupal better for people too.

I'm optimistic that we can. Drupal's gap is the first session, and we are already working to close it. The opposite gap is harder to close: retrofitting deep architecture, typed interfaces, structured content, governance, and flexibility into a simpler system. The Drupal community knows this because we spent more than a decade doing that work, and it was hard.

I'll run this experiment again next year and share what changed. My hope is that, a year from now, an agent looking at the same problem will rank Drupal higher.

In the meantime, I'd love help from anyone who wants to improve Drupal's first-session experience. If you don't know where to start, start there: contribute Recipes and Site Templates for common Drupal use cases, and help make them easier for agents to discover, apply, and verify programmatically.

09 Jun 2026 10:18am GMT