Background
Drupal (https://drupal.org) is one of the oldest and most battle-tested open source CMS platforms out there — it's been around since 2000 and powers a huge chunk of the web. We're talking government sites (whitehouse.gov ran on Drupal for years), universities, major media companies, and enterprises worldwide. The Drupal community is enormous, with tens of thousands of contributed modules and a very active ecosystem.
What makes Drupal interesting from a code intelligence perspective is that it's not your typical MVC framework. It has a unique hook-based architecture where modules extend the system by implementing functions with specific naming conventions (e.g. mymodule_form_alter, mymodule_node_presave), plus a YAML-based routing system, a powerful dependency injection container, plugin system, and entity API. This means a lot of the application logic lives in .module and .install files, YAML configs, and PHP classes — spread across custom modules and themes.
What's missing
Right now CodeGraph doesn't understand Drupal projects at all. If you open a Drupal codebase, you get raw symbol detection but none of the framework-specific relationships — no routes, no hook call graph, no service wiring. For anyone using Claude Code or Cursor on a Drupal project, the context you get is much weaker than what you'd get on a Laravel or Symfony project.
What I'd love to see
A Drupal framework resolver similar to how Laravel is handled, covering the main patterns:
Detection
composer.json containing drupal/core or drupal/core-recommended- Presence of
web/core/ or core/includes/bootstrap.inc (classic installs)
.module, .install, .theme file extensions alongside PHP
Routing
- Parse
*.routing.yml files — each route entry has a path, a controller class + method, and optional requirements
- These should map to
route nodes so callers/callees work across routes
- Also handle the older hook_menu() style routes (Drupal 7 compat, still common in legacy codebases)
Hooks
- Functions named
{module}_hook_name() that match known Drupal hook signatures (hook_form_alter, hook_node_insert, hook_cron, etc.)
- These are effectively event handlers and should be surfaced as such
Services & DI
*.services.yml files define services with class mappings and dependencies- Would be great if these fed into the call graph so you can trace what gets injected where
Plugins
- Drupal's Plugin system is annotation-based (e.g.
@Block, @FieldFormatter, @QueueWorker)
- Classes under
src/Plugin/ with these annotations are essentially route/entry-point equivalents
Forms & Controllers
- Classes extending
FormBase or ConfigFormBase — the buildForm, validateForm, submitForm methods are important entry points
- Classes extending
ControllerBase with methods wired to routes via routing.yml
Why it matters
Drupal codebases tend to be large and heavily modular. The hook system means logic is intentionally scattered — you might have 15 different modules all implementing hook_form_alter on the same form. Without a framework-aware graph, there's no way to answer "what alters this form?" or "what implements hook_node_presave?". That's exactly the kind of question CodeGraph should be able to answer.
Would be happy to help with implementation details or test fixtures if that's useful.
Background
Drupal (https://drupal.org) is one of the oldest and most battle-tested open source CMS platforms out there — it's been around since 2000 and powers a huge chunk of the web. We're talking government sites (whitehouse.gov ran on Drupal for years), universities, major media companies, and enterprises worldwide. The Drupal community is enormous, with tens of thousands of contributed modules and a very active ecosystem.
What makes Drupal interesting from a code intelligence perspective is that it's not your typical MVC framework. It has a unique hook-based architecture where modules extend the system by implementing functions with specific naming conventions (e.g.
mymodule_form_alter,mymodule_node_presave), plus a YAML-based routing system, a powerful dependency injection container, plugin system, and entity API. This means a lot of the application logic lives in.moduleand.installfiles, YAML configs, and PHP classes — spread across custom modules and themes.What's missing
Right now CodeGraph doesn't understand Drupal projects at all. If you open a Drupal codebase, you get raw symbol detection but none of the framework-specific relationships — no routes, no hook call graph, no service wiring. For anyone using Claude Code or Cursor on a Drupal project, the context you get is much weaker than what you'd get on a Laravel or Symfony project.
What I'd love to see
A Drupal framework resolver similar to how Laravel is handled, covering the main patterns:
Detection
composer.jsoncontainingdrupal/coreordrupal/core-recommendedweb/core/orcore/includes/bootstrap.inc(classic installs).module,.install,.themefile extensions alongside PHPRouting
*.routing.ymlfiles — each route entry has a path, a controller class + method, and optional requirementsroutenodes so callers/callees work across routesHooks
{module}_hook_name()that match known Drupal hook signatures (hook_form_alter, hook_node_insert, hook_cron, etc.)Services & DI
*.services.ymlfiles define services with class mappings and dependenciesPlugins
@Block,@FieldFormatter,@QueueWorker)src/Plugin/with these annotations are essentially route/entry-point equivalentsForms & Controllers
FormBaseorConfigFormBase— thebuildForm,validateForm,submitFormmethods are important entry pointsControllerBasewith methods wired to routes via routing.ymlWhy it matters
Drupal codebases tend to be large and heavily modular. The hook system means logic is intentionally scattered — you might have 15 different modules all implementing
hook_form_alteron the same form. Without a framework-aware graph, there's no way to answer "what alters this form?" or "what implements hook_node_presave?". That's exactly the kind of question CodeGraph should be able to answer.Would be happy to help with implementation details or test fixtures if that's useful.