Як мы падключылі Claude да баявой Joomla

Чым гэта не з'яўляецца

Пачнём з таго, чаго ў гэтай гісторыі няма, — інакш лёгка вырашыць, што гаворка пра чарговы плагін з кнопкай «згенераваць тэкст».

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

Пяць каналаў доступу, і навошта іх столькі

Першае адкрыццё: аднаго спосабу дастукацца да сайта не хапае. Кожны наступны канал з'яўляўся тады, калі папярэдні ўпіраўся ў сцяну.

• Канектар MCP. Праслойка паміж асістэнтам і штатным API Joomla: каля дзвюхсот пяцідзесяці аперацый — артыкулы, катэгорыі, меню, модулі, тэгі, медыяфайлы. Асноўны працоўны канал.
• Штатнае API напрамую. Калі канектар чагосьці не ўмее. Напрыклад, метатэгі пункта меню ляжаць унутры поля параметраў, і запісаць іх можна толькі прамым запытам.
• База дадзеных. Чытанне — стала, кропкавы запіс — рэдка і асэнсавана. Ёсць рэчы, якія API моўчкі адфільтроўвае: блок мікраразметкі ў целе артыкула ён выразае і адказвае «паспяхова».
• Файлавая сістэма хостынгу. Змантаваная як сеткавы дыск. Шаблон, robots.txt, логі сервера, зыходнікі плагінаў. Менавіта чытанне зыходнага кода Joomla некалькі разоў давала адказ хутчэй, чым пошук у дакументацыі.
• Сапраўдны браўзер з адкрытай адмінкай. Для таго, чаго ў API няма наогул. Сёння гэта спатрэбілася двойчы: скінуць кэш і перазахаваць налады кампанента, без чаго параметр, запісаны проста ў базу, не ўжываўся.

Чаму аднаго канала мала — канкрэтны выпадак

Сённяшняя задача: прыбраць лічбавы ідэнтыфікатар з адрасоў артыкулаў, каб замест /be/blog/96-japanese-keyword-hack адкрывалася /be/blog/japanese-keyword-hack.

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

Тры каналы, каб перамкнуць адзін пераключальнік. Затое цяпер гэта запісана ў памяць праекта, і наступным разам задача зойме хвіліну.

Памяць — тое, без чаго ўсё гэта бескарысна на другі дзень

Моўная мадэль не памятае ўчарашні дзень. Калі кожную сесію пачынаць з нуля, асістэнт будзе нанова высвятляць, які ў артыкула ідэнтыфікатар, дзе ляжыць шаблон і чаму нельга захоўваць стыль без спіса старонак. На трэці раз гэта перастае акупляцца.

Таму веды пра праект захоўваюцца ў файлах побач з асістэнтам:

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

Гэта і ёсць галоўная каштоўнасць, якая назапашваецца. Мадэль замяняльная, а карта праекта — не.

Засцерагальнікі: гісторыя пра сорак шэсць прывязак

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

Прычына аказалася ва ўладкаванні Joomla: спіс прывязаных старонак — частка формы стылю, і пры захаванні сістэма спачатку абнуляе прывязкі, а потым расстаўляе іх нанова паводле таго, што прыйшло ў запыце. Не даслаў спіс — прывязкі зніклі.

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

Як выглядае працоўны дзень

Сённяшні, без упрыгожванняў. Раніцай камп'ютар уключыўся пасля аварыйнага выключэння напярэдадні, і ўсе ўчарашнія сесіі аказаліся мёртвымі. Аднаўленне кантэксту заняло каля дзесяці хвілін: па журналах стала зразумела, што адбылося, а няскончаная праца знайшлася ў файлах.

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

Праверка выніку — не «адказ сервера 200», а жывая старонка і валідатар разметкі. Па ўсіх шаснаццаці артыкулах: нуль памылак, нуль папярэджанняў.

Што сапраўды паскараецца

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

Што не паскараецца

Тут важна быць сумленным, інакш разбор ператвараецца ў рэкламу.

Рашэнні. Што пісаць, які тон, якая цана, ці варта наогул брацца за тэму — гэта па-ранейшаму чалавек. Асістэнт выдатна выконвае і дрэнна вырашае.

Густ. Дызайн, кампазіцыя старонкі, адчуванне «танна ці дорага выглядае» — не яго моцны бок. Ён збірае сетку па правілах, але правілы дае чалавек.

Адказнасць. Сайт баявы, змены відаць адразу, аўтаматычных здымкаў няма. Кожная праўка — гэта праўка ў прадакшэне. Таму парадак нязменны: спачатку прачытаць бягучы стан, потым пісаць, потым праверыць на жывой старонцы.

Тры пасткі, якія каштавалі часу

Карысней за ўсё аказаліся не поспехі, а месцы, дзе ўсё выглядала паспяховым, але не працавала.

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

Ці варта паўтараць гэта ў сябе

Сумленны адказ: залежыць ад таго, колькі ў вас аднатыпнай працы.

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

Звязка акупляецца там, дзе ёсць аб'ём і паўтаральнасць: некалькі моў, рэгулярныя публікацыі, каталог, інтэграцыі, рэгулярныя праверкі. І там, дзе нехта ў кампаніі гатовы фармуляваць задачы пісьмова і правяраць вынік. Без другой умовы атрымаецца генератар праўдападобнага смецця.

Яшчэ адно назіранне: амаль уся каштоўнасць аказалася не ў мадэлі, а ў абвязцы — у доступах, даведніках, засцерагальніках і назапашанай памяці праекта. Мадэль можна замяніць на наступную версію за адзін вечар. Паўтара месяца назапашаных ведаў пра канкрэтны сайт замяніць нельга.

Коратка

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

І тое, што не мяняецца: вырашае па-ранейшаму чалавек, а сайт застаецца баявым, дзе кожная праўка адразу відаць кліентам. Калі хочаце абмеркаваць, ці дастасавальна гэта да вашага праекта, — напішыце нам. Як мы працуем над сайтамі наогул, апісана на старонцы Этапы працы.

Victor Parhimchik, заснавальнік вэб-студыі IT Deweloper