I spend a lot of time in rooms with people who are cautious about AI. That caution is legitimate. There are real obligations around privacy, accuracy, equity, and trust. The deliberation is appropriate. I’m not here to argue against it.

But there’s a distinction we’re not making clearly enough.

Adoption is a choice. Exposure is not.

You don’t have to deploy an AI tool, build an AI workflow, or take any institutional position on generative AI for it to be actively shaping your reputation. These systems are not waiting for your policy committee to finish its work. They’re already reading your website, processing your content, and forming a portrait of who you are and whether you’re worth recommending, right now, before your next prospective customer, student, or partner clicks a single link.

And you can’t see it happening. There is no report. No dashboard. The conversation is already underway. You’re just not in the room.

This isn’t a higher education story, or a B2B story, or a consumer story. It’s all of them at once.

Consider what’s happened to search behavior in the last 18 months. According to Adobe’s May 2025 survey of 800 U.S. consumers, 77% of Americans who use ChatGPT now use it as a search engine. Nearly one in four goes to ChatGPT first, before Google. And 36% of all consumers have already discovered a new product or brand through ChatGPT. For Gen Z, nearly half have.

In B2B, the shift is equally stark. G2’s March 2026 survey of over a thousand software buyers found that half of B2B buyers now begin their software research with an AI chatbot more often than with Google, up from just 29% in April 2025. That’s nearly doubled in less than a year.

In higher education, EAB published survey data this past February showing that 46% of high school students now use AI tools during their college search, nearly double the rate from six months prior. Nearly one in five have already removed a college from consideration based on what AI told them.

Picture what that actually looks like. A 17-year-old, Sunday night, asking ChatGPT whether a particular school has a strong environmental engineering program. The answer comes back thin, vague, assembled from whatever that institution has left lying around. The school never makes the list. No one in admissions ever knows the conversation happened.

Not after a campus visit. Not after talking to an admissions counselor. Based entirely on what a language model assembled from everything that institution had ever published.

The common thread across all three of these: The decision happens before the website visit. Before a sales call. Before a form submission. Before anyone in your organization even knows someone was considering you.

There’s one more data point that deserves attention, because it names what many organizations are starting to feel without yet having language for it.

Semrush analyzed billions of visits across more than 50,000 sites and found that total web traffic was nearly flat in 2025, while AI traffic grew 66% and organic search declined in 13 of 17 industries. A separate field study published in 2026 found that when a Google AI Overview appears, organic click-through rates drop 61%. In Google’s newer AI Mode, the zero-click rate reaches 93%.

Demand didn’t disappear. It moved.

Since this post was first drafted, Google has made that trajectory official. At Google I/O in May 2026, the company announced that AI Overviews now reach 2.5 billion monthly users and that its conversational AI Mode has surpassed 1 billion. More significantly, Google confirmed it is building agentic search capabilities designed to perform information-gathering on users’ behalf — with traditional links described internally as increasingly secondary to the experience. The shift the data was pointing to is no longer a prediction. Google has named it as the direction.

The harder problem is that your analytics won’t tell you. Traffic may hold steady, or decline slowly enough to explain away, while the decisions that used to happen on your site are now happening somewhere you have no instrumentation for.

The people who would have visited your site to answer a question are now getting that question answered before they arrive. The top and middle of your funnel, awareness, consideration, initial shortlisting, may already be happening somewhere you can’t see, can’t measure, and currently have no ability to influence.

This doesn’t mean websites are dying. It means the website has lost its monopoly on first impressions. For many organizations, the AI answer is the first impression, and it’s being assembled from whatever you’ve left lying around.

Before you commission a content audit, redesign a page, or draft a governance policy, do something simpler.

Ask.

Open ChatGPT. Open Perplexity. Open Claude. Open whatever tool your audience is using. Ask about your organization the way a prospective customer would. Ask what you’re known for. Ask what you offer. Ask whether you’d be a good fit for someone in a specific situation.

Then read the answer carefully. Not just for accuracy, but for recognition. Does it sound like you? Does it reflect who you are now, or who you were five years ago? Is it specific and confident, or vague in ways that suggest the underlying signal was weak?

Then do it for a peer organization. Compare the answers. You’ll feel the difference immediately between an organization whose content model is coherent and one whose isn’t.

Run that experiment this week. Project it on a screen with the people who make decisions about your content and let them watch it happen in real time. The conversation that follows is the one that needs to happen.

Your organization is already being summarized by machines. The only question is whether the story they tell is the one you intended.

Knowledge hoarding has a hidden cost. When people and organizations treat what they know as proprietary, they slow down the work, isolate the expertise, and create fragility. When one person holds the context for a system, a process, or a decision, that context walks out the door with them.

The open-source model offers a different proof. Software built in the open — where anyone can read, improve, and share the code — powers most of the web. It’s more secure, more resilient, and more innovative than most proprietary alternatives, precisely because it benefits from more eyes, more minds, and more perspectives than any single organization could assemble on its own.

That lesson doesn’t only apply to software. It applies to how teams collaborate, how expertise develops, and how trust gets built — with clients, with partners, with communities.

Four Kitchens started this way from the beginning. In 2006, the founders taught themselves Drupal from documentation the community had written and modules volunteers had built. The foundation they built on wasn’t theirs. It belonged to everyone.

That sense of reciprocity became an operating principle. Early versions of our values included a commitment to contributing to open-source projects every single day — not as a marketing claim, but as a standard for how we work.

In practice, that has meant contributing code back to Drupal, sponsoring camps, sending Web Chefs to speak at events large and small, writing publicly about what we’ve learned from complex projects, and documenting our work in ways that leave clients more capable after an engagement, not more dependent.

The clearest expression of this value is Emulsify.

We built Emulsify because we kept seeing the same problem: large organizations — higher education institutions in particular — struggling to maintain consistent brand and visual identity across dozens of websites. Every institution was managing the design independently, spending significant time and budget on a challenge that was fundamentally shared.

