WooCommerce HPOS на VPS: проверка плагинов и перенос таблиц заказов

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

Эта статья про то, как проверить переход на HPOS именно на вашем магазине, не трогая рабочие заказы. Мы не будем обещать ускорение: оно зависит от состава расширений, объёма данных и версии WooCommerce. Мы будем строить репетицию, в которой видно, что сломается, а что нет, и по каким признакам вы решите переключаться или подождать.

Начинаем не с настроек, а с карты операций

Обычно проверку HPOS начинают с флажка в настройках WooCommerce. Разумнее начать с листа бумаги и выписать, что происходит с заказом от появления до архива. Не «какие у нас плагины», а «какие действия с заказом они выполняют». Разница существенная: плагин может быть установлен, но не касаться заказов, а мелкий сниппет в functions.php может делать запросы напрямую к таблицам записей.

Составьте таблицу в таком виде:

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

Что на самом деле меняет HPOS

Согласно документации WooCommerce о HPOS, эта функция использует отдельное хранение заказов вместо прежнего, где заказы лежали как записи WordPress. Для понимания риска достаточно такой картины: раньше заказ был одним из видов поста, и любой код, умеющий работать с постами, мог его найти, прочитать и изменить. Теперь у заказов своя структура данных, и код, который лезет «по-старому» напрямую в таблицы записей, перестаёт видеть то, что видит магазин.

Отсюда вытекает практический вывод, который не зависит от процентов ускорения. Расширение, использующее штатные методы WooCommerce для работы с заказом, переживает смену хранилища спокойно: слой доступа делает свою работу. Расширение или доработка, обращающиеся к заказу как к посту, могут вести себя неверно: не найти заказ, не сохранить мета-поле, показать пустой отчёт. И проблема эта не шумная. Падение с ошибкой заметно сразу, а тихо неполный отчёт можно не замечать неделями.

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

Совместимость: чья это ответственность

В документации сказано, что совместимость расширений проверяется отдельно, а интерфейс WooCommerce показывает те, что несовместимы. Там же указано, что поддержку HPOS в стороннем расширении обеспечивает разработчик этого расширения. Это важная деталь распределения ответственности: WooCommerce даёт механизм и сообщает о проблемах, но сделать плагин доставки совместимым может только его автор.

Что из этого следует на практике:

• Список несовместимых расширений в админке — отправная точка, а не приговор. Он показывает, что объявлено разработчиками, а не то, как плагин поведёт себя в вашей конфигурации.
• Отметка о совместимости не заменяет теста. Плагин может честно поддерживать HPOS и всё равно конфликтовать с вашей самописной доработкой, которая добавляет поля или меняет статусы.
• Для несовместимого плагина есть три пути: написать разработчику и узнать планы, найти замену или отложить переход. Какой выбрать, зависит от того, насколько плагин критичен. Платёжный модуль без поддержки — повод остановиться. Декоративный виджет статистики — повод подумать о замене.

Отдельно пройдитесь по собственному коду: темы, дочерние темы, mu-плагины, сниппеты. Поиск по коду на обращения к заказам как к записям (запросы по типу записи заказа, прямые SQL к таблицам постов и их мета-таблицам) покажет места, которые придётся переписать на методы WooCommerce. Это работа разработчика, и лучше оценить её объём до переключения.

Почему репетиция идёт на копии, и при чём тут VPS

Тестировать на рабочем магазине нельзя по очевидной причине: переключение хранилища затрагивает живые заказы. Тестировать на локальном компьютере можно, но часто неудобно. Данных там нет, окружение отличается от боевого, а показать результат коллеге-менеджеру сложно. Промежуточный вариант — отдельный VPS с копией магазина, максимально похожей на рабочую среду: те же версии PHP и MySQL или MariaDB, тот же веб-сервер, те же плагины и тема.

У VPS MAATRIX для этой роли есть подходящие свойства: root-доступ, NVMe-диски и процессоры AMD EPYC, а сервер создаётся автоматически через пару минут после оплаты. Оплатить можно картой РФ или через СБП. Для репетиции это значит, что стенд можно поднять на время проверки и не держать его годами. Локации в публичном предложении: UK, US, RU и FR; для тестовой копии с реальными данными клиентов выбирайте ту, которая соответствует вашим требованиям к размещению персональных данных, и решайте это заранее, а не после копирования.

По ресурсам: тарифы идут от Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) до Djed (16 vCPU, 32 ГБ, 320 ГБ), и между ними Uab, Heka и Maat. Это характеристики конфигураций, а не обещание ёмкости. Практический ориентир для стенда таков: диск должен вместить копию файлов и базы с запасом под дампы и журналы, а память и процессор — выдержать фоновый перенос заказов, не мешая вам одновременно кликать в админке. Для небольшого магазина с умеренной историей заказов начальной конфигурации может хватить, для магазина с большим архивом разумно взять ступенью выше. Подтвердит или опровергнет это только замер на самом стенде.

