MCP for VMT + ET Templates is a free add-on for MCP for J that answers a question nothing else on your site can: which of your template's VirtueMart overrides have quietly stopped matching the VirtueMart underneath them. Every VMT template ships frozen copies of VirtueMart's own view files, and when VirtueMart updates, those copies don't. There's no error and no log entry โ your shop just never gains the feature, or a renamed helper white-screens a page. Thirteen tools cover that check and the everyday jobs around it: template inventory, changelog extraction, parameter writes validated against the template's own options, and file access at the legacy path Joomla's newer tooling can't reach.
Why this exists
A template override is a copy, and copies go stale. When your VMT template wanted the product page to look a particular way, the way to get that was to take VirtueMart's product-page view file, put a modified copy inside the template, and let Joomla serve the copy instead. That works, and it keeps working, which is exactly the problem โ VirtueMart keeps improving the original and your copy sits there shadowing it. A feature lands in VirtueMart 4.2 that you never see. A helper function gets renamed and the page it's called from goes white at three in the morning; the fleet-wide PHP 8 fix to user/edit_address.php was precisely that failure. Across the roughly sixty-nine templates in the VMT range, at around fifteen overrides each, that's on the order of a thousand frozen copies of VirtueMart files out there. Nothing in Joomla tells you which have rotted. Nothing in VirtueMart tells you either. check_vmtet_override_drift reads every override on your site, finds the core file it shadows, compares the two, and tells you.
What the drift check tells you
Each override comes back with one of four verdicts, and the difference between them matters more than the count.
| Verdict | What it means |
|---|---|
orphan | The core file this override shadows isn't there any more. VirtueMart removed the view and your template is still standing in front of the hole. This is the one to act on first. |
possibly_stale | The override differs from core, and the core file is newer. Probably behind upstream โ but check before you believe it. |
diverged | The override differs from core and core isn't newer. This is the healthy state for a branded override, and most of yours will be here. |
identical | Byte-for-byte the same as core, so the override isn't doing anything at all. |
possibly_stale is hedged deliberately. It leans partly on file modification times, and a deploy or a Joomla update rewrites those wholesale, so a whole template can look freshly stale on a day nothing changed. The number to weigh more heavily is the count of substantive lines present in the core file and absent from your override. When one of them looks worth a second opinion, diff_vmtet_override shows you the actual lines you're missing, so you can tell deliberate branding from code that's fallen behind.
What Claude can do
Thirteen tools across five groups. Everything except the inventory takes the template's element (its folder name), which is what the inventory hands you.
| Area | Tools | What you can do |
|---|---|---|
| Overrides | 3 | List every override a template ships and what each one shadows, run the drift check, and diff a single override against the core file behind it. |
| Templates | 2 | Inventory every VMT and ET template on the site with its version, style rows and whether it's the site default; pull the changelog back out of the manifest as structured entries. |
| Configuration | 3 | Dump a template's full options schema, read a style with every stored value annotated against that schema, and write parameters that are checked against it before anything is saved. |
| Files | 3 | List, read and write files inside one of your templates at the legacy path, with PHP writes gated per call. |
| Diagnostics | 2 | See what's installed on an unfamiliar site, which template is serving the front end and which VirtueMart version is present, and run a five-check health audit per template. |
Why the parameter writes are different
MCP for J already ships a tool that writes template style parameters, and its merge logic is correct. What it can't do is tell whether the key you handed it is real. Write sitenamecolour when the template calls it sitenamecolor and the typo is stored quite happily โ nothing reads it, nothing errors, and the setting just appears not to work for a reason nobody can find. set_vmtet_template_params validates every key and every value against the installed template's own options first, and refuses the whole call rather than applying half of it.
That validation has to be per-template, which is the part that surprised me. There genuinely is a house schema across the range: eighty-six option names were common to all eight templates sampled, and a Crystal major-version bump kept a hundred and sixty-four of a hundred and sixty-five names. But the totals run from a hundred and thirty-nine options on one template to three hundred and seventy-five on another. A single hardcoded list would have rejected perfectly valid settings on half the fleet, so the tool reads each template's own definitions instead.
Installing it
You'll need Joomla 5 or 6, PHP 8.2 or later, MCP for J, and at least one VMT or ET template installed. VirtueMart is only needed for the override tools, since plenty of ET templates are ordinary Joomla templates.
- Open Components โ MCP for Joomla โ Browse MCP Add-Ons and click Install on this add-on. You can also download the ZIP above and install it through System โ Install โ Extensions.
- That's the whole install. The plugin enables itself, and the tools show up in your connected AI client the next time it lists them.
There's no admin screen for the plugin, by design โ it adds tools to MCP for J rather than a place to click. On a site with no VMT or ET template installed the tools don't disappear; they refuse with a message that says why, which is more useful than silence when you're trying to work out whether the plugin is even loaded.
Using it
Start with "what VMT or ET templates are on this site, and which one is live?" Then "check the live one for override drift" and read the orphans first. "Show me what the product-page override is missing" gets you the diff. "Run the health check on every template here" is the version to use when you've inherited a site and want the whole picture in one go.
That health check is worth knowing about on its own, because the drift check is only one of the five things it looks at. It also compares the version in the template's manifest against the version Joomla has cached in its extensions table โ those drift apart whenever template files are updated over FTP or rsync without a reinstall, which is how fleet patching actually gets done, and Joomla then reports the cached version everywhere including to the update server. It compares the manifest version against the newest changelog entry embedded in that manifest, since a mismatch means a release pipeline that didn't run cleanly. It checks the files the manifest declares against what's actually on disk, which catches a half-extracted upload. And it compares the stored parameters against the current options, so you can see settings left orphaned by a version bump and values that are no longer legal choices.
Permissions and security
Almost everything here is read-only. Two tools write: one sets template parameters, and one writes files.
The file writer is the one to be careful with, and it's built accordingly. MCP for J's core file tools refuse to write .php at all, and that decision is a good one โ a template file that executes is remote code execution if a token ever leaks. This add-on doesn't weaken that. It adds a separate, narrower door: writing a PHP file requires an explicit flag on every single call, there's no setting that makes it stick, the target has to be one of these templates rather than any folder on the site, the content is syntax-checked first where the host allows it, and the previous version of the file is always backed up with the backup path returned to you. The realistic failure being defended against isn't an attacker โ it's a bad override taking a storefront down overnight, with nobody around who knows what changed.
One thing the backup doesn't protect you from: reinstalling or updating the template through Joomla overwrites everything written this way. These are vendor files, not custom ones. That's simply what patching an override in place means, and it's why a patched override has to be re-applied after every template release.
An honest caveat
Three of the thirteen tools โ the ones that list, read and write template files โ exist because of a gap in MCP for J itself rather than because they're a good idea. MCP for J's file tools resolve template paths under media/templates/, which is where Joomla 4 and later put things. VMT and ET templates install to the older templates/ path and declare no media folder, so as far as core is concerned they aren't installed at all and it says so. The right fix is to teach the core path resolver about the legacy location, and when that happens these three tools become redundant and should be retired. The durable value of this add-on is the drift detection. The path workaround is scaffolding, and it's labelled as scaffolding here so nobody has to guess later.
Open source
GPL-2.0-or-later, the same license as Joomla itself. If you have installed it, you are entitled to the source under those terms โ ask us and we will send it.
Add comment