We could have built a proprietary solution. Instead, we built an open-source design system toolset and gave it to the community.

Emulsify is a component-based design system that uses structured, reusable code to implement a visual identity across multiple websites. Because it’s built on components, design updates don’t require rebuilding a website’s look and feel — changes flow through the system reliably and consistently. The underlying code is tested, accessible, and built to last. It works natively with Drupal, with active community support and ongoing development.

For large organizations managing many sites, that kind of system isn’t a convenience. It’s what makes it possible to maintain coherent brand governance at scale without constant intervention.

Emulsify has since been adopted well beyond our own client base — active on more than 5,000 sites, according to the Drupal community. That’s not a side effect of open-sourcing it. That’s exactly the point.

The organizations that benefit most from shared knowledge aren’t the ones that give the most away. They’re the ones that treat generosity as a discipline — a practiced habit rather than an occasional gesture.

When a team documents what it learns from a complex project, that knowledge compounds. It makes the next project faster. It helps newer team members build on real experience rather than starting from scratch. It creates the conditions for the kind of deep expertise that clients can actually feel and come to expect.

The same is true at the community level. The Drupal ecosystem is stronger because thousands of organizations have contributed back the solutions they built for themselves. No single one of them could have built what the community has built together.

Sharing knowledge doesn’t diminish what you know. It extends your reach, strengthens your relationships, and positions you as someone worth learning from.

When we revisited our values in 2025, “Share What We Know” didn’t feel like a new commitment. It felt like a reclamation — a formal name for something we’d been doing since the first time we pushed code back to the community that had taught us to build.

Our goal has always been to do work that outlasts us. Tools our clients can extend without us. Documentation their teams can use long after our engagement ends. Contributions the community can build on for years. A website that keeps growing, improving, and reaching its audience without waiting for the next big contract to move forward.

That kind of lasting impact doesn’t come from holding things close. It comes from letting them go.

“Share What We Know” isn’t a value we added. It’s what we’ve always been.

To be fair, search can only work with what it’s given. If your content is clear and maintained, even a basic search implementation will feel pretty effective. If it’s not, no amount of technology is going to save you.

You see it happen all the time. A result shows up, but it’s not clear why. The right page is there, but the title doesn’t match what the user meant. Three pages compete for the same idea, and none of them feel like the right answer.

That usually gets labeled as a ranking problem. But often, it’s a content problem. Most search issues come down to a mismatch between how content is written and how people actually look for it. We name things based on internal structures that users don’t know exist. If someone searches for “scholarships” and your site calls it “financial aid,” the system isn’t “broken”; the content and the user are just speaking different languages.

Then there’s the governance side of things. Search is very good at surfacing content no one has looked at in years: expired events, outdated pages, or duplicates. That’s not a bug. That’s the system doing exactly what it was designed to do.

The interesting part is that fixing these things doesn’t just “fix search.” It improves how you perform in external search engines, how accessible your site is, and how well an AI might be able to parse your data later. It’s the same foundation.

Most search experiences look the same on the surface: a box, a list, maybe some filters. It’s easy to think of it as a single feature, but behind the scenes, I find it helpful to break it down into three separate decisions.

Indexing: This is how your content gets into the system. You can use a crawler to scan the site, which is easy but gives you less control. Or, you can “push” content from your CMS, which gives you more control but requires a lot more intentional structure.

Ranking: Every system has a logic that decides what’s relevant. Maybe titles are weighted more than body text. Maybe newer content gets a “boost.” If you haven’t made these decisions intentionally, the system is still making them for you; you just don’t have a seat at the table.

Interface: This is what the user actually sees. The snippets, the filters, the way results are grouped. You can take something off the shelf, or you can build something custom. Either way, this is where you build (or lose) user trust.

What’s useful about this framework is that it shifts the conversation. You’re not just choosing a “tool”; you’re deciding how much effort you want to put into managing your data, your logic, and your experience. Those choices don’t always line up with the highest price tag.

1. The “off-the-shelf” path (lower effort, lower control)

This path usually relies on a Crawler. The tool “reads” your site much like a user does. It’s the fastest way to get a search box on a page.

• The go-to: Google Programmable Search
• Best for: Smaller sites or organizations that need a “set it and forget it” solution and don’t require custom “boosting” of specific content. An easy way to search across multiple sites on the same domain.
• The tradeoff: You are often stuck with a “prebuilt widget” that looks like a guest on your own website.
• The strategic note: Watch out for the “trust gap.” If your tool serves ads or carries external branding, it can feel less like an authoritative resource and more like a third-party plugin.

2. The “configuration” path (the middle ground)

This is the “sweet spot” for many mid-to-large organizations. These tools offer more control over ranking and interface without requiring you to manage complex server infrastructure.

• The tools: SearchStax Site Search or SwiftType
• How it works: You can often choose between a crawler or “sending” your data via an API.
• Best for: Teams where search is a primary navigation tool and needs to feel integrated, but you don’t want to hire a full-time search engineer.
• The strategic note: This is the “agility” choice. These tools provide a marketing dashboard, empowering content teams to tune results, like boosting “Giving Tuesday” to the top for a week, without needing a developer.

3. The “engineered” path (high control, high investment)

This is the “send” approach. Your CMS (like Drupal) pushes highly structured data directly into the search index via modules like Search API. This gives you total control over the experience.

• The tools: Solr or Elasticsearch
• How it works: Deeply integrated into your hosting environment (like Pantheon’s managed Solr) or a dedicated provider like SearchStax.
• Best for: Enterprise-level sites, multidomain ecosystems, or situations where search is the “core product” (e.g., a complex program finder or resource library).
• The strategic note: This offers the most power, but it requires a “search owner.” While the software is often open source (no license fee), it is the most expensive to run because it requires specialized engineering hours to maintain and tune the logic.

