Drupal native, not generic: what a Drupal-native tool adds on top of reading your code

Drupal code intelligence means analysis that understands hooks, services, render arrays and cache tags, on top of the PHP they are written in. That is what EventHorizon adds, a Drupal-specific layer that builds on reading the code.

The short version

• General AI coding tools read PHP syntax well. Drupal adds another layer on top: hooks, services, render arrays, cache metadata, and configuration entities.
• EventHorizon is built around that model. It reads and analyses a codebase the way Drupal is structured, by its hooks, services, and relationships.
• That extra layer shows up exactly where it matters most: cache tags, dependency injection, module relationships, and config integrity.
• Everything runs as static analysis first. AI is optional, opt in per project, and uses your own key and your own model.
• Built for Drupal 8 to 11, for the people who live in Drupal every day.

I have spent close to ten years building and maintaining Drupal. In that time I have inherited more projects than I can count, and almost all of them arrived the same way. A zip file, a thin README, and a question I could not honestly answer on day one: what in here is going to hurt in production?

Last year I tried something out of curiosity. I pointed a popular AI coding assistant at one of those inherited codebases and asked it a plain Drupal question. Where is this custom block missing its cache tags? It gave me a confident, well written answer that read the PHP correctly. The fuller answer needed the Drupal context behind the code. The model did its job well: it was reading PHP, and reading Drupal is a further layer on top.

That gap is the entire reason EventHorizon exists, and it is what this post is about.

What does "Drupal native" actually mean?

EventHorizon is a Drupal-native code intelligence platform. It reads a codebase as a senior Drupal engineer might, by hooks, services, render arrays, cache metadata, and configuration, then turns that into visual maps, health scores, and answers grounded in your own code.

"Drupal native" is not a tagline I reach for because it sounds good. It is a description of where the knowledge lives. A general-purpose tool knows the PHP language well. A Drupal-native tool also knows what the PHP is doing inside Drupal. Those are two complementary kinds of understanding, and the second is where Drupal-specific issues tend to surface.

What makes Drupal different for a general-purpose assistant?

Drupal is not really written in PHP. It is written in Drupal, which happens to use PHP as its surface language. Almost everything that matters lives in conventions and structures that are specific to Drupal itself.

Take a function named mymodule_node_presave. On the surface it is a function with an underscore in its name. To Drupal it is a hook implementation, fired by the system every time a node is saved, with a defined contract and a place in a much larger lifecycle. That context is the difference between reading the function and understanding what it does.

A few more places where the Drupal context is worth knowing:

• A render array looks like an ordinary associative array, and its #cache keys are what decide whether a page is fast or slow.
• A service defined in a .services.yml file and injected through a constructor makes sense once you read the YAML and the constructor together.
• A static \Drupal::service(...) call reads as ordinary code, and it is often a good chance to move toward cleaner dependency injection.
• Configuration lives in YAML rather than PHP, so a broken field reference or an orphaned paragraph type sits in a layer worth reviewing alongside the code.

General-purpose tools are genuinely useful here. They help you write a function, explain a snippet, and reason about code at the language level. Reasoning about a whole Drupal system simply adds an extra layer of context on top, the conventions and structures that hold the system together.

What does EventHorizon add for a Drupal codebase?

The short answer is structure. EventHorizon breaks your code down the way Drupal is organised, one meaningful unit at a time, and it carries Drupal's own rules along with it.

It chunks by meaning. When EventHorizon indexes a project, one function becomes one unit. One service becomes one unit. So do modules, fields, content types, paragraphs, and even grouped findings. A function chunk keeps its docblock, its metadata, and its caller and callee relationships. A service chunk keeps its class definition, its dependencies, and its public methods. A function stays whole, so the related pieces of it travel together.

It carries a Drupal hooks reference. During indexing it loads a catalogue of Drupal hooks, so it recognises a hook implementation as a hook by matching the catalogue.

It encodes Drupal's caching model as real checks. EventHorizon ships sixteen caching detectors that understand Drupal's cache API specifically. They look for the issues that cost you the most, missing cache tags and missing cache contexts when the output depends on the current user, among others. Each one maps to a pattern a Drupal performance reviewer looks for.

