Как мы подключили Claude к боевой Joomla

Чем это не является

Начнём с того, чего в этой истории нет, — иначе легко решить, что речь про очередной плагин с кнопкой «сгенерировать текст».

Это не плагин для CMS. Это не сервис, куда загружают ключевые слова и получают статьи. И это не автопилот: ни одна правка не уходит на сайт без человека, который сказал, что именно нужно сделать. Ассистент здесь работает как подрядчик с доступом к сайту — быстрый, дотошный и абсолютно не обидчивый, но подрядчик, а не владелец.

Пять каналов доступа, и зачем их столько

Первое открытие: одного способа достучаться до сайта не хватает. Каждый следующий канал появлялся тогда, когда предыдущий упирался в стену.

• Коннектор MCP. Прослойка между ассистентом и штатным API Joomla: около двухсот пятидесяти операций — статьи, категории, меню, модули, теги, медиафайлы. Основной рабочий канал.
• Штатный API напрямую. Когда коннектор чего-то не умеет. Например, метатеги пункта меню лежат внутри поля параметров, и записать их можно только прямым запросом.
• База данных. Чтение — постоянно, точечная запись — редко и осознанно. Есть вещи, которые API молча отфильтровывает: блок микроразметки в теле статьи он вырезает и отвечает «успешно».
• Файловая система хостинга. Смонтирована как сетевой диск. Шаблон, robots.txt, логи сервера, исходники плагинов. Именно чтение исходного кода Joomla несколько раз давало ответ быстрее, чем поиск в документации.
• Реальный браузер с открытой админкой. Для того, чего в API нет вообще. Сегодня это понадобилось дважды: сбросить кэш и пересохранить настройки компонента, без чего параметр, записанный прямо в базу, не применялся.

Почему одного канала мало — конкретный случай

Сегодняшняя задача: убрать числовой идентификатор из адресов статей, чтобы вместо /ru/blog/93-japanese-keyword-hack открывалось /ru/blog/japanese-keyword-hack.

Через API настройка недоступна: наружу отдаётся всего двадцать один параметр, и нужного среди них нет. Записали значение прямо в базу — и ничего не изменилось: адреса без идентификатора продолжали отдавать 404. Полная очистка кэша тоже не помогла. Заработало только после того, как настройки компонента пересохранили через админку в браузере: настройки расширений живут отдельно от обычного кэша.

Три канала, чтобы поменять один переключатель. Зато теперь это записано в память проекта, и в следующий раз задача займёт минуту.

Память — то, без чего всё это бесполезно на второй день

Языковая модель не помнит вчерашний день. Если каждую сессию начинать с нуля, ассистент будет заново выяснять, какой у статьи идентификатор, где лежит шаблон и почему нельзя сохранять стиль без списка страниц. На третий раз это перестаёт окупаться.

Поэтому знание о проекте хранится в файлах рядом с ассистентом:

• Карта сайта — пять с половиной тысяч строк: идентификаторы всех статей, пунктов меню, категорий, стилей шаблона, модулей. Не «примерно», а точные значения, проверенные на живом сайте.
• Справочник по API — рабочие рецепты и обязательные поля: что нужно передавать, чтобы запрос не стёр соседние данные.
• Требования к текстам — кто читатель, каким языком с ним говорить, какие обороты запрещены.
• Пятьдесят две заметки о том, что уже случалось: инциденты, найденные причины, принятые решения.

Это и есть главная ценность, которая накапливается. Модель заменяема, а вот карта проекта — нет.

Предохранители: история про сорок шесть привязок

Двадцать первого августа обычное сохранение стиля шаблона через API молча отвязало от него сорок шесть языковых страниц из шестидесяти одной. Ответ сервера — 200 OK, ошибок нет, сайт визуально цел, а половина страниц потеряла оформление.

Причина оказалась в устройстве Joomla: список привязанных страниц — часть формы стиля, и при сохранении система сначала обнуляет привязки, а потом расставляет их заново по тому, что пришло в запросе. Не прислал список — привязки исчезли.

Вывод из этого сделали не «впредь быть внимательнее», а технический: написан обработчик, который блокирует такое сохранение до его выполнения. С тех пор эта ошибка невозможна в принципе. Это важный принцип: любая дорого обошедшаяся ошибка должна превращаться в предохранитель, а не в напоминание.

Как выглядит рабочий день