The right choice depends on your search maturity. Don’t buy the “engineered” solution if you don’t have the staff to steer it; don’t settle for “off-the-shelf” if your users rely on search to make high-stakes decisions.

When search underperforms, the instinct is to add more power through better tools, more features, and more controls. That’s a reasonable reaction. There’s a lot these systems can do. But what we tend to see is a familiar pattern: a more complex system running on the same content. Filters get added. The UI gets heavier. Configuration grows. The results don’t really improve.

It’s the “Lamborghini to pick up groceries” problem. Sure, the car is capable of a lot, but you’re still sitting in the same traffic, and you still have nowhere to put the bags. If the underlying content isn’t in place, more technology doesn’t fix the problem; it just makes the failures scale faster.

There are situations where a more advanced search makes sense (large datasets, multiple domains, deeper filtering), but even in those cases, the outcome still depends on the same thing: how clear and structured the content is.

If that part isn’t in place, more technology doesn’t fix the problem; it just makes it scale faster.

Improving search usually starts with getting the right people in the room. It sits at this awkward intersection of UX, content, and engineering. If those perspectives aren’t aligned, you end up with three different people trying to solve three different versions of the problem.

The way I usually approach this is to move away from “search feels off” and toward something concrete. What are the top 10 queries? What should the first result be? Are users finding things, or are they just trying again and leaving?

Once you look at search logs and identify where the language doesn’t match, the conversation changes. Instead of asking “what tool do we need,” we start asking: “What content should we exclude? How do we prioritize this department over that one? Where is search being asked to fix a gap in our main navigation?”

That’s where progress actually happens. Search will always have a subjective element, but it shouldn’t be driven by gut feel alone. Once you have a shared understanding of what the user is trying to do, and visibility into how the system is actually behaving, the technology becomes a lot less confusing.

You’re never really “done” with search. But when your content is clear, and your priorities are aligned, search starts to feel predictable. And once it’s predictable, you can stop guessing and start solving the actual problem.

In 2006, Todd Ross Nienkerk founded Four Kitchens with three friends and a conviction that the web could be built better. Not just technically, but intentionally, with craft, curiosity, and a genuine commitment to the people on both sides of the work.

The name, inspired by a potential office space with four kitchens, became a playful metaphor for who they were and the company they wanted to be: a place where things get made, where process and tools matter as much as output.

From the beginning, the team operated with a set of shared beliefs about how to do the work. No leadership offsite handed them down, and no business book supplied them. They emerged from the practice itself: the way writers, designers, and developers collaborated across disciplines, the way the team navigated hard problems together. The team codified them over time as The Way of the Web Chef.

We are young, hip, creative, brilliant, and witty. And modest. We are… graphic artists, audiophiles, computer scientists, webdesigners, satirists, photographers, filmmakers, information systems experts, writers. Four Kitchens Studios is a creative collective based in Austin, Texas. We specialize in engaging, entertaining, and amusing publishing for print and the web. We’ve got everything under one roof—plus four kitchen sinks.

Those values weren’t a manifesto. They were a reflection. A description of what was already true about how Four Kitchens worked.

A lot happens in two decades. A startup becomes an established agency. The founders’ vision gets carried forward by a team that evolves and changes shape. The industry shifts under everyone’s feet, sometimes gradually, sometimes overnight.

Four Kitchens grew through all of it. The team expanded, went remote, built tools that became standards in the Drupal community, and deepened expertise in higher education digital work. The company that exists today is not the company these four friends founded in 2006.

And yet, the instincts that shaped those early years, to stay curious, to care about craft, to show up for each other, were always there. They didn’t need to be invented. They needed to be recognized.

In 2025, Four Kitchens undertook a structured values revision process through EOS (Entrepreneurial Operating System), a framework the leadership team uses to align around shared goals, honest feedback, and clear accountability.

The process wasn’t a reset. It was an excavation. The question wasn’t: what should we believe? It was: what do we believe and how does it show up in our work?

The behaviors that showed up most consistently in good work, in strong client relationships, in how people treated each other during hard stretches started to surface. We looked at where the company had been and where it was heading, and asked: are our current values an accurate description of who we are? The answer was: close, but not quite. Some values had merged naturally. Some were better expressed differently. The spirit was right. The language needed sharpening.

The result is The Way of the Web Chef as it exists today: five values that describe not aspirations, but practices. Things we actually do.

What emerged from that process was something we didn’t expect. Answers overlapped. We started finishing each other’s sentences. When one person named a pattern, someone else immediately recognized it. At one point, we brought Todd back into the history, asking him to tell the story that had inspired the original values in the first place. The energy was unmistakable. We weren’t a team being asked to agree to something. We were a team discovering what we already knew.

These aren’t rules. They’re recognitions.

Endlessly curious

Two weeks before launching That Other Paper, one of our co-founders, David Strauss, discovered Drupal and convinced Todd and team to scrap the existing build and start over.

That decision carried real risk. It also became our first Drupal project and led to Pressflow, one of our earliest open-source contributions. All because of a willingness to pursue the better answer, even when the comfortable one is right in front.

If you work with us, expect thoughtful questions. We dig in because we’d rather understand your problem deeply than jump to a solution that only looks right on the surface.

Dedicated to our craft

One of our original values read: Deliver the best possible value, even if it means billing less work.

That wasn’t a marketing line. It reflected how we try to operate, and it still does.

That dedication has always been structural, not accidental. What started as informal brown bag lunches, Web Chefs® gathering to share what they were learning, evolved into our Practice Group: a weekly open forum where anyone can lead a session, propose a topic, or simply show up to learn from a colleague. The expertise we bring to your project isn’t developed in isolation. It’s built collectively, on purpose, every week.

That dedication shows up in the details: the code review that catches an edge case before it becomes a production headache, or accessibility standards that are considered from the start rather than added later.

We care about how things are made because your team will live with what we build long after the project wraps.

Playful

