Protecting your Drupal sites from unexpected dependency issues requires a proactive approach. This article reveals our strategy for continuously monitoring a suite of reference Drupal sites – automatically updated every hour – to detect runtime problems stemming from dependency updates. We’ll demonstrate how to identify PHP errors, styling issues, and even frontend JavaScript errors that often go unnoticed, ensuring a smooth and reliable experience for your Drupal users.

Community First, Business Second, Build Everything with Drupal

The enthusiastic response to our Birds of a Feather (BOF) session on "The Future of Drupal Economy" at DrupalCon Atlanta was nothing short of inspiring. First, I want to express my sincere gratitude to everyone who took the time to attend and contribute to this critical conversation. When we had to move to a larger room to accommodate over 100 participants, it became clear that these discussions about Drupal's economic future resonate deeply with our community.

Beyond Identifying Issues: Time for Solutions

Our community knows well the challenges we face. We all recognize the issues, and now is the time to move beyond merely identifying problems to actively crafting solutions.

The strategic shifts highlighted in the Starshot (now Drupal CMS) initiative represent a pivotal moment for our ecosystem. Now, we have the opportunity to build upon this momentum and address fundamental questions about how we support and grow our economy.

Supporting the Drupal Association's Revenue Goals

I want to acknowledge the Drupal Association's critical need for sustainable revenue streams. The DA faces the challenging task of supporting our infrastructure, organizing events, and guiding initiatives like Drupal CMS - all while balancing the community's needs with financial realities.

We find ourselves in an interesting position: we need large agencies' substantial support now to help the DA reach its goals of expanding the Certified Partner program and increasing revenue. However, the long-term vision should be creating self-sustaining systems where this intense dependency becomes less necessary.

It's encouraging to see the DA taking a more active leadership role in this space. The community's evolving perspective has allowed the DA to expand beyond just maintaining Drupal.org and organizing DrupalCon. This shift represents an important evolution that deserves our support.

Community-Driven Solutions

I'd like to propose several concrete solutions that could transform Drupal's ecosystem while supporting the DA's revenue goals:

1. Regionalized Official DrupalCons

As I mentioned during the Atlanta board meeting, Latin America is ready to support regional DrupalCon events. These events should test more business-oriented approaches alongside their developer focus, without abandoning the heart of the event as a time to work together on the project.

Regional events can serve as powerful business development platforms when structured to connect service providers with potential clients in their economic context.

These events would acknowledge the different economic realities across regions. What constitutes a "small," "medium," or "enterprise" project varies dramatically between markets. Adapting the DrupalCon model to regional needs creates opportunities for businesses of all sizes in their appropriate economic contexts.

2. Drupal.org as the Source of Truth

Drupal's contribution credit system is already unique in the open source world for how it tracks and attributes various forms of contribution. We should build upon this foundation to position Drupal.org as the definitive source of truth for everything Drupal-related. From identifying qualified developers to finding appropriate partner agencies, Drupal.org should be the central hub.

When businesses need Drupal expertise, Drupal.org should be their first destination. Not third-party job boards. Not general search engines. This transition creates natural economic incentives for contribution while connecting clients with service providers who have demonstrated their commitment to the project.

This would also significantly enhance the value of the Certified Drupal Partner program. The DA would now have something valuable to offer partners: qualified leads from businesses looking for Drupal expertise.

3. Community-Driven Certification Framework

Here's where I see tremendous potential: I believe a community-led certification system could be transformative for positioning Drupal.org as the central hub for Drupal expertise. But importantly, this must start as a community initiative rather than immediately becoming a DA responsibility.

This idea comes from my personal experience in education. Before joining the Drupal world, I worked as a certified bilingual elementary teacher in Texas for three years, teaching 5th grade Science. I saw firsthand how the Texas Essential Knowledge and Skills (TEKS) framework created clarity around educational standards. For example, a kindergarten math standard might simply state: "The student can count forward from 1 to 20 with and without objects." This clear standard defines exactly what skill the student should demonstrate.

Similarly, we could establish a framework of Drupal knowledge and skills. A site builder certification might include standards like "The developer demonstrates ability to configure content types and fields to model complex data relationships." A security standard might state "The developer applies security best practices when configuring user roles and permissions."

I envision three certification levels (Beginner, Intermediate, Advanced) across four areas. We would have Backend Developer standards. Frontend Developer standards. Site Builder standards. And Developer standards focusing on development processes like local development, git workflows, agile, best practices, and contribution knowledge.

From these standards, we could develop community-curated question banks for each knowledge area. We could create assessment methodologies that validate both theoretical understanding and practical application. And we could build clear pathways for skills progression from entry-level to expert.