Если вы ещё не разворачивали WooCommerce на сервере, базовую установку и настройку удобно сверить по статье «WooCommerce: установка и настройка», чтобы стенд не отличался от рабочей среды по базовым параметрам.

Копия, которая похожа на настоящий магазин

Идеальная тестовая копия — не просто дамп базы. Она должна содержать то разнообразие заказов, которое есть в магазине, иначе репетиция проверит только «средний» заказ, а проблемы живут в нестандартных.

Перенесите на стенд файлы сайта и базу данных. Затем сделайте три защитных шага, которые относятся к копии с реальными данными:

1. Отключите отправку писем клиентам или перенаправьте их в тестовый ящик, иначе копия может написать покупателям о заказах, которые они уже получили.
2. Переведите платёжные модули и интеграции доставки в тестовый режим или отключите их боевые ключи. Копия не должна создавать реальные отправления и списывать деньги.
3. Закройте стенд от поисковых систем и посторонних: доступ по паролю или по списку адресов. Там лежат данные покупателей.

Затем проверьте, что среди заказов копии есть все типы, которые встречаются у вас. Подберите конкретные заказы и запишите их номера, чтобы потом сравнивать «до» и «после» на тех же примерах:

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

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

Зафиксируйте «как было», пока ничего не изменилось

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

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

Включаем HPOS на стенде: перенос и синхронизация

Дальше действуем в рамках процедуры, которую предлагает сам WooCommerce. В настройках магазина, в разделе дополнительных параметров, находятся настройки хранения данных заказов. Там вы увидите, какое хранилище активно, и, как отмечено в документации, интерфейс сообщит о несовместимых расширениях. Если список непустой, остановитесь и вернитесь к вопросу совместимости, а не переключайте «на посмотреть».

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

Порядок для стенда:

1. Убедитесь, что WooCommerce обновлён до актуальной версии, а список несовместимых расширений пуст или вы осознанно оставили в нём то, что на копии можно отключить.
2. Включите режим совместимости, чтобы данные заказов поддерживались в обоих хранилищах.
3. Запустите перенос данных средствами WooCommerce и дождитесь, пока синхронизация завершится. На большой базе это занимает заметное время, и именно здесь полезно засечь его: полученная цифра пригодится при планировании окна работ на рабочем магазине.
4. Только после завершённой синхронизации выберите новое хранилище основным.
5. Сравните число заказов в обоих хранилищах и просмотрите журналы на ошибки.

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

Теперь главное: проверяем операции, а не размеры таблиц

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

Сделайте на стенде сквозной прогон одного нового тестового заказа:

1. Оформите заказ как покупатель, включая заполнение дополнительных полей. Проверьте, что поля сохранились и видны в админке.
2. Имитируйте оплату тестовым способом платёжного модуля. Убедитесь, что статус сменился, а запись о платеже на месте.
3. Переведите заказ в статус отправки. Проверьте, что плагин доставки отработал в тестовом режиме и трек появился там, где должен.
4. Создайте частичный возврат. Проверьте сумму, состав и остатки на складе.
5. Выгрузите заказ в тот экспорт, который идёт в бухгалтерию или CRM, и сравните с эталоном.
6. Пересоберите отчёт за тот же период, что сохраняли ранее.

Затем пройдите по набору старых заказов, номера которых вы записали, и сравните значения с эталоном. Особое внимание — на старый заказ и заказ с возвратом: именно они чаще всего выявляют нюансы миграции данных. Отдельно проверьте поиск и фильтры в списке заказов, массовые действия и печать накладных, если вы ими пользуетесь: менеджеры работают именно через них.

Если что-то не совпало, не спешите винить HPOS. Разберитесь в причине: плагин не поддерживает новое хранилище, кастомный код обращается к заказу как к записи, или сработала гонка при синхронизации. От причины зависит решение: обновить плагин, написать разработчику, переписать фрагмент или отложить переключение.

Что делать с результатами: критерии решения

Чтобы решение не превратилось в «вроде нормально», запишите критерии заранее, до прогона. Вот пример, как они могут выглядеть. Пример условный, ваши пороги определит ваш бизнес:

Заметьте: в таблице нет строки «стало быстрее — переключаем». Скорость — приятный побочный эффект, который вы измерите, но не основание для решения. Основание — корректность операций и предсказуемость процедуры.

Переход на рабочем магазине: то же самое, но с поправкой на деньги

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

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

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

Менеджер открывает два заказа

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

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