Four Kitchens was founded by people who met while working on a humor publication. That creative energy still shows up across the company, from the way we brainstorm solutions to how we stay connected as a fully remote team.

Around year 10, we co-hosted a SXSW Interactive party on 6th Street with another Austin agency. Live-band karaoke, a Friday the 13th tattoo artist giving away free computer-themed flash, and a line out the door and down the stairs within an hour. The tattoos weren’t horseshoes or four-leaf clovers. They were mouse cursors, terminal windows, pixel art. At least one Web Chef went home with a cursor clicking on the number 13.

That’s always been the instinct: Find the version of the thing that’s a little unexpected, a little more fun, and commit to it fully. (Ask us about our Slack emoji lore sometime.)

Playfulness here doesn’t mean unseriousness. It means creating an environment where people feel comfortable offering the unexpected idea that might turn out to be the right one. Especially when working remotely, it’s our playful nature that keeps us connected. It’s the connective tissue of a distributed team.

Our work tends to be strongest when collaboration feels open and exploratory rather than stiff and transactional.

Share what we know

From the beginning, our mission was to set knowledge free. Early versions of our values included a commitment to contributing to open-source projects every single day. Over time, open source moved out of the spotlight, partly because we weren’t sure it resonated with every role on the team.

But the spirit behind it never disappeared. It’s why we built Emulsify, an open-source design system toolset born out of a problem we kept seeing: higher ed institutions struggling to maintain brand consistency across dozens of department and school websites. Rather than solve it once for one client, we built something the whole community could use.

Naming this value again felt like a homecoming.

Whether it’s code, documentation, or lessons learned from a complex migration, sharing what we learn strengthens the communities that make our work possible. That same instinct shapes how we work with clients: transparent about our thinking, willing to explain the why behind our recommendations.

Accountable to each other

Accountability is easy to declare. It’s harder to build into how a team actually operates.

On our team, feedback is continuous rather than saved for annual reviews. We treat goals as shared outcomes.

When we collaborate with clients, our teams communicate directly and take shared ownership of the outcome. Strategy and execution aren’t siloed here. The people shaping the approach are the ones building it.

If something isn’t working, we’ll say so — and we hope you will, too. That kind of partnership creates the conditions where strong work can emerge.

Right now, every organization we work with is navigating some version of the same pressure: how do you evolve without losing what makes you distinctive? How do you respond to new technologies, new expectations, and new constraints without either clinging to the past or chasing every trend?

It’s a question we’ve been asking ourselves for 20 years.

The answer has never been: pick a lane and stay in it. It’s been: know what you actually believe, and let that be the constant while everything else evolves.

A kitchen that’s been open for 20 years has learned a few things. What works and what doesn’t. When to follow the recipe and when to improvise. How to serve people well, not just serve them.

The Way of the Web Chef isn’t a brand exercise. It’s a description of how we work. And for the clients who partner with us, that matters. Because the same rigor, curiosity, and care we apply to our own organization is exactly what we bring to yours.

jQuery did not become dominant because developers were lazy. It solved real problems. Browsers were fragmented. There was no consistent way to select elements from the DOM. Event handling varied. AJAX required wrestling with verbose XMLHttpRequest code and awkward callback patterns. jQuery unified those concerns behind a clean, approachable interface: the dollar sign selector, the on method, simple get and post helpers, animations like fadeIn and slideUp.

It was a necessary abstraction at the time.

Over the years, though, the platform evolved. Browsers standardized. APIs matured. ES6 modernized the language. CSS grew far more capable. Many of the problems jQuery once addressed were absorbed directly into the browser.
The platform changed.

We may be living through a similar moment with modern frameworks. React and other tools solve meaningful problems. They help teams move quickly and provide structure, especially for developers early in their careers. In many cases, they are exactly the right choice.

But over time, thoughtful decisions can quietly become defaults. A subtle assumption can creep in: if something feels modern or interactive, it probably requires a framework.

The shift is not dramatic. It is behavioral. Instead of beginning with the problem, we sometimes begin with the stack. If an interaction feels dynamic or app-like, we assume it needs something larger.

Frameworks offer guardrails and shared patterns, and that consistency is valuable. But when the tool becomes the starting point for every conversation, it can narrow the range of options we consider. We stop asking what the browser already provides. We begin to treat complexity as the baseline for modern work.

This is not bad architecture.It is often just unexamined architecture.

It shows up in small ways: adding a dependency before exploring a native API, reaching for a heavy client-side solution when progressive enhancement might be enough, and introducing new tooling because that is what modern projects tend to do. Each decision is understandable on its own. Over time, though, they expand the surface area of a project: more dependencies, more upgrades, more maintenance. Fewer dependencies can mean fewer upgrades to manage, fewer compatibility conflicts, and a smaller maintenance surface over time.

While we have been refining our build pipelines and debating frameworks, the browser has continued to evolve. Quietly and steadily. Modern JavaScript is not what it was 10 or even five years ago. Today’s browsers ship with stable, well-documented APIs that address many of the use cases we once handled with libraries.

Need to know when something enters the viewport? There is Intersection Observer.

Need to react to changes in the DOM without polling? Mutation Observer is built in.

Need to respond to screen size changes? MatchMedia handles that cleanly.

Need to persist data between sessions? Local storage is there.

Need to integrate with a device’s native share dialog? There is an API for that.

CSS has evolved as well. Layout systems, transitions, scroll behaviors, and positioning features eliminate entire categories of JavaScript we once considered unavoidable.

And the language itself has matured. Modules, promises, async and await, richer array methods, cleaner syntax. These are no longer experimental features. They are part of the platform.

None of this is particularly flashy. It is simply what the browser now provides.

The important point is not that every project should avoid frameworks. It is that many of the problems we once solved with external libraries now have first-class support in the browser itself. So, what does that mean in practice?

Add one small pause to your workflow. Before installing a dependency, check the platform. Search MDN. Look up “browser API for…” and see what comes back. You might discover that Intersection Observer replaces the scroll library you were about to add. Or that CSS handles the animation without JavaScript at all.