We've seen many training initiatives struggle in the past. I tried to help Drupaleros before it was dissolved. I've spoken with the maintainer of the previous Open Curriculum initiative that ultimately stagnated. Learning from these experiences, I believe focusing on standards rather than specific training content gives us a stronger foundation. We can reinvigorate the Open Curriculum as a standards framework rather than trying to create and maintain all the training content ourselves.

Similar to how the contribution credit system was developed through community committees, we could establish a committee to maintain the question bank. This committee would ensure the certification's value isn't diminished through widespread distribution of questions.

A Sustainable Path Forward

This approach lets the DA adopt a proven certification system later without carrying the development costs now. The community does the groundwork, the DA gets a working solution.

Once proven effective, this certification system could provide a sustainable revenue source for the DA while delivering genuine value to both the community and clients. It creates a self-reinforcing cycle. Developers gain credible validation of their skills. Companies find qualified talent more efficiently. Clients identify appropriate service providers with greater confidence. The DA receives ongoing certification revenue. The entire ecosystem benefits from higher quality standards.

Join the Discussion

I want to emphasize that these are just ideas that I'm putting forward for community discussion. I don't believe I have all the answers, and the best solutions will come from our collective wisdom and experience.

What's critically important here is that this cannot become a DA responsibility at this stage. The Drupal Association needs to maintain its focus on current revenue strategies and sustainability goals. They have a clear roadmap for growing the Certified Partner program and increasing financial stability. Adding a new, unproven initiative now would risk distracting from these essential priorities.

Instead, this needs to be a true community initiative that develops, tests, and refines a certification framework independently. Only after proving its value and sustainability should we consider how it might integrate with the DA's offerings.

I'm committed to helping build this framework, but it requires a collaborative community effort if you want to contribute to this initiative. Whether through defining knowledge domains, developing assessment methodologies, or testing the framework. Please reach out.

Together, we can create a system that strengthens Drupal's position as a leading CMS while creating sustainable economic opportunities across our entire ecosystem pyramid.

What are your thoughts on this approach? Do you see additional ways we could position Drupal.org as the central hub for Drupal expertise? I'd love to continue this conversation.

Add new comment

Content editors are the unsung heroes of the digital experience. They keep the messaging up-to-date, respond to real-time changes, and ensure that your website remains relevant. But here's the truth: most websites are still too hard to edit.

And that’s a problem we—designers, developers, and strategists—need to solve.

The Problem: Clunky CMS Interfaces and Lost Opportunities

Let me paint a familiar picture.

Imagine  managing a website for a small business, higher ed institution, or nonprofit. Say your small business is a gym and it’s a holiday—your hours of operation change. You know the update should go right on the homepage, but instead, someone posts it to Instagram.

Why?

Because it's easier. The CMS is too clunky. Updating the actual site feels like a chore.

Now scale that to a university with hundreds of editors and thousands of pages. If even a local gym can’t easily update their own website, how can we expect large teams to navigate overly complex CMSs?

We Need to Design For Editors, Not Just End-Users

Content editors are users too yet they’re often left out of the design and build process.

We obsess over the front-end UX while the admin interface—the actual editing experience—gets overlooked. It’s time for a shift in mindset: editing interfaces should be usable, flexible, and empowering.

Modern page builders like WordPress’s block editor (Gutenberg) and Drupal’s upcoming Experience Builder are rapidly evolving.They offer visual, drag-and-drop interfaces that bring content editing closer to what we see on the front end.

But there’s a catch…

Modern Tools Are Only as Good as Their Implementation

While page builders unlock powerful features, they can also introduce too much flexibility.

Dozens of block types, unlimited colour choices, and fine-grained layout controls might appeal to designers—but they often overwhelm editors.

Faced with 40 block types, an editor may not choose the best one for the job.

The solution isn’t to remove features, but to implement intentional defaults and smart guardrails that simplify choices and support consistency.

To Support Editors, Do the Following:  

1. Use Clear Field Labels and Help Text

• Why: Content editors may not be technical. Clear labels reduce confusion.
• Best Practice: Replace vague labels like Body with  Main Content or Article Body, and add descriptions like “This is the main section of your page.”

2. Organize Fields Logically

• Why: A well-organized content-entry form improves usability and reduces cognitive load.
• Best Practice: Group fields in logical sections (e.g., SEO, Header, Content, Sidebar) using fieldsets or tabs. Keep this structure consistent across content types.

3. Provide Flexible Yet Structured Components

• Why: Editors need creative freedom without sacrificing consistency using tools like Drupal Paragraphs, Layout Builder, or WordPress custom blocks—rather than relying solely on WYSIWYGs. This approach gives editors options to assemble pages in creative ways while maintaining visual consistency.
• Best Practice: Instead of relying solely on WYSIWYG fields for full-page content, provide a library of reusable, pre-designed components using tools like Drupal Paragraphs or Layout Builder, or WordPress custom blocks. This approach gives editors options to assemble pages in creative ways while maintaining visual consistency.

