Module Matrix rebuilds Drupal's Extend and Uninstall screens into a filterable, package-grouped interface, so that finding one module among two hundred is a two-second search instead of a scroll.
It does not replace those pages or add a route of its own. Read from src/Hook/ModuleMatrixHooks.php, it alters core's existing system_modules form and preprocesses the module details and uninstall templates. You go to /admin/modules exactly as before; what renders there is different.
Why the Extend page stops scaling
Core's module page is a long list of collapsible details elements grouped by package. That is fine at thirty modules. At a hundred and fifty — which is an ordinary count for a site that has been live for five years — three specific jobs become slow: finding a module whose exact name you half-remember, seeing at a glance which packages contain something disabled, and answering "is this thing still supported?" before you build on it.
The last one is the expensive question. A deprecated or obsolete module that nobody noticed is how a site arrives at an upgrade with a dependency that has no Drupal 11 release. Core's Extend page will not tell you; it shows the name, the description and a checkbox.
What Module Matrix puts on that page
Four filters, all client-side
A text box matches on name and description as you type. Three checkbox groups then narrow by status (enabled, disabled, unavailable), by lifecycle (active, deprecated, experimental, obsolete) and by stability (stable, release candidate, beta, alpha, dev). A reset button clears the lot.
Lifecycle and stability answer different questions and people confuse them. Lifecycle is what the maintainer says about the module's future — a stable release of an obsolete module is still obsolete. Stability is where the current release sits in the release cycle. You want both columns visible when you are planning an upgrade, and neither is on the core page.
Package navigation with counts
Packages are listed as their own navigation panel with three counts each: total modules, enabled, and disabled. That is the view that catches the thing you forgot — a package where four of six are on, when you believed the whole feature had been switched off.
Thirteen detail fields you choose from
Each module row can carry any subset of thirteen information fields, counted from the module's configuration schema: machine name, version, lifecycle, requires, required by, status, project, subpath, last modified time, stability, links, issue link and usage link. You turn on the ones your team actually reads and the rest never render. Where nothing is selected, the description shows plainly with no accordion wrapper at all, which keeps the page from filling with empty toggles.
This is the setting worth spending two minutes on. A site builder auditing an upgrade wants version, lifecycle, stability and required-by. Someone hunting a configuration form wants links and machine name. They are not the same page, and the module lets you have either.
If the real problem is that nobody can say what two hundred installed modules are for, that is an audit rather than a screen — see Drupal services.
Layout, colour and the settings form
The settings live at /admin/config/system/module-matrix-settings, behind a single permission, access module matrix settings. Three layouts position the package panel left, right or across the top, and the layout collapses for narrower screens. A style mode selector offers light, dark, or none — and "none" is a real option, not a placeholder: it drops the module's own styling and leaves the browser and your admin theme in charge. Six accent colours are available in both light and dark: teal, coral, indigo, gold, slate and neutral. Grid layout, compact mode and a scrollable package sidebar are separate toggles.
If you are the person who ends up doing this kind of tidying on other people's sites, the same instinct applies to configuration itself — there is a related write-up on Drupal configuration and management practices that covers the config side of keeping a large site legible.
Module Matrix compared with Module Filter
Module Filter is the long-established option and it is mature. The honest comparison:
- JavaScript: Module Matrix's main library loads nine vanilla JavaScript files, of the eleven that ship with the module, whose only declared dependencies are
core/drupal,core/drupalSettingsandcore/once. There is no jQuery in its libraries. - Navigation model: Module Filter uses tabs or a dropdown. Module Matrix uses a persistent package panel in one of three positions.
- Filters: lifecycle and stability filtering are in Module Matrix and not in Module Filter.
- Presentation: dark mode, accent colours, compact mode, grid layout and per-field detail selection are Module Matrix features.
- Maturity: Module Filter has years of installs behind it. That is a real advantage and should count.
They solve the same irritation from different directions. If tabs work for you, keep Module Filter.
What it does not do
It is a presentation layer over core's own module data. It does not resolve dependency conflicts, does not tell you whether an upgrade will succeed, and does not check drupal.org for available updates — that remains core's Available Updates report. It also does nothing for you on the command line; if your workflow is entirely drush pm:list, this module is not aimed at you.
Installing it is also a decision about the admin experience your client sees. On a site where the client never opens the Extend page, it earns nothing.
Requirements and install
Read from module_matrix.info.yml: core_version_requirement: ^10 || ^11 || ^12, php: ^8.1, and one dependency, core's system. It is one of the few modules in this space that already declares Drupal 12 support. Install it with composer require drupal/module_matrix, enable it, rebuild caches, then set your detail fields before you judge it — the defaults show only some of the thirteen.
Common questions
Does it change the Uninstall page too?
Yes. There is a separate preprocess hook and a separate stylesheet for system_modules_uninstall, so both admin screens are covered.
Can I stop editors from changing the settings?
Yes. Everything is behind the access module matrix settings permission, so grant it to administrators only and the interface stays as you configured it.
Will it slow down a site with 300 modules?
Filtering is entirely client-side, so no request is made while you type. The page still renders the same module data core renders. Needs checking on your own hardware if your module count is unusual.
Does it work with Gin or Claro?
It ships its own layout and accent styling and does not depend on an admin theme. Setting style mode to "none" hands presentation back to the admin theme entirely. Verified from the shipped libraries, not tested visually against Gin in this pass.
Where to go next
The Module Matrix project page has the full feature list and screenshots. If you are assembling a stack rather than fixing one screen, the Drupal 11 modules and themes round-up is the wider view, and Selectify covers the same treatment applied to forms rather than the module list. If the real problem is that nobody knows what those two hundred modules are for any more, that is an audit, and it is what Drupal services and the Drupal architect work exist to do.
Module Matrix is a module I wrote and maintain. I have worked in web development since 2005 and I am the author of Drupal modules and themes, listed on my drupal.org profile.