It means reframing how you evaluate tradeoffs. When a feature request comes in, write down the requirement in plain language before you write down the stack. What actually needs to happen? A modal opens. Content animates on scroll. State persists between visits. Once the behavior is clear, ask whether the browser can already do it.

It means keeping a short list of native capabilities in your mental toolkit: MatchMedia. Local storage. Native form validation. ResizeObserver. The goal is not to memorize every API. It is important to remember that vanilla JavaScript is an option.

It also means normalizing this conversation on your team. When someone suggests a new library, ask a simple question: is there a native way to do this? Not as a challenge. As due diligence.

None of this requires abandoning modern tooling. It simply widens your decision tree. And it costs almost nothing but attention.

In our session, “Elevating Drupal Experiences with Vanilla JavaScript,” we’ll share how we’ve used modern browser capabilities to build rich, interactive experiences within Drupal — not by rejecting frameworks, but by pairing Drupal’s strengths with what the browser already does well.
We’ll walk through:

• Where native APIs replaced heavier dependencies
• Where progressive enhancement simplified complexity
• Where we had to rethink our own assumptions

More than anything, we hope it sparks a conversation.

If you’re going to DrupalCon Chicago 2026, please make sure to attend the session with Mari and Andrés.

Where: Hilton Chicago, 720 S. Michigan Ave., Chicago, IL 60605, Salon A-2 (LL)

When: Tuesday, March 24, 2026, 4:10–5:00pm

For session details and tickets, click here.

Before we built our dashboard, someone on our platform team was manually generating reports for each of the 130 sites every quarter. Accessibility problems. Broken links. Duplicate content. All compiled, formatted, and sent out as a PDF.

It was better than nothing. But it had two serious problems.

First, people were unlikely to act on it. A PDF that arrives by email, detached from the website itself, is easy to file away and forget. Second, even the editors who did read it had no way of knowing whether they were improving until the next quarter’s report showed up. The feedback loop was three months long.

This is a pattern that’s common across organizations: the information that would most help editors do better work exists somewhere, but it’s separated from the moment when they’re actually ready to act on it. Updates get coordinated in chat threads. Content issues arrive by email. Broken link reports live in spreadsheets.

Editors are expected to carry all of that context across multiple tools and respond when something surfaces. For people whose primary job isn’t web publishing, that’s a lot to ask.
A dashboard brings that context back into the CMS, the place where the work actually happens.

Editors don’t log into a CMS at random. They arrive with a purpose: fixing a typo, publishing a new story, or checking whether a content import ran correctly. Whatever the task, they’re already in the right mindset. They’re thinking about the website and are ready to make changes.

That makes login the ideal moment to surface what needs attention.

On our dashboard, we highlight the pages with the most accessibility errors. We show a list of broken links. We surface draft content that never got published. These aren’t things editors have to go hunting for. They appear right when editors are ready to do something about them.

We also use the dashboard to answer questions editors commonly ask us. One recurring one: how does content get into the site from other university systems? Faculty profiles, events, and course data. All of it comes in through automated imports. Drupal has robust tools for this, but its default interface exposes every option and setting, which is overwhelming for a content editor. So we’d never exposed it to them at all. Editors had no visibility into something that was working fine. They just didn’t know it.

The dashboard gave us a place to show a simplified view of those imports: here’s when faculty profiles last synced, here’s the kinds of courses that are imported to this site. Just enough to answer the question and build confidence. Support requests about content imports dropped significantly after we added that.

Information alone doesn’t change much. The problem usually isn’t awareness. It’s timing.

When a broken link shows up in a quarterly report, the path from seeing it to fixing it is long and uncertain. Someone reads the report, makes a mental note, hopes they remember. Most of the time, they don’t. By integrating that same information into the dashboard, the cycle changes:

Quarterly report → read → maybe remember → maybe act later

becomes

Login → see issue → click → fix

The feedback loop collapses from months to minutes. A broken link becomes a clickable item. A page stuck in draft becomes a quick decision. A list of accessibility errors becomes something an editor can start working through today.

One practical note from experience: some data sources introduce delays. Our broken link list comes from Siteimprove via API, which means that when an editor fixes a broken link, it won’t disappear from the dashboard immediately. We didn’t think about that until after we launched. It’s not a dealbreaker, but it’s worth designing around. At minimum, set expectations with editors so a fixed link that still appears on the list doesn’t feel like a bug.

Dashboards aren’t neutral. They’re curated.

Every item that appears is there because someone, explicitly or quietly, decided it mattered. Looking at our current dashboard, I can tell you what it says about our priorities: we value accessible content (pages with the most accessibility errors are one of the most prominent blocks), and we value simplicity and iteration over comprehensiveness.

What’s not on the dashboard is equally revealing. We don’t have traffic metrics or analytics. For this particular higher ed institution, that’s a deliberate choice. The focus is on content quality and editor success, not marketing outcomes. For other clients we work with, traffic data would need to be front and center. The dashboard has to reflect what that organization actually cares about.

The conversations that happen while building a dashboard are often more valuable than the dashboard itself. When you ask your team what should appear on it, you surface competing priorities that usually haven’t been written down anywhere:

• What are editors most commonly asking us for help with?
• What do we wish editors were doing that they aren’t?
• What should be the first thing someone sees when they log in?
• What action should be easiest to take?

Those questions don’t always have obvious answers. But asking them is how you build something useful rather than something that just looks like a dashboard.

And don’t let perfect be the enemy of good. Our first dashboard was basic: simple tables, in a single column, nothing animated or interactive. If you get a dozen useful things on a dashboard, the organization as a whole is going to be better for it. Start there, then build up.

There’s a real risk that a dashboard drifts into feeling like a compliance tool, a place that exists primarily to point out what’s wrong. If the only things editors see when they log in are warnings and error counts, the dashboard starts to feel like surveillance.

