Connecting Claude to a production Joomla site

What this is not

Start with what is absent from this story — otherwise it is easy to assume we mean yet another plugin with a "generate text" button.

This is not a CMS plugin. It is not a service you feed keywords to and receive articles from. And it is not an autopilot: no change reaches the site without a person who said what exactly needed doing. The assistant works here like a contractor with site access — fast, meticulous and entirely unoffendable, but a contractor, not the owner.

Five access channels, and why that many

The first discovery: one way of reaching the site is not enough. Each new channel appeared when the previous one hit a wall.

• An MCP connector. A layer between the assistant and Joomla's own API: around two hundred and fifty operations — articles, categories, menus, modules, tags, media files. The main working channel.
• The API directly. For whatever the connector cannot do. Menu item meta tags, for instance, live inside a parameters field and can only be written with a direct request.
• The database. Reading constantly, writing rarely and deliberately. Some things the API silently filters out: a structured-data block inside an article body gets stripped while the response says "success".
• The hosting filesystem. Mounted as a network drive. Template, robots.txt, server logs, plugin sources. Reading Joomla's own source code has repeatedly produced an answer faster than searching the documentation.
• A real browser with the admin panel open. For what the API does not offer at all. Today that was needed twice: to clear the cache and to re-save component settings, without which a parameter written straight into the database would not take effect.

Why one channel is not enough — a concrete case

Today's task: remove the numeric identifier from article URLs, so that /en/blog/95-japanese-keyword-hack becomes /en/blog/japanese-keyword-hack.

The setting is not available through the API: only twenty-one parameters are exposed and this is not among them. We wrote the value straight into the database — and nothing changed: URLs without the identifier still returned 404. A full cache clear did not help either. It only worked after the component settings were re-saved through the admin panel in a browser: extension settings live separately from the ordinary cache.

Three channels to flip one switch. On the other hand it is now recorded in the project's memory, and next time the task will take a minute.

Memory — without it the whole thing is useless by day two

A language model does not remember yesterday. If every session starts from scratch, the assistant will work out afresh which identifier an article has, where the template lives, and why a template style must never be saved without its page list. By the third time it stops being worth it.

So knowledge about the project sits in files next to the assistant:

• A site map — five and a half thousand lines: identifiers for every article, menu item, category, template style and module. Not approximations but exact values verified against the live site.
• An API handbook — working recipes and required fields: what must be sent so a request does not wipe neighbouring data.
• Writing requirements — who the reader is, what language to use with them, which phrases are banned.
• Fifty-two notes on what has already happened: incidents, causes found, decisions taken.

This is the value that accumulates. The model is replaceable; the map of the project is not.

Safety catches: the story of forty-six assignments

On 21 August an ordinary save of a template style through the API silently detached forty-six of its sixty-one language pages. Server response: 200 OK, no errors, the site visually intact, and half the pages stripped of their design.

The cause lay in how Joomla works: the list of assigned pages is part of the style form, so on save the system first clears the assignments and then re-applies whatever arrived in the request. Send no list, and the assignments vanish.

The conclusion drawn was not "be more careful next time" but a technical one: a handler was written that blocks such a save before it executes. Since then the mistake has been impossible. That is the important principle — every expensive error should turn into a safety catch, not a reminder.

What a working day looks like

Today's, unembellished. In the morning the machine came back from an unexpected shutdown the evening before, and every session from the previous day was dead. Restoring context took about ten minutes: the system logs explained what had happened, and the unfinished work was found in files.

Then, in order: three translations of an article started yesterday were finished, identifier-free URLs were switched on with a control run across the sixty addresses in the sitemap, and four new articles were written and published, each in four languages. Sixteen texts, each with its own meta tags, structured data and language links. Plus a broken internal link discovered and fixed in already-published material.

Verifying the result does not mean "the server answered 200" — it means the live page and the structured data validator. Across all sixteen articles: zero errors, zero warnings.

What genuinely gets faster

• Repetitive work across several languages. Four language versions with correct links and markup is exactly where a human errs from fatigue and a machine does not.
• Checks. Run sixty URLs before a change and after it, compare response codes, find the discrepancy — minutes instead of an hour.
• Diagnostics. Read a plugin's source, find the parameter, check server logs, cross-reference with the database. Here the difference against manual work is severalfold.
• Incident analysis. In September we cleaned an infected client site: seven hundred and seventy-seven foreign files, the oldest backdoor dated December 2022. Finding and removing that by hand is weeks of work.

What does not get faster

Honesty matters here, otherwise the account turns into an advert.

Decisions. What to write, in what tone, at what price, whether to take on a topic at all — still a person. The assistant executes excellently and decides poorly.

Taste. Design, page composition, the sense of whether something looks cheap or expensive — not its strength. It assembles a grid to the rules, but a person supplies the rules.

Responsibility. The site is live, changes show immediately, there are no automatic snapshots. Every edit is an edit in production. Hence the unchanging order: read the current state, then write, then check on the live page.

Three traps that cost time

The most useful moments were not the successes but the places where everything looked successful and did not work.

• The date drifts by two hours. Every article update through the API moved the creation time two hours back — the system read the stored value as local time and converted it to UTC a second time. Four edits in a row shifted the date by eight hours. The fix is sending the time in local format with every request.
• A "success" response with no result. The structured-data block in an article body is stripped by a filter when written through the API. Response 200, no errors, no markup. What has to be checked is the database field, not the response.
• The cache hides the change. That morning ten-hour caching had been switched on. The change was saved, the page served the old version, and my first conclusion was wrong — I decided the template was at fault. The correct conclusion: "the edit is not showing" now means the cache until proven otherwise.

Is it worth repeating

The honest answer: it depends how much repetitive work you have.

If the site is five pages in one language and changes once a quarter — no. Setting it up will cost more time than it saves.

The setup pays off where there is volume and repetition: several languages, regular publishing, a catalogue, integrations, recurring checks. And where someone in the company is willing to write tasks down and check the results. Without that second condition you get a generator of plausible-looking rubbish.

One more observation: almost all the value turned out to lie not in the model but in the surrounding apparatus — the access channels, handbooks, safety catches and accumulated project memory. The model can be swapped for the next version in an evening. Six weeks of accumulated knowledge about one specific site cannot.

In short

Five access channels because one is not enough. A project map in files because the model does not remember yesterday. Safety catches built from expensive mistakes, because "be more careful" does not work. Verification on the live page rather than from a server response. The result: nineteen articles in four languages in a day, and an infected site diagnosed in twenty-four hours instead of weeks.

And what does not change: a person still decides, and the site stays live, where every edit is immediately visible to customers. If you would like to discuss whether this applies to your project, write to us. How we work on websites in general is described on the Process page.

Victor Parhimchik, founder of the IT Deweloper web studio