Optistream объединила двенадцать кастомных плагинов WordPress в единую кодовую базу, не потеряв SEO-показатели ни одной из своих тысячи публичных страниц.

Почему слияние было важным

Типичный сайт на WordPress обычно содержит несколько плагинов; более крупный же напоминает мастерскую, заваленную проводами, каждый из которых гудит, но ни один не так просто выдернуть из розетки. На сайте Optistream работали двенадцать специализированных плагинов, которые управляли профилями стримеров, киберспортивными командами и игровыми данными. Эти плагины генерировали тысячу индексируемых страниц. Сохранение этих URL в неизменном виде было обязательным условием — любое изменение могло сорвать миграцию.

Как выглядела старая конфигурация

Каждый из двенадцати плагинов жил в своей собственной папке, регистрировал свой собственный тип записи (custom post type) и подключался к WordPress в разных точках. Проблемы накапливались:

  • Хуки (hooks) и ассеты были разбросаны, что мешало предсказать, какой код и когда выполняется.
  • Логика маршрутизации (routing) была разнесена по множеству отдельных файлов, поэтому на один URL могли влиять сразу несколько плагинов.
  • CSS-файлы загружались в непредсказуемом порядке, что приводило к конфликтам стилей.
  • Отладка требовала открытия двенадцати разных директорий, что отнимало массу времени у любого разработчика.

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

Как планировалась миграция

Команда отнеслась к публичному интерфейсу — URL-адресам, шаблонам и метаданным — как к контракту, который нельзя нарушать. Любое изменение на фронтенде считалось бы провалом. Исходя из этого правила, они составили чек-лист, который необходимо было выполнять после каждого шага.

1. Составить список публичных контрактов

Каждый путь URL был записан вместе с его типом записи, rewrite slug, файлом шаблона и мета-ключами, от которых он зависел. Эта таблица стала сводом правил: если после переноса модуля URL менялся, миграция откатывалась.

2. Создать простой загрузчик (loader)

Был создан крошечный bootstrap-файл. Каждый бывший плагин теперь регистрирует единый «content domain» через предсказуемое имя функции. Загрузчик не делает ничего сложного — ровно столько, сколько нужно, чтобы подтянуть нужный модуль в WordPress при необходимости. Простота позволяет легко заметить ошибки.

3. Защитить данные

Переименование мета-ключей превратило бы изменение кода в миграцию данных, что добавило бы ненужного риска. Старые ключи остались нетронутыми; новые вспомогательные функции оборачивают их, сохраняя стабильность схемы базы данных.

4. Исправить управление CSS

Конфликты стилей были решены с помощью трех мер:

  • CSS-файлы модулей ставятся в очередь (enqueue) с высоким приоритетом, чтобы они загружались последними.
  • Все селекторы ограничены уникальным классом-оберткой для каждого модуля.
  • При постановке в очередь используется filemtime(), чтобы сбрасывать кэш браузера при изменении таблицы стилей.

5. Использовать безопасный цикл

Миграция проходила по одному модулю за раз. После переноса модуля команда проверяла регистрацию типа записи, маршрутизацию и мобильную верстку, прежде чем переходить к следующему. Оригинальные плагины оставались установленными, но неактивными, обеспечивая возможность мгновенного отката.

Чек-лист для продакшена

После каждой замены модуля команда проверяла:

  • Каждый URL типа контента возвращает HTTP-статус 200.
  • Заголовок canonical URL соответствует исходному URL.
  • Заголовки страниц (page titles) и мета-описания (meta descriptions) не изменились.
  • Все изображения загружаются без битых ссылок.
  • На мобильных экранах отсутствует горизонтальная прокрутка (overflow).
  • Консоль браузера не показывает ошибок JavaScript или CSS.

Только после успешного прохождения чек-листа команда окончательно деактивировала старый плагин.

Что дает новый плагин

Полученный в итоге единый плагин не уменьшает объем кодовой базы; он просто делает границы видимыми. Все двенадцать функциональных областей теперь имеют единый жизненный цикл, один набор хуков и одно место для управления зависимостями. Новый плагин не сделал систему меньше. Он сделал границы видимыми. Это оказалось полезнее, чем просто уменьшение количества плагинов.

Риски и контраргументы

Кейс Optistream показывает, что дисциплинированный подход «сначала контракт» (contract-first) и поэтапное внедрение позволяют держать риски под контролем.

На что обратить внимание в дальнейшем

Если вы планируете подобную консолидацию, начните с этих двух столпов:

  1. Стабильность URL — сопоставьте каждый публичный путь, прежде чем писать первую строку кода.
  2. Стабильность данных — избегайте переименования полей базы данных, если только вы не готовы к полноценной миграции данных.

После этого создайте крошечный загрузчик, используйте область видимости (scope) для CSS и переносите модули по одному, строго следуя чек-листу для продакшена.