4. Set Reasonable Default Values

• Why: Editors juggling multiple tasks benefit from smart defaults. When the CMS provides helpful starting points, editors can focus on crafting meaningful content rather than wrestling with layout or metadata choices.
• Best Practice: Auto-fill fields like meta descriptions or Open Graph tags based on content. Default layouts and image sizes help editors focus on content, not formatting.

5. Create Granular User Roles and Permissions

• Why: Editors will be confused if they have access to advanced configuration settings that they don’t have the training to update. Editors should only see what they need—no more, no less.
• Best Practice: Limit access to advanced features with role-based permissions aligned to staff responsibilities.

6. Make Media Management Easy

Why: Efficient access to quality, on-brand assets speeds up publishing.
Best Practice: Use a media library with previews, drag-and-drop, and asset categories for easy re-use.

7. Build with Accessibility in Mind

Why: Accessibility isn’t just a legal requirement—it’s a key aspect of good user experience. Yet for many content editors, it can be difficult to know whether what they’re creating is truly accessible. That’s where the CMS can provide much-needed guidance.
Best Practice: Use accessible components by default and build guardrails into the editorial interface to help prevent common accessibility issues. 

For example, instead of allowing editors to choose arbitrary colours—which can result in poor contrast—offer a curated colour palette that aligns with brand guidelines and meets contrast requirements. Incorporate a tool like Editoria11y in Drupal or Editoria11y Accessibility Checker in WordPress that allows content editors to do a quick check of accessibility before publishing content.  

8. Train Your Content Teams and Provide Content-Entry Guides

Why: Even the most intuitive CMS can be overwhelming for new or occasional users. Without training, content teams may struggle to understand editorial workflows, component use, or accessibility best practices which can lead to inconsistent content, errors, or underused features.
Best Practice: Provide clear onboarding and content-entry guide. If internal training feels too difficult to manage, talk to us about training your content team to get tailored support and resources.

Avoid These These Mistakes

1. Don’t Use Technical Jargon

Why: Editors may not understand terms like Node, Taxonomy, or View Mode.
Best Practice: Use plain language labels and admin interfaces (e.g., “News Article” instead of “Node Type: Article”).

2. Don’t Overload the Edit Screen

Why: Too many options causes decision fatigue.
Best Practice: Use conditional fields, collapsible sections, and permissions to simplify the experience.

3. Don’t Hardcode Layouts or Lock Editors Out

Why: Editors often need to update layouts over time.
Best Practice: Provide structured layout tools (like Layout Builder with guardrails), instead of rigid templates, so that content can evolve.

4. Don’t Ignore Performance for Admin Users

Why: Speed is often the single most important factor in delivering a good user experience—especially for content editors working in the backend every day. When editing screens are slow to load or unresponsive, it leads to frustration, interruptions in workflow, and more room for error.
Best Practice: Apply performance best practices to the administrative interface, which could mean changing form settings to reduce the complexity, and selecting page-building tools that load quickly.  

Emerging tools like Drupal’s Experience Builder offer a glimpse into what a high-performance admin experience can look like. Its React-based architecture will enable near-instant updates for editors.

5. Don’t Skip Content Previews

Why: Editors want to know what their content will look like before publishing.
Best Practice: Enable preview modes, ideally with live preview built in, that render content as it will appear on the site. Bonus points for adding a mobile preview.

6. Don’t Neglect Help Text and Documentation

Why: Content editors don’t want to hunt around for links to documentation. They want to be able to get help for the specific task they’re working on.
Best Practice: Add inline help text, links to documentation, or tooltips where possible, to reduce the friction for getting help.

Who Owns the Editor Experience?

That’s a tricky question.

• Developers think in terms of schemas and data models.
• Designers empathize with end users, but are often disconnected from CMS workflows.
• Project managers advocate for client needs, but may not possess full technical insight.

What’s often missing is shared ownership of the content editor experience. Creating a usable backend shouldn’t fall solely to developers or be an afterthought. Instead, we need intentional conversations across roles—designers, developers, strategists, and editors—to prioritize editorial usability from the earliest stages of discovery through to implementation.

In most projects, the CMS backend isn’t explicitly designed. It emerges by default—from how Drupal, WordPress, or similar platforms render interfaces based on content types, fields, and configurations. The result is often a functional but fragmented editing experience. But the backend deserves the same thoughtful design as the front-end—and that means approaching it with intent, not just accepting what the CMS gives us out of the box.
Practical Steps for Each Role

Here’s how each team member can contribute:

Developers