Сегодняшний, без прикрас. Утром компьютер включился после аварийного выключения накануне, и все вчерашние сессии оказались мертвы. Восстановление контекста заняло около десяти минут: по журналам стало понятно, что произошло, а незаконченная работа нашлась в файлах.

Дальше по списку: доделаны три перевода начатой вчера статьи, включены адреса без идентификаторов с контрольным прогоном шестидесяти адресов карты сайта, написаны и опубликованы четыре новые статьи на четырёх языках каждая. Шестнадцать текстов, каждый со своими метатегами, микроразметкой и языковыми связями. Плюс найдена и исправлена битая внутренняя ссылка, попавшая в уже опубликованный материал.

Проверка результата — не «ответ сервера 200», а живая страница и валидатор разметки. По всем шестнадцати статьям: ноль ошибок, ноль предупреждений.

Что реально ускоряется

• Однотипная работа на нескольких языках. Четыре языковые версии с правильными связями и разметкой — это ровно то место, где человек ошибается от усталости, а машина нет.
• Проверки. Прогнать шестьдесят адресов до правки и после, сравнить коды ответа, найти расхождение — минуты вместо часа.
• Диагностика. Прочитать исходник плагина, найти нужный параметр, проверить логи сервера, сопоставить с базой. Здесь скорость отличается от ручной работы в разы.
• Разбор инцидентов. В сентябре у клиента чистили заражение сайта: семьсот семьдесят семь чужих файлов, самая старая закладка датирована декабрём 2022 года. Найти и вычистить это вручную — недели.

Что не ускоряется

Здесь важно быть честным, иначе разбор превращается в рекламу.

Решения. Что писать, какой тон, какая цена, стоит ли вообще браться за тему — это по-прежнему человек. Ассистент отлично исполняет и плохо решает.

Вкус. Дизайн, композиция страницы, ощущение «дёшево или дорого выглядит» — не его сильная сторона. Он собирает сетку по правилам, но правила даёт человек.

Ответственность. Сайт боевой, кэш отключён, изменения видны сразу, автоснапшотов нет. Каждая правка — это правка в продакшене. Поэтому порядок неизменный: сначала прочитать текущее состояние, потом писать, потом проверить на живой странице.

Три ловушки, которые стоили времени

Полезнее всего оказались не успехи, а места, где всё выглядело успешным, но не работало.

• Дата уезжает на два часа. Каждое обновление статьи через API сдвигало время создания на два часа назад — система принимала сохранённое значение за местное и переводила его в UTC повторно. Четыре правки подряд увели дату на восемь часов. Лечится передачей времени в местном формате при каждом запросе.
• Ответ «успешно» без результата. Блок микроразметки в теле статьи вырезается фильтром при записи через API. Ответ 200, ошибок нет, разметки нет. Проверять надо не ответ, а поле в базе.
• Кэш прячет правку. Утром на сайте включили кэширование на десять часов. Изменение записалось, страница отдавала старое, и первый вывод был неверным — я решил, что дело в шаблоне. Правильный вывод: «правки не видно» теперь означает кэш, пока не доказано обратное.

Стоит ли повторять это у себя

Честный ответ: зависит от того, сколько у вас однотипной работы.

Если сайт из пяти страниц на одном языке и меняется раз в квартал — не стоит. Настройка займёт больше времени, чем сэкономит.

Связка окупается там, где есть объём и повторяемость: несколько языков, регулярные публикации, каталог, интеграции, регулярные проверки. И там, где кто-то в компании готов формулировать задачи письменно и проверять результат. Без второго условия получится генератор правдоподобного мусора.

Ещё одно наблюдение: почти вся ценность оказалась не в модели, а в обвязке — в доступах, справочниках, предохранителях и накопленной памяти проекта. Модель можно заменить на следующую версию за один вечер. Полтора месяца накопленных знаний о конкретном сайте заменить нельзя.

Коротко

Пять каналов доступа к сайту, потому что одного не хватает. Карта проекта в файлах, потому что модель не помнит вчера. Предохранители на дорогих ошибках, потому что «быть внимательнее» не работает. Проверка на живой странице, а не по ответу сервера. Результат — девятнадцать статей на четырёх языках за день и разбор заражённого сайта за сутки вместо недель.

И то, что не меняется: решает по-прежнему человек, а сайт остаётся боевым, где каждая правка сразу видна клиентам. Если хотите обсудить, применимо ли это к вашему проекту, — напишите нам. Как мы работаем над сайтами вообще, описано на странице Этапы работы.

Виктор Пархимчик, основатель веб-студии IT Deweloper