The same information can be framed very differently. A list of pages with accessibility errors isn’t a punishment; it’s a prioritized to-do list. A reminder about draft content that was never published helps an editor finish work that might otherwise be abandoned. A note that a component has recently changed gives editors a heads-up to check their pages before finding out something looks broken.

That last one is something we’ve gotten real value from. Our platform has 130 sites, which means making a breaking change to a component has a wide impact. Before we had the dashboard, that kind of communication was difficult. We still do targeted communications about breaking changes. But now we also use a simple announcements block (it pulls from a Google spreadsheet where each row is an announcement) to reach editors right where they’re working. It’s low-tech, but it means we can flag an upcoming change and tell editors exactly what to check. That’s made us more comfortable shipping improvements we might otherwise have sat on.

The goal isn’t to catch mistakes. It’s to help editors succeed.

When your platform supports hundreds of editors across dozens of sites, traditional support breaks down fast. You can’t train everyone personally. You can’t answer every Slack message. And the editors who log in only a few times a year don’t have the context that frequent users build up over time.

The platform itself has to take on more of that responsibility.

One thing that helped clarify our thinking: on the back end, your audience is actually more focused than it might seem. On the front end of a university website, you’re trying to serve prospective students, current students, faculty, staff, donors, and more. But in the CMS, your primary audience is your content editors. There might be a few other users (stakeholders who log in occasionally to get a lay of the land, or interns assigned to clean up a single page), but by and large, you’re designing for a pretty clear group.

For us, that meant focusing our first version on the editors who log in regularly and need to take action. We can add more guidance for infrequent users in later iterations. Starting with the core use case meant we shipped something useful without trying to solve everything at once.

A well-designed dashboard becomes a quiet guide embedded in the platform, helping editors move forward without needing someone from the platform team to step in. At scale, that kind of built-in guidance isn’t just helpful. It’s essential.

In our session, “A Dashboard that Works: Giving Editors What They Want, But Focusing on What They Need,” we’ll share the story behind a dashboard built for 500 editors across 130 sites — the decisions we made, the things we got wrong, and how we figured out what actually belongs on a dashboard and what doesn’t.

We’ll walk through:

• How we identified what editors needed versus what they asked for
• How we balanced editorial priorities with technical realities
• What we’d do differently if we were starting over

Whether you manage one site or one hundred, we hope you leave with something you can use.

If you’re going to DrupalCon Chicago 2026, please make sure to attend the session with Dave Hansen-Lange and Albert Hughes.

Where: Hilton Chicago, 720 S Michigan Ave, Chicago, IL 60605, Williford B (3rd Floor)

When: Tuesday, March 24, 2026, 9:00–9:50am

For session details and tickets, click here.

Program Finder AI demo at the AI Summit in Salon A-5 (lower level)

Monday, March 23 at 10:40 am

Program Finder AI demos at the Four Kitchens booth #116 (lower level)

Tuesday, March 24 at 2:30 pm

Wednesday, March 25 at 12:30 pm

Content Publisher demos at the Pantheon booth (lower level)

Tuesday, March 24 at 10 am

Wednesday, March 25 at 1 pm

“A Dashboard that Works: Giving Editors What They Want, But Focusing on What They Need” session in Williford B (third floor)

Tuesday, March 24 at 9 am

“Elevating Drupal Experiences with Vanilla JavaScript” session in Salon A-2 (lower level)

Tuesday, March 24 at 4:10 pm

“Beyond Card Grids: Using AI to Make Digital Experiences Human Again” lightning talk in Salon C (lower level)

Tuesday, March 24 at 1:00 pm

• Higher ed Drupal teams planning for Drupal 11
• Platform owners managing SSO across multiple environments
• Engineers who want to reduce upgrade risk caused by third-party dependencies

The SAML Authentication module is a really straightforward resource to set up SSO into your site. From my point of view, it’s way easier to configure and maintain than SimpleSAMLphp, so, even if you’re not worried about upgrades (though should you be, read our post about upgrading to Drupal 11), this module will make the maintenance of your site less complicated. However, it’s not perfect. It has its caveats, which I will cover!

Most of the configuration required for SAML Auth is already handled in your site’s SimpleSAMLphp settings. However, there’s already a tool that automates this task!

If you read the Drupal 11 compatible issue thread for SimpleSAMLphp, you will stumble upon Jay Beaton’s comment: He created a helper module to automate the migration of SAML Auth from SimpleSAMLphp. This module will make the switch pretty fast! However, depending on your site’s setup, you must be careful on what settings you’re migrating, especially if the configuration varies by environment.

Before migrating, there are a few decisions worth making. Let’s dive into them!

1. Install SAML Authentication

Naturally, because we want to migrate into SAML Authentication, we need to install it on our site.

1. Run composer require drupal/samlauth

2. Install the helper module

The SimpleSAMLphp to SAML Auth Migration module is currently in development, so the module itself is a sandbox project in Drupal.org. In order to install it, you need to:

1. 1. 1. 1. 1. Add the sandbox as a custom repository into your composer.json:

               "samlauth_helper": {
                           "type":"package",
                           "package": {
                               "name": "drupal/samlauth_simplesamlphp_auth_migration",
                               "version":"1.0.0",
                               "type": "drupal-module",
                               "source": {
                                   "url": "https://git.drupalcode.org/sandbox/jrb-3531935.git",
                                   "type": "git",
                                   "reference":"1.0.x"
                               }
                           }
                       }

            2. This is the composer command: composer config repositories.samlauth_helper '{"type": "package", "package": {"name": "drupal/samlauth_simplesamlphp_auth_migration", "version": "1.0.0", "type": "drupal-module", "source": {"url": "https://git.drupalcode.org/sandbox/jrb-3531935.git", "type": "git", "reference": "1.0.x"}}}'
            3. Require the module: composer require drupal/samlauth_simplesamlphp_auth_migration
            4. Enable it: drush en samlauth_simplesamlphp_auth_migration -y