• Embrace modern editing frameworks. Platforms like WordPress’s block editor or Drupal’s Experience Builder (soon to be released) are built with React to support visual editing. Embracing these tools—rather than older, field-heavy methods—can make editing feel more intuitive and less technical.
• Simplify the interface. Default page building tools often offer too many blocks, options, and settings. Reduce clutter by removing unused blocks, hiding advanced controls, and setting defaults for fonts, colours, and layouts. This lets editors focus on content instead of configuration.
• Avoid overcomplicated field systems. When editors need layout flexibility, field-based solutions can be limiting and confusing—kind of like using spreadsheets to design a webpage. Instead, offer structured components that support visual editing but still preserve consistency and accessibility. For WordPress, tools like the Block Binding API, or the Meta Field Block plugin, can help render our beloved structured data in a much more editor-friendly way.

Designers

• Perform user testing with content editors on the editor interface. Testing with content editors is essential to truly understand how to improve their experience
• Design with this flexible backend in mind.This requires designers to get familiar with the back-end. Typically, “components” can be placed anywhere on a page, next to any other component. Designers can play a role in giving guidance around how to combine components in a way that creates a good visual balance and a good UX flow.
• Prioritize consistency in styling defaults. Establish rules for spacing, font sizes, and colour palettes that carry through to the editor experience. This reduces cognitive load for editors and prevents design drift.
• Create an editorial style guide or content templates. These can help non-designers replicate good layout and visual hierarchy by using predefined combinations of components.

Content Editors

• Provide feedback during demos—especially on the admin UI. No one knows the job better, so that insight is incredibly valuable. Doing a test run of daily tasks can help surface any gaps and ensure the right tools are in place.
• Advocate for brand  and accessibility compliance. Ask for sensible options for colours or text sizing so to be able to create branded, accessible content more easily.
• Request training resources and backend walkthroughs. Think about which formats would be most helpful—whether that’s guides, videos, or live training sessions—to support everyday workflows.

Why It Matters

Websites are strategic investments—often meant to last 5–7 years. A poor editing experience erodes that value.. Editors avoid using a CMS that’s hard to use, content gets outdated, and the site gradually deteriorates.

On the flip side, when content editors are empowered, they:

• Keep the site fresh and relevant
• Create accessible content
• Communicate more effectively with audiences

Improving editor UX saves time, reduces support requests, and supports compliance. Better editing tools don’t just help editors—they help the entire organization.

Looking Ahead

Embracing Experience Builder and Beyond

As tools like Drupal’s Experience Builder and WordPress’s block editor (Gutenberg) continue to mature, they’re reshaping how we think about backend design. These systems have the potential to make publishing more accessible. Built on modern React-based frameworks, these systems move away from rigid, form-based interfaces toward dynamic, visual editing environments that more closely mirror the frontend experience.

Visual, drag-and-drop tools reduce barriers for non-technical users and unlock creative autonomy. But flexibility without strategy can quickly lead to clutter and inconsistency.

To truly improve the editor experience, we need to curate the interface, set smart defaults, and collaborate across roles—bringing developers, designers, and editors into alignment from the start. These systems offer real opportunities to democratize publishing but only if we treat backend usability as a core part of the design process.

Join the Conversation

Want to explore this topic further? Join me for a free webinar on May 9 at 12 PM EST, where he'll dive deeper into building better content editing experiences.

Sign up for the webinar!

Today, we can confidently say that AI technologies and machine learning are actively being implemented in various areas of human life. This directly concerns Drupal web development.
And here, quite natural questions arise: how can these technologies be used, where, what benefits can they bring, and much more? 
In fact, the potential for implementing such solutions is incredibly huge. A business's main task is always to improve efficiency and quality of service, attract new customers, and increase the final profit.

A slightly quieter week than I would have liked, but you can't get everything done all the time. That said, I worked on two pretty large issues - Font Awesome Icons in LocalGov Base and config setting for JS mobile breakpoint.

Agentic AI with Maestro

AI is disrupting the business world where many look to AI as a way to replace personnel. We at Nextide look at AI combined with our Maestro Workflow Engine as a way to increase people's productivity by replacing the mundane or repetitive tasks that humans do, retaining employees and allowing them to focus on important business tasks.  As AI offerings mature, offloading routine and time consuming tasks to AI to perform will become the norm. 

Introducing the Maestro AI Task!  

With our latest release of Maestro, you are now able to use an AI-powered task within your workflow templates.  Using the AI LLM of your choice, here's a few examples of what you can do with the Maestro AI Task:

Join us THURSDAY, April 24 at 1pm ET / 10am PT, for our call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)

We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google doc: https://nten.org/drupal/notes!

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

This free call is sponsored by NTEN.org and open to everyone. 

Please note that, since we postponed for a week due to NTC, the Zoom link for this month is different. Please use the following link for April's call:

• Join the call: https://us02web.zoom.us/j/81168469697?pwd=7UI5ZBjeDJQuicIq61et1TmMu2pDqb.1

  • Meeting ID: 811 6846 9697
    Passcode: 284106

• Follow along on Google Docs: https://nten.org/drupal/notes

View notes of previous months' calls.