Logistan — новостной портал о логистике (logistan.info)

Контекст и задача

logistan.info — живой русскоязычный новостной портал о логистике Центральной Азии (авиа/ж-д/авто/морские перевозки, экономика, страны региона). Сайт работает на WordPress, тема — дочерняя к twentytwentyfour, архитектура Full Site Editing (FSE / block theme), кэш WP Rocket. На «широких» тегах (Узбекистан, Кыргызстан, Таджикистан) читатели после нажатия «Загрузить ещё» видели повторяющиеся карточки. Задача: найти корневую причину (повреждение БД? баг темы? кэш?) и устранить её, не сломав работающие рубрики, главную и отдельные публикации. Отдельной задачей позже — разобраться в устройстве фронтенда (header и блок «Главное за неделю») и подготовить почву для вёрстки.

Что я сделал

Важно по честности роли: это доработка/диагностика существующего сайта (rework-legacy + audit), а не разработка темы с нуля. Признаков, что автор разрабатывал тему изначально, в артефактах нет; фронтенд-отчёт написан как разведка уже существующей кодовой базы.

Конкретные работы (прослеживаются по снапшотам before/after и отчётам):

Backend-багфикс (report.html, снапшоты 19.04.2026): нашёл и устранил источник дублей в догрузке «Загрузить ещё» на архивных страницах (теги, авторы, архивы по датам). Правки — в functions.php и assets/js/main.js, без изменений БД.
Фронтенд-разведка (report-frontend.html, 24.04.2026): составил карту, где лежит разметка header/footer/sidebar (FSE-части в БД, не в файлах), какие sass-партиалы и строки отвечают за стили, как устроен серверный lazyblock «Главное за неделю», что отсутствует (CSS для .is-style-grid-week) и что требует вёрстки. Подготовил handoff-документ для вёрстальщицы.
Вспомогательная backend-правка (локальная рабочая копия): фильтр render_block, добавляющий класс .burger-btn-wrapper к обёртке мобильной навигации — чтобы можно было стилизовать кнопку бургера (поддержка фронтенд-этапа). Присутствует только в logistan/functions.php, в server-after снапшоте его нет.

Решение и подход

Диагностика велась в три шага, чтобы не «чинить вслепую»:

Проверка БД — SQL-запросом по wp_term_relationships/wp_term_taxonomy искал дублирующие связи «публикация ↔ тег» (результат: 0 строк, база чистая).
Воспроизведение на живых данных — выполнил точно тот же запрос, что шлёт браузер при клике «Загрузить ещё» (admin-ajax.php, query_render_more_pagination), напрямую через curl, в обход кэша и плагинов; сверил первый экран с догрузкой.
Разбор кода — JS, формирующий запрос, и PHP-обработчик ответа.

Корневая причина: функция query_replace_vars() упаковывала в data-attrs блока core/query только categoryName (плюс принудительно inherit=false), а тег/автора/дату не сохраняла; AJAX-фильтр query_loop_block_query_vars фильтровал тоже только по рубрике. На страницах тегов контекст терялся, и сервер отдавал «свежие записи всего сайта» — пересечение с первым экраном и давало дубли. На рубриках всё работало именно потому, что для них поле было предусмотрено.

Фикс: расширил «паспорт» блока и серверный фильтр полями tag/tagId/authorName/year/monthnum/day с безопасной очисткой (sanitize_title, absint, wp_unslash); зеркально дополнил main.js, чтобы запрос передавал эти поля. Деплой выполнен с бэкапами (файлы + дамп БД ~140 МБ), проверкой синтаксиса php -l, сбросом кэша WP Rocket и приёмочными тестами.

Результат

По данным отчёта (report.html), с приёмочной проверкой каждого кейса повтором AJAX-запроса:

/tag/uzbekistan/, /tag/kyrgyzstan/, /tag/tadzhikistan/ — догрузка 12/12 постов по тегу, 0 дублей с первым экраном.
Рубрики «Авиаперевозки» и «Железные дороги», главная и отдельная публикация — работают как раньше, ничего не сломано.
На примере тега «Узбекистан»: было 3 релевантных поста из 12 догруженных, стало 12 из 12.
БД не изменялась; «чистки дублей в базе» не требовалось и не выполнялось.

Долгосрочный SEO/поведенческий эффект в отчёте обозначен как наблюдение «на будущее», но не измерен (уточнить).

Стек и обоснование

WordPress, FSE / block theme (дочерняя к twentytwentyfour). Контент-разметка — на блоках core/query + core/post-template; кастомные блоки через LazyBlocks (15+ серверных lazyblock-ов, в каталоге 16 папок lazyblock-*), плюс GhostKit (подключён в workspace, утилит-классы ghostkit-*). Свой blocks/loader.php автоматически подхватывает block.css/block.js каждой папки с cache-busting по filemtime(). Стили — SASS (партиалы), компиляция Prepros → assets/css/main.css. Догрузка — jQuery AJAX через admin-ajax.php. Кэш — WP Rocket (в коде темы — универсальный сброс кэша для WP Rocket/W3TC/LiteSpeed/WP Engine/SiteGround; этот участок пред-существовал, не авторская правка). Безопасность входных параметров — штатные функции WordPress (sanitize_title/absint/wp_unslash), как наименее инвазивный и стандартный путь.

Роль ИИ в проекте

Прямых артефактов работы с ИИ в проекте не обнаружено: нет CLAUDE.md, AGENTS.md, GEMINI.md, каталогов .claude//.opencode/, prompt-файлов, нет git-истории. Структурированные, аккуратно оформленные HTML-отчёты и методология «исследование → воспроизведение → аудит → правка → верификация» согласуются с AI-augmented-подходом, однако это не подтверждено артефактами и не заявляется как факт. Какие именно ИИ-инструменты использовались (если использовались) — вопрос к автору.

Инженерные вызовы

FSE-специфика: разметка header/footer/sidebar и вставки блоков хранятся в БД, а не в файлах темы; пришлось рассуждать о сериализации атрибутов core/query в data-attrs, а не искать привычные шаблоны.
Разграничение причин: методичное исключение версий (повреждение БД vs баг кода vs кэш) с воспроизводимой проверкой, а не «посмотрел глазами».
Безопасная правка: починить контекст тега/автора/даты, не сломав работавшую ветку рубрик; добавить валидацию входных параметров.
Работа с незнакомой кодовой базой: во фронтенд-разведке выявил отсутствие CSS для зарегистрированного стиля .is-style-grid-week и латентный баг — разные aspect-ratio у <figure> для текущей и fallback-недели в lazyblock-glavnoe-za-nedelyu/block.php.