Configuration counts as code here. If your project ships a config sync directory, EventHorizon validates it: broken references where a field points at a content type that no longer exists, orphaned paragraph types defined but never used, and circular dependencies where paragraph types reference each other in a loop. That adds a content model audit on top of the code review.

It maps relationships across files. The dependency mindmap is a force-directed graph where modules are nodes and edges are real dependencies. Each node is sized by its code surface, the number of functions and services it holds, so a heavyweight module reads bigger on sight. You can switch between module, function, and service views, colour coded by type: a custom module is a filled blue node, a contrib module is a hollow blue ring, a theme is purple, and core sits as a dashed blue outline. EventHorizon decides that custom, contrib, core, and theme split by reading the nearest .info.yml type: key and the canonical Drupal directory layout, so a module that happens to ship a themes/ subdirectory is still read as a module, and every finding is tagged to the extension it actually lives in. Circular dependencies, the kind that hide in the code until an upgrade trips over them, show up as loops you can see early.

All of that rolls up into health scores from 0 to 100 for performance and security, so a non-technical stakeholder can read "performance is sitting at 68, here is what is dragging it down" in plain language, with the code detail there for whoever wants it. The dashboard even switches between a developer view, with the code-level tools front and centre, and a PM and client view that leads with the shareable quality signals, so each audience sees the right thing first.

What does this look like on a real codebase?

Picture a custom module with a block that renders a list of recent articles. The query runs on every request, there is no #cache metadata on the render array, and the block depends on the current user without saying so.

A general-purpose assistant, asked to review it, will tell you the PHP is clean. It is. The syntax is fine, the logic reads well, nothing is obviously broken.

EventHorizon reads the same block and adds another layer to the picture. It flags the render array as rebuilt on every request, points out that the output depends on the user but the cache contexts do not mention it, and notes the uncached database query sitting inside the build. Same code, two complementary reviews. One reads the syntax, the other reads how it behaves inside Drupal.

This is the part that is hard to communicate until you watch it happen on your own project. The behaviour lives in how the PHP behaves inside Drupal's render and cache pipeline, and that is where a Drupal-native tool focuses.

Does the AI ever see my code?

This is the first question every agency and every enterprise security team asks me, and it is the right question.

The honest answer is that the AI is optional and off by default. Every analysis in EventHorizon runs as static analysis first, with zero AI required. The dependency maps, the performance and security scans, the caching checks, the config validation, all of it works without a model ever being involved.

If you do want the AI chat, you turn it on per project, you bring your own key, and you choose your own model from Gemini, OpenAI, or Anthropic. Retrieval runs against a per-user, project-specific knowledge base that is built and queried locally, so only the final answer step ever reaches your chosen provider, and answers come back with source attribution so you can see which part of your code the answer is built on. I will go deeper on this architecture in a later post in this series, because for regulated and enterprise Drupal it deserves its own discussion.

Who is this for?

EventHorizon is built for the people who carry Drupal codebases for a living.

For agencies, it shortens one of the slower parts of taking on a new client, the days of spreadsheet archaeology before anyone can give an estimate with a straight face. You connect a GitHub repository, pick the branch you want to read, and EventHorizon takes it from there.

For enterprises and product companies, it turns major version upgrades and platform risk from a leap of faith into something you can see, measure, and plan around. For architects and team leads, it gives meetings a graph everyone can read.

The common thread is simple. If your business runs on Drupal, a tool built around Drupal gives you a clearer view of it.

The bigger picture

I built EventHorizon to read Drupal as Drupal. Plenty of general scanners already do a lot well, and EventHorizon adds the Drupal-specific layer on top, where subtle, costly issues often live.

A general tool reads your code well. A Drupal-native one also reads your Drupal. That difference is what I most wanted to put in other people's hands, after close to a decade of doing this work by hand.

This is the pillar of a five part series. The companion posts go deeper on each piece: performance and cache tags, Drupal-aware security, dependency maps and de-risking upgrades, and keeping your code private.

EventHorizon will not write your Drupal for you. It will help you understand the Drupal you already have. And that understanding is the foundation of every good decision you make on a Drupal project.

---