Optistream об'єднала дванадцять кастомних плагінів WordPress в єдину кодову базу, не втративши SEO для жодної зі своїх тисячі публічних сторінок.

Чому це об'єднання було важливим

Типовий сайт на WordPress зазвичай має кілька плагінів; більший же сайт нагадує майстерню, заплутану дротами, кожен з яких гуде, але жоден неможливо легко від'єднати. Сайт Optistream використовував дванадцять спеціалізованих плагінів, які керували профілями стрімерів, кіберспортивними командами та ігровими даними. Ці плагіни генерували тисячу індексованих сторінок. Збереження цих URL-адрес у незмінному вигляді було критично важливим — будь-яка зміна могла зірвати міграцію.

Як виглядала стара конфігурація

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

  • Хуки (hooks) та активи були розкидані, що ускладнювало передбачення того, який код і коли виконується.
  • Логіка маршрутизації була рознесена по багатьох окремих файлах, тому на одну URL-адресу могли впливати кілька плагінів.
  • CSS-файли завантажувалися в непередбачуваному порядку, що призводило до конфліктів стилів.
  • Для налагодження (debugging) доводилося відкривати дванадцять різних директорій, що було марною тратою часу для будь-якого розробника.

Метою було не зменшення кількості файлів, а надання всій системі єдиного життєвого циклу та єдиного місця для керування залежностями.

Як планувалася міграція

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

1. Перелік публічних контрактів

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

2. Створення простого завантажувача (loader)

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

3. Захист даних

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

4. Вирішення конфліктів CSS

Конфлікти стилів були вирішені за допомогою трьох заходів:

  • CSS-файли модулів додаються в чергу (enqueued) з високим пріоритетом, щоб вони завантажувалися останніми.
  • Усі селектори обмежені (scoped) унікальним класом-обгорткою для кожного модуля.
  • При додаванні в чергу використовується filemtime(), щоб скинути кеш браузера, якщо файл стилів змінився.

5. Використання безпечного циклу

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

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

Після кожної заміни модуля команда перевіряла:

  • Кожна URL-адреса типу контенту повертає HTTP-статус 200.
  • Заголовок canonical URL відповідає оригінальній URL-адресі.
  • Заголовки сторінок та мета-описи залишилися без змін.
  • Усі зображення завантажуються без битих посилань.
  • На мобільних екранах немає горизонтального переповнення (overflow).
  • Консоль браузера не показує помилок JavaScript або CSS.

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

Що дає новий плагін

Єдиний плагін, що утворився, не зменшує обсяг коду; він просто робить межі видимими. Усі дванадцять функціональних областей тепер мають спільний життєвий цикл, один набір хуків та одне місце для керування залежностями. Новий плагін не зробив систему меншою. Він зробив межі видимими. Це виявилося кориснішим, ніж просто мати менше плагінів.

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

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

На що звернути увагу далі

Якщо ви розглядаєте можливість подібної консолідації, почніть із цих двох основ:

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

Після цього створіть крихітний завантажувач, використовуйте scoped CSS і переносьте модулі по одному, суворо дотримуючись чек-листа для продакшну.