3. Migrate the configuration

There are two ways for you to migrate the configuration: either through drush commands or through the UI. For the purpose of this article, we will migrate the configuration through the command line, however, you can do it through the UI in this path: admin/config/people/saml/simplesamlphp-auth-migration.

That path also provides a nice visualization of the configuration mapping and migration that will be performed. You can also view it running drush samlauth-simplesamlphp-show-changes command.

3.1. Before migrating

Usually, sites have different setups for different environments, such as testing, development, or production. Each environment may have its own configuration, and if you’re running a migration locally, SimpleSAMLphp might not even be enabled.

Knowing this, depending on where you’re running the migration, you will need to manually set some of the settings yourself. For example, the staging environment uses a different certificate than production. Locally, the staging environment SimpleSAMLphp settings are enabled by default. When you run the migration command, the settings for the active environment will be migrated over, not the other for production.

Another example is that the Entity ID of the SP is dynamic, depending on the environment. If so, you will need to override the SAML Authentication settings, rather than the SimpleSAMLphp.

For the ones that need to be migrated manually, you can either set up a config split for each environment, or you can do some configuration overrides through settings.php. Just beware that, if you need to override arrays, it may not be possible to override them through settings.php. Read more about the issue.

I’ve done both approaches. The approach you take will depend on your site. I’ve set different configuration splits, and have overridden values through settings.php. In my case, I just create a settings.saml.php file and include it in settings.php.

3.2. Known caveats

Although SAML Authentication is way simpler to set up, it’s missing a feature SimpleSAMLphp provides: you can link a remote IdP certificate. In SAML Authentication, the files must be physical in your server. You can only link their path.

This means if your site has remote IdP certificates, you will have to copy its contents and create the files into your site folder. This may make your maintenance process a bit more nuanced, as if the IdP certificates change, you will have to update the physical files from your site.

For the purposes of this migration, if you are linking to remote IdP certificates, you will have to create the files. I’ve faced two situations: remote and local files. For the remote certificates, I decided to put them into web/private/saml-certificates.

3.3. Migrate the configuration

Having the whole context of what we need to be careful about, let’s migrate the config! It’s very simple:

1. Run drush samlauth-simplesamlphp-migrate
   1. You can provide the --cert-path for your certificate path; or
   2. You can go to /admin/config/people/saml/saml and add it into the X.509 certificate(s) field
2. Confirm it was migrated correctly
   1. You can compare against your SimpleSAMLphp configuration

3.4. The Auth Map table

Both SimpleSAMLphp and SAML Authentication use the External Authentication module, it allows a SAML authenticated user with an authname identical to the one in the authmap table to be logged in as that Drupal user. Among those values, it stores the provider, i.e., the module that allowed the authentication.

The SAML helper module automatically migrates the SimpleSAMLphp authmap values into SAML Authentication. However, this is a database migration, so, if you migrated locally and then pushed your changes into a remote environment, this migration won’t be reflected there. To make sure it also happens, you can:

1. 1. If you keep the helper module in your remote environments, you can create an update hook that calls the service that makes the changes:

      /**
       * Enable SAML auth migration module and update authmap table.
       */
      function hook_update_N(): void {
        if (!\Drupal::moduleHandler()->moduleExists('samlauth_simplesamlphp_auth_migration')) {
          \Drupal::service('module_installer')->install(['samlauth_simplesamlphp_auth_migration']);
        }
        /** @var \Drupal\samlauth_simplesamlphp_auth_migration\Migrate $saml_auth_utility */
        $saml_auth_utility = \Drupal::service('samlauth_simplesamlphp_auth_migration.migrate');
        $saml_auth_utility->updateAuthmapTable();
      }
      

Or, you can just do it yourself:

/**
 * Enable SAML auth module and update authmap table.
 */
function hook_update_N(): void {
  if (!\Drupal::moduleHandler()->moduleExists('samlauth')) {
    \Drupal::service('module_installer')->install(['samlauth']);
  }

  \Drupal::database()
    ->update('authmap')
    ->fields(['provider' => 'samlauth'])
    ->condition('provider', 'simplesamlphp_auth')
    ->execute();
}

4. Testing the new SAML Authentication

Once you’ve migrated over everything, the last step is to test if the configuration migration actually works. In order for you to test it, you will need to make changes to your IdP with the new values of the new SAML implementation: the metadata URL, the Assertion Consumer Service, and the Single Logout Service.

If you don’t want to override the existing values from your current SAML IdP, you can modify the Entity ID for SAML Authentication to create a new one, that way you could have two entries in you IdP for SimpleSAMLphp and SAML Authentication.

Regardless, it may be the case that making such a change could take some time if it’s handled by another team. If that’s the case, you would have to wait until those changes are implemented to test the new SAML implementation. Fortunately, the SAML Auth helper module provides a way to masquerade SimpleSAMLphp endpoints with SAML Auth implementations, that way you can test right away without having to make any changes to the IdP. You would eventually need to do it, but for testing purposes, you can use the helper module. To do so, you have to:

1. Remove the simplesaml folder from your web/docroot folder
2. Disable the simplesamlphp_auth module
3. Remove any composer script/automated script that symlinks any SimpleSAMLphp related behavior
4. Enable the Use SimpleSAMLphp Authentication Routes option offered by the SAML Auth helper module (find it on admin/config/people/saml/saml)

Once that’s done, you can try and log in using SSO into the site you’re trying to migrate. If it works, fantastic! You only need to (i) request the IdP changes for you to completely move away from SimpleSAMLphp, and (ii) you can remove the helper module.

4.1. Remote host provider issues

In some cases, SSO is enabled in certain specific environments. That means you may want to test on those environments; you only need to deploy and let the environment be built with the new changes. However, it is not as straightforward as you may think. As a matter of fact, the helper module route masquerading may not even work.

Before speaking about these issues, these are the remote host providers the masquerading will work:

1. Acquia
2. Platform.sh (though you will have to edit the .platform.app.yml file)

4.1.1. Pantheon special routing rule

If your site is hosted on Pantheon, the helper module masquerading won’t work. This is due to a specific routing rule Pantheon seems to have.

If you try and test the new SAML implementation with the helper module, you will get a HTTP 404 error, specifically stating that the file was not found — a text 404, completely different from your Drupal 404. In order to test this with the helper module, the steps (from the module itself) specify that “Make sure that SimpleSAMLphp is not available on the server at https://site/simplesaml/module.php”.

Even after removing the library from your web/docroot, the helper module won’t work on Pantheon. After some testing and investigation, and knowing that Pantheon uses Nginx for routing, I was able to confirm Pantheon has a special rule for paths that go to /simplesaml/*.php.

Any path following that pattern won’t be routed through Drupal. Nginx makes sure to look up for a file inside your web/docroot simplesaml folder. Hence why I was getting a text 404, instead of Drupal’s 404. I made a test to confirm this: I placed a hello.php file inside that folder that just returns a simple text message. When I went to /simplesaml/hello.php I was getting said message.

Due to this fact, the helper module route masquerading won’t work because that’s a path expected to be handled by Drupal; on Pantheon, that won’t be the case. It won’t work.

But, good news is, there’s a workaround you can use in order to confirm your migration worked! Before diving into that, I want to give a shout out to Jay Beaton, the helper module maintainer! I reached out to him on Drupal Slack about the route overrides not working. He was kind enough to listen and help me; and, after talking to him, I was able to realize and discover this Pantheon issue; and the workaround I’m going to mention was recommended by him. Thanks so much for such a great tool, and help!

4.1.2. Testing workaround

Even if you cannot test remotely, you can do it locally. SAML validation and redirections happen on the browser level, meaning that, if you change your machine DNS to point a SSO-enabled domain to your local machine environment, you will be able to test it there. This is how you do it:

1. For DDEV, you need to edit the config.yaml file and:
   1. Add the domain you want to override in the additional_fqdns property
   2. Switch to false the use_dns_when_possible property, so DDEV always updates the /etc/hosts file with the project hostname instead of using DNS for name resolution
   3. Restart DDEV
   4. If for some reason the custom domain is not reaching your local environment, make sure the custom domain is in your /etc/hosts file.
2. For lando, you can add proxies with custom domains.
   1. You will need to edit your /etc/hosts file.

And that’s it! You can now go to the custom domain while using your local environment!

5. You’re almost there

With the configuration migrated over to SAML Authentication, you should be able to use SSO. However, if your site has custom code that uses SimpleSAMLphp services or is hooked into one of its hooks, you will need to adjust your code accordingly.

For example, from the sites I’ve migrated:

1. There was code that was using the simplesamlphp_auth.manager service, specifically to call the isAuthenticated() function.
   1. I changed it to use the SAML Authentication service, samlauth.saml, and calling the getAttributes() function, which does the same as SimpleSAMLphp isAuthenticated() (it gets the attributes if the current user was logged in using SSO, otherwise, it returns an empty array).
2. The hook_simplesamlphp_auth_user_attributes and hook_simplesamlphp_auth_existing_user hooks were being used.
   1. I had to create an Event Subscriber (as SAML Authentication doesn’t use hooks for these) that hooks to SamlauthEvents::USER_LINK, equivalent to the existing user hook, and SamlauthEvents::USER_SYNC, equivalent to user attributes hook.

You will have to go and search in your code for any SimpleSAMLphp usage and change it!

6. Hurray!

That’s it. With SimpleSAMLphp out of the way, your Drupal site is no longer blocked by upstream dependencies — and you’re free to plan your Drupal 11 upgrade on your timeline. Happy coding!

When something breaks, everything is suspect: frontend, backend, third-party tools, even data. Add a looming deadline or a frustrated stakeholder, and it’s easy to spiral. That’s where self-regulation — your ability to stay calm and grounded — makes a difference.

Stay focused

Debugging is rarely a quick fix. It’s often a long, layered investigation. Before diving in, pause to reset your priorities with your team. Let them know where your focus is shifting so you’re not blocking others or working under silent pressure.

Avoid panic mode

It’s tempting to throw everything at the wall in search of a fix. Instead, start with a plan. A checklist grounds your thinking and avoids rabbit holes. We always verify recent backups first. It eases the mind and gives you room to troubleshoot confidently.

Adapt on the fly

Sometimes, quick fixes trump pristine code. If an external service is the culprit, disabling it temporarily may be the fastest way to restore core functionality. Good developers know when to ship the workaround and save the polish for later.

Take a breath

Literally. A moment of pause can often deliver the clarity you need to see what you’ve missed. Reflection is part of the process, not a delay.

Self-awareness leads to smarter decisions. It’s easy to jump straight into the code when something’s on fire. But emotional intelligence asks you to take stock first — of the problem and of yourself.

Start with understanding

When a support ticket lands without much context, error logs are your best friend. Don’t chase the first error message you see. Read across layers, cross-check symptoms, and build a hypothesis. The goal is clarity, not just activity.

Watch for burnout

Long debugging sessions can drain even the most seasoned devs. If you catch yourself getting foggy or frustrated, step away or ask for backup. A fresh set of eyes (or even a walk around the block) can save hours of spinning.

Communicate clearly

Whether you’re debugging solo or as part of a team, updates matter. Share what you’re trying, what you’ve ruled out, and what’s next. This keeps everyone aligned, reduces duplicate effort, and turns a problem-solving moment into a learning opportunity.

It’s easy to think of debugging as a purely technical task. But the truth is, it’s a test of patience, process, and emotional resilience.

Every problem is an opportunity to learn, not only to grow your technical skills, but to also build your emotional intelligence. Debugging is a skill that, with practice, can transform overwhelming chaos into a well-managed and structured process for success.