Перенос магазина на HPOS начинается с полной инвентаризации всех установленных плагинов, так как стандартный WooCommerce не поддерживает их функционал нативно. Необходимо проверить каждое расширение на совместимость или найти альтернативы.
Инвентаризация и проверка сторонних расширений перед миграцией на HPOS
Перенос магазина на архитектуру HPOS (Head of Point of Sale) начинается не с настройки сервера, а с детального аудита установленных плагинов. Стандартный WooCommerce хранит данные заказов в одной таблице `wp_posts` и использует кастомные таблицы для расширений. Новая система HPOS разделяет эти данные на несколько таблиц (`wc_orders`, `wc_order_items` и другие), что меняет структуру запросов. Большинство старых плагинов, особенно те, которые добавляют поля к заказу или управляют инвентарем, не работают с новой структурой без доработки. Ваша задача — выявить такие плагины до начала миграции.
Процесс проверки строится по принципу функционального анализа, а не просто перечисления названий. Для каждого активного модуля ответьте на три вопроса: что именно он делает для бизнеса, какие данные он хранит и как эти данные используются в других системах. Если плагин решает задачу через создание кастомных таблиц или хуки на старые типы заказов, его необходимо либо заменить на нативный аналог из экосистемы HPOS, либо перенести логику на использование новых API-методов. Пример: если вы используете плагин для управления статусами доставки, который пишет данные в `wp_posts`, он потребует замены на решение, работающее с таблицами `wc_order_status_transitions`.
Критически важно проверить плагины интеграции с платежными системами и логистическими сервисами. Эти модули часто зависят от конкретных полей заказа (например, `total`, `status`, `customer_id`). При переходе на HPOS структура этих полей меняется, что может привести к тому, что платежный шлюз перестанет принимать данные или сформирует ошибочный запрос. Тестируйте такие интеграции в песочной среде: создайте тестовый заказ через плагин и проверьте, корректно ли он попадает в новую таблицу заказов и отправляет ли события внешнему сервису.
Перед началом любых изменений обязательно создайте полную резервную копию базы данных и файлов. Это стандартная практика безопасности, но при миграции на HPOS она становится критической. Если вы обнаружите несовместимость ключевого плагина во время тестирования, наличие полной копии позволит откатить изменения за минуты, а не дни. Копия должна включать не только файлы WordPress, но и дампы всех таблиц базы данных, включая пользовательские таблицы, созданные расширениями.
План действий по инвентаризации выглядит так: сначала экспортируйте список всех установленных плагинов и их версий. Затем для каждого модуля проверьте наличие официальных обновлений или заявлений разработчиков о поддержке HPOS. Если официального решения нет, изучите документацию плагина на предмет совместимости с новой архитектурой заказов. Для плагинов без поддержки найдите альтернативы в репозитории WooCommerce, которые уже адаптированы под HPOS, или рассмотрите возможность реализации требуемой функции через нативные возможности ядра WordPress и WooCommerce.
Ограничением процесса является невозможность одновременной работы старой и новой системы заказов без промежуточного слоя. Это значит, что миграцию нужно проводить поэтапно: сначала переносите функционал плагинов на новые модули или кастомный код, работающий с HPOS, затем проверяете стабильность, и только после этого отключаете старые плагины. Попытка запустить магазин с активными старыми расширениями и новой базой данных приведет к ошибкам в отображении заказов и потере данных.
После замены или настройки совместимости каждого плагина проведите проверку истории заказов. В админ-панели HPOS данные о статусе заказа хранятся иначе, чем в старой модели. Убедитесь, что все исторические заказы корректно отображаются, а фильтры по статусам и типам работают без ошибок. Если вы используете плагины для отчетности или аналитики, проверьте, корректно ли они агрегируют данные из новых таблиц заказов.
Успешный переход зависит от качества документации по настройке каждого модуля. Запишите свои действия и конфигурации для каждого плагина: какие параметры были изменены, какие альтернативы использованы. Наличие такого плана действий позволит быстро восстановить работоспособность магазина в случае возникновения несовместимости с конкретными модулями после запуска новой системы.
Анализ функционала сторонних расширений и выбор стратегии миграции
Перенос магазина на HPOS (Head of Point of Sale) невозможен без детального изучения каждого активного плагина. Стандартная архитектура WooCommerce опирается на кастомные таблицы для хранения данных заказов, тогда как HPOS использует нативную модель `wp_posts` с типом записи `shop_order`. Если расширение работает через кастомные таблицы, оно не будет корректно отображать историю заказов или статусы в новой системе. В таких случаях есть два пути: перенести логику работы плагина на нативные возможности HPOS (через кастомные поля и фильтры) или заменить модуль на готовый аналог, поддерживающий новую архитектуру.
Начните инвентаризацию с группировки плагинов по типу их влияния. Выделите инструменты, работающие напрямую с данными заказа: расчет доставки, налоги, управление складом (инвентаризация), интеграции с CRM и платежными шлюзами. Эти модули критичны, так как они формируют структуру данных транзакции. Остальные плагины (например, для оформления заказа на странице или визуальные элементы) часто можно отключить или заменить на более легкие решения, не требующие глубокой интеграции с базой данных заказов.
Для каждого плагина из критической группы выполните анализ его функционала. Задайте вопрос: «Как именно этот модуль меняет данные заказа?». Если ответ — «добавляет колонки в кастомную таблицу» или «создает записи в отдельной БД», то миграция требует пересборки логики. Например, плагин для расчета доставки, который считал стоимость на основе весов из старой таблицы, нужно переписать так, чтобы он брал данные из полей `post_meta` нового формата заказа. Это часто требует участия разработчика для создания кастомных функций или поиска альтернативы с поддержкой HPOS.
При выборе альтернативы избегайте слепого копирования списка плагинов конкурентов. Проверьте документацию каждого кандидата на совместимость с версией WooCommerce, поддерживающей HPOS (обычно 8.0+). Условный пример: если вы используете плагин для управления возвратами, который не поддерживает нативные заказы, найдите решение, которое работает через стандартные статусы `wc-order-status`. Если готового модуля нет, рассмотрите возможность написания простого кастомного решения на основе фильтров `woocommerce_order_status_transition`, что часто дешевле и надежнее, чем поиск редкого плагина.
Не забывайте о плагинах безопасности и аналитики. Некоторые из них могут сканировать структуру таблиц базы данных и выдавать предупреждения при переходе на HPOS. Проверьте их настройки: возможно, потребуется обновить правила сканирования или отключить мониторинг кастомных таблиц, которые больше не существуют в новой системе. Это предотвратит ложные срабатывания систем защиты и обеспечит корректную работу аналитических отчетов.
Документируйте найденные альтернативы и планы переписывания логики для каждого плагина. Запишите, какой функционал вы планируете сохранить, как именно он будет реализован в HPOS и какие риски это несет. Если плагин решает уникальную бизнес-задачу, которую нет в стандартных модулях, подготовьте план разработки кастомного решения или поиска специалиста для адаптации существующего кода. Это позволит избежать ситуации, когда после миграции часть функционала магазина перестанет работать, а вы не сможете быстро восстановить процессы продаж.
Тестирование интеграций с платежными системами и логистическими сервисами
Перенос магазина на HPOS меняет внутреннюю структуру данных заказа. Платежные шлюзы и службы доставки часто работают не напрямую с базой данных, а через API, которое ожидает стандартные поля старой модели WooCommerce. Если интеграция опирается на кастомные таблицы или специфические метаданные, которые исчезают при миграции, платеж может не пройти, а статус заказа в админ-панели станет неверным.
Критическим моментом является проверка того, как новая система формирует объект заказа для внешнего сервиса. Многие платежные системы (например, ЮKassa, Тинькофф Касса) и логистические агрегаторы (CDEK, Почта России) требуют строгого соответствия полей: ID заказа, суммы, адреса, список товаров. В HPOS эти данные хранятся иначе, поэтому необходимо убедиться, что ваш плагин-обертка или кастомный код корректно собирает и передает их в том формате, который ожидает сторонний сервис.
Начните тестирование с малого: выберите один тип платежа (например, банковская карта) и одну службу доставки. Создайте условный заказ в новой системе HPOS, но не оплачивайте его реальными деньгами. Вместо этого используйте песочницу платежного шлюза или симуляцию оплаты через API-тестовый ключ. Проверьте, корректно ли формируется запрос к внешнему сервису и приходит ли ответ с подтверждением статуса.
Особое внимание уделите логистике. При переносе на HPOS часто меняются способы расчета стоимости доставки или правила отмены заказа. Убедитесь, что интеграция с курьерскими службами корректно обрабатывает изменения в статусе заказа (например, переход из статуса «Ожидает оплаты» в «Оплачен»). Если сервис зависел от старых полей для расчета тарифа, вам придется обновить конфигурацию или написать новый обработчик событий.
Используйте инструменты логирования для отслеживания ошибок. Если платежный шлюз вернет ошибку, проверьте не только сообщение об ошибке, но и структуру данных, которые вы передали в запросе. Часто проблема кроется в том, что поле «ID заказа» теперь имеет префикс или другое форматирование, которое старый код интеграции не учитывает.
Если тесты показывают сбои, не пытайтесь исправить их «на лету» в продакшене. Вернитесь к плану миграции и определите, какой именно слой абстракции нарушает работу. Возможно, потребуется обновить плагин-обертку или переписать часть логики сбора данных. Зафиксируйте все изменения в документации, чтобы при необходимости можно было быстро откатиться или объяснить команде причины задержек.
Помните, что некоторые сервисы могут требовать повторной авторизации после смены структуры базы данных. Проверьте, не истекают ли токены доступа и не требует ли платежный шлюз пересогласования условий работы. Это частая причина сбоев сразу после миграции.
Завершите этап тестирования проверкой сценариев возврата средств и отмены заказов. В HPOS процесс аннулирования заказа может отличаться, и если интеграция не учитывает новые статусы, деньги могут быть списаны ошибочно или курьер получит неверную инструкцию.
Создание резервной копии перед миграцией на HPOS
Перед началом любых изменений в базе данных и файлах магазина критически важно создать полную резервную копию. Это не просто формальность, а страховка от потери данных при возникновении ошибок во время переноса функционала или конфликтов плагинов. В контексте перехода на HPOS (Head of Point of Sale) риски возрастают из-за смены внутренней структуры таблиц заказов и инвентаризации расширений.
Резервное копирование должно включать два компонента: файловую систему и базу данных. Файлы содержат темы, плагины, изображения товаров и настройки конфигурации. База данных хранит историю заказов, клиентов, остатки на складах и логику работы кастомных таблиц старых расширений. Если вы используете хостинг с панелью управления (например, cPanel), используйте встроенные инструменты для создания архива всего сайта или отдельных папок wp-content и базы данных.
Для более сложных сред или частых бэкапов целесообразно настроить автоматическое резервное копирование через скрипты или плагины. Важно убедиться, что копии хранятся в отдельном месте, не зависящем от основного сервера (например, на другом диске, в облачном хранилище или у провайдера). Это позволит восстановить данные даже в случае полной поломки текущего сервера или удаления файлов администратором.
Процесс создания копии занимает время, пропорциональное размеру магазина. Не пытайтесь делать это во время пиковой нагрузки на сайт, когда пользователи активно совершают покупки. Лучше запланировать процедуру на период низкой активности или техническое окно. После завершения копирования обязательно проверьте целостность архива: попробуйте восстановить его в тестовом окружении или просто откройте файл архива, чтобы убедиться, что он не поврежден.
Если вы планируете поэтапный перенос функционала, создавайте отдельные копии перед каждым значимым шагом. Например, после инвентаризации плагинов сделайте одну копию, затем после настройки HPOS — другую. Это позволит откатиться к состоянию «до миграции» или «после настройки ядра», но до начала проблем с конкретными модулями. Документируйте время создания каждой копии и её содержимое, чтобы в случае инцидента можно было быстро определить, какая версия данных актуальна.
Важно помнить, что резервная копия — это статичный снимок состояния системы на момент её создания. Данные, появившиеся после этого момента (новые заказы, изменения остатков), не будут включены в архив. Поэтому для критически важных операций рекомендуется делать дополнительные копии непосредственно перед запуском процесса миграции. Если вы работаете с несколькими магазинами или тестовыми окружениями, синхронизируйте их состояние перед созданием бэкапа, чтобы избежать расхождений между средой разработки и продакшеном.
План переноса на HPOS: этапы и реализация
Переход на архитектуру HPOS (Headless Point of Sale) — это не просто смена плагинов, а фундаментальное изменение способа хранения и обработки данных заказов. Стандартный WooCommerce использует одну таблицу `wp_posts` для всех типов записей, тогда как HPOS разделяет данные по типам: заказы, товары, детали заказа, адреса доставки и т.д. Это требует строгой последовательности действий, чтобы избежать потери информации или блокировки функционала.
Первым этапом является аудит плагинов. Необходимо пройтись по списку всех активных расширений и оценить их зависимость от старой структуры данных. Если плагин работает через кастомные таблицы в базе данных `wp_posts`, он не будет корректно функционировать на HPOS без доработки или замены. Задача — найти нативные аналоги в экосистеме WooCommerce или подготовить кастомный код для миграции логики работы таких модулей.
Второй этап — настройка самой архитектуры HPOS. Это включает установку соответствующих плагинов-оболочек, которые обеспечивают совместимость с текущим сайтом и постепенно переключают запись данных в новые таблицы. Важно не отключать старый механизм записи сразу, а настроить плавный переход, чтобы старые заказы продолжали формироваться по старой схеме, пока новые не перейдут на новую структуру.
Третий этап — поэтапный перенос функционала. Нельзя менять всё сразу. Рекомендуется начать с малого: например, активировать HPOS для новых заказов, а существующие оставить в старой модели. По мере накопления опыта и подтверждения стабильности новой системы можно постепенно переключать старые заказы или запускать полный переход. Параллельно нужно переносить бизнес-логику из плагинов в нативные возможности платформы или кастомные решения.
Четвертый этап — тестирование сценариев продаж. Необходимо смоделировать реальные ситуации: оформление заказа, изменение статуса, отмена, возврат, применение скидок, работа с несколькими адресами доставки и оплаты. Проверьте корректность отображения истории заказов в админ-панели, так как HPOS меняет способ хранения данных о статусе. Убедитесь, что интеграции с платежными системами и логистическими сервисами продолжают работать без ошибок.
Пятый этап — обучение персонала. Новый интерфейс админ-панели может отличаться от привычного. Покажите сотрудникам, как создавать заказы, управлять остатками и обрабатывать возвраты в новой системе. Подготовьте инструкции по работе с новыми разделами управления заказами и деталями заказов. Это снизит риски ошибок при переходе на новую систему.
Важно учитывать ограничение: одновременная работа старой и новой системы заказов возможна только через промежуточный слой (middleware). Без него нельзя просто «переключить тумблер». Требуется тщательное планирование времени миграции, чтобы минимизировать простои. Если вы работаете с несколькими магазинами или тестовыми окружениями, синхронизируйте их состояние перед созданием бэкапа, чтобы избежать расхождений между средой разработки и продакшеном.
После завершения миграции обязательна финальная проверка корректности отображения истории заказов в админ-панели. HPOS меняет способ хранения данных о статусе заказа, поэтому старые заказы могут отображаться иначе. Убедитесь, что все отчеты, аналитика и интеграции с CRM работают корректно. Если обнаружены критические ошибки, используйте резервную копию для отката изменений.
Успешный переход зависит от качества документации по настройке плагинов и наличия плана действий при возникновении несовместимости с конкретными модулями. Подготовьте список контактов разработчиков или вендоров плагинов, которые могут помочь в случае проблем. Регулярно обновляйте систему и следите за обновлениями плагинов, чтобы избежать уязвимостей и ошибок совместимости.
Ограничения миграции: невозможность параллельной работы систем
Стандартная архитектура WooCommerce не позволяет одновременно использовать старую модель заказов (Legacy Order) и новую систему HPOS. Это фундаментальное ограничение, а не техническая сложность, которую можно обойти простым обновлением плагинов. Если попытаться запустить миграцию без промежуточного слоя, система столкнется с конфликтом баз данных: новые данные будут записываться в таблицы `wp_wc_*`, а старые запросы — в `wp_posts` и связанных таблицах заказов. Это приведет к рассинхронизации инвентаря, статусов платежей и истории транзакций.
Из-за этого ограничения миграция должна проводиться строго по времени: либо на моменте остановки приема новых заказов (полная остановка магазина), либо с использованием специализированного middleware. Middleware выступает в роли адаптера, который принимает заказы в старой модели, конвертирует их в формат HPOS и сохраняет в новой базе, но при этом блокирует возможность создания новых заказов напрямую в старой системе. Это создает узкое место: все бизнес-процессы (прием заявок, обработка платежей) должны проходить через этот слой, что увеличивает время отклика системы.
Планирование времени миграции требует учета пиковых нагрузок и логистических циклов. Нельзя переносить систему в момент высокой активности продаж или во время проведения акций с распродажами. Рекомендуется выбирать период низкой нагрузки (например, ночью или в выходные дни), чтобы минимизировать простои. Перед началом работ необходимо уведомить клиентов о временном ограничении функционала, если используется схема полной остановки.
При использовании middleware критически важно настроить правила конвертации данных заранее. Не все поля старой модели имеют прямые аналоги в HPOS, и некоторые кастомные данные могут быть потеряны при автоматическом переносе. Необходимо проверить, как будут обрабатываться статусы заказов, если они не поддерживаются новой системой по умолчанию. Также стоит предусмотреть сценарий отката: если middleware сломается или возникнет критическая ошибка конвертации, магазин должен быстро вернуться на работу в старой модели, что возможно только при наличии полной резервной копии и возможности быстрого переключения базы данных.
Оценка рисков невозможности параллельной работы включает анализ зависимости от сторонних сервисов. Платежные шлюзы, службы доставки и CRM часто опираются на структуру таблиц заказов. При переходе на HPOS эти интеграции могут перестать работать корректно, если они не обновлены разработчиками для новой архитектуры. В этом случае потребуется временное отключение внешних сервисов или использование их API в режиме ожидания, пока миграция завершится.
Для минимизации простоев рекомендуется проводить тестовую миграцию на копии базы данных с сохранением активной работы магазина через middleware. Это позволит оценить реальное время конвертации заказов и выявить потенциальные сбои в работе интеграций. Если бизнес-процессы не позволяют остановить магазин даже на несколько часов, необходимо рассмотреть вариант поэтапного переноса функционала: сначала мигрируются каталог и корзина, затем заказы, а платежи подключаются последними.
Итоговый план миграции должен содержать четкий тайминг: когда отключается старый модуль заказов, когда запускается middleware, когда происходит финальная конвертация данных и когда полностью останавливается старая система. Любое отклонение от этого плана может привести к потере данных или сбою в работе магазина. Поэтому важно согласовать график работ с командой поддержки, разработчиками плагинов и поставщиками внешних сервисов заранее.
Проверка корректности отображения истории заказов после миграции на HPOS
После завершения процесса миграции данных критически важно проверить, как административная панель отображает историю заказов. В архитектуре HPOS структура хранения информации о статусе заказа фундаментально отличается от классической модели WooCommerce: данные разнесены по множеству таблиц (orders, order_items, order_meta и др.), а не хранятся в одной большой таблице с JSON-метаданными. Из-за этого стандартные плагины для просмотра истории заказов могут показывать устаревшие статусы или пропускать этапы обработки.
Первым шагом является визуальное сравнение списка заказов в новой панели управления и в старой резервной копии (если доступ к ней еще возможен). Обратите внимание на поля «Статус» и «Дата изменения статуса». В HPOS статус заказа часто обновляется асинхронно через события, поэтому в интерфейсе может отображаться не тот этап, который был зафиксирован в момент оплаты. Проверьте случайные заказы из разных состояний: «Ожидает оплаты», «Обработка», «Выполняется», «Завершен». Если статусы не совпадают с реальным положением дел (например, заказ оплачен, но система показывает «Ожидает оплаты»), это указывает на проблему в работе плагина просмотра истории или в кэшировании данных.
Второй шаг — анализ детализации заказа. Откройте конкретный заказ и проверьте наличие всех позиций, скидок, налогов и информации о доставке. В HPOS данные о товарах хранятся отдельно от заголовка заказа, поэтому при неправильной конфигурации плагина-просмотрщика могут отсутствовать детали или отображаться в неверном формате. Убедитесь, что все метаданные (например, примечания для клиента, информация о промокодах) корректно перенесены и отображаются в расширенной информации заказа.
Третий шаг — тестирование сценариев изменения статуса. В старой системе статус часто менялся напрямую через базу данных или простые функции. В HPOS это происходит через триггеры событий (action hooks). Запустите тестовый заказ, измените его статус вручную и проверьте, обновляется ли запись в интерфейсе админ-панели без задержек. Если обновление происходит с опозданием или не происходит вовсе, возможно, требуется настройка кэша базы данных или обновление плагинов, отвечающих за отображение информации о заказах.
Четвертый шаг — проверка интеграций с внешними сервисами. Многие плагин-просмотрщики истории заказов зависят от структуры данных старой модели и могут некорректно парсить новые таблицы HPOS. Если вы используете сторонние модули для аналитики или отчетности, убедитесь, что они корректно считывают данные из новой архитектуры. В случае обнаружения ошибок в отображении истории, замените плагин на нативное решение WordPress/WooCommerce или используйте официальный API для получения актуальных данных.
Пятый шаг — оценка влияния на пользовательский опыт. Несоответствие статуса заказа в админ-панели может привести к тому, что менеджер не сможет вовремя уведомить клиента о готовности товара или ошибочно отменит заказ. Проверьте, корректно ли формируются уведомления клиентам при смене статуса. Если статус отображается неверно, это может вызвать жалобы покупателей и потерю доверия.
Если проверка выявляет системные ошибки в отображении истории заказов, не пытайтесь исправить их через правки кода или временные обходные пути. Лучше всего заменить плагин-просмотрщика на решение, которое изначально поддерживает HPOS, либо настроить кастомный интерфейс с использованием нативных API WordPress. Это обеспечит стабильность работы магазина и точность данных в системе управления заказами.
Подготовка документации и план действий при несовместимости
Качество документации по настройке плагинов определяет скорость восстановления работоспособности магазина после миграции. Без записей о параметрах, кастомных полях и логике работы модулей вы будете тратить время на повторное изучение кода или поиск информации в интернете. Создайте файл для каждого перенесенного плагина, где опишите его назначение, список используемых таблиц базы данных (если они были созданы вручную), а также ссылки на альтернативные решения, которые вы планируете внедрить.
План действий при обнаружении несовместимости должен быть утвердён до начала переноса. В нём фиксируйте порядок приоритетов: сначала восстанавливаются критические функции (корзина, оформление заказа, расчёт доставки), затем — вспомогательные инструменты (отчёты, интеграции с CRM). Если плагин не имеет нативной версии для HPOS, в плане укажите сроки поиска аналога или разработки кастомного решения. Это позволит избежать ситуации, когда магазин остаётся без возможности принимать заказы на несколько дней.
Для оценки рисков используйте матрицу совместимости. В ней перечислите все активные расширения и напротив каждого указывайте статус: «Нативно поддерживается», «Требует замены», «Требует кастомизации» или «Несовместимо». Если плагин решает задачу через кастомные таблицы, как указано в проверке функционала, сразу найдите готовый модуль для HPOS. Это исключит необходимость писать код с нуля и снизит вероятность ошибок при переносе данных.
Важно предусмотреть варианты решения, если альтернативы не найдены. В таких случаях можно временно отключить плагин и реализовать его функции через кастомные функции WordPress или плагины-обёртки. Для этого в плане действий пропишите конкретные шаги: какие файлы создать, где разместить их и как подключить к системе. Такой подход сохраняет работоспособность магазина даже при отсутствии готовых решений на рынке.
Документация должна включать не только технические детали, но и инструкции для персонала. Опишите, как изменился интерфейс админ-панели после переноса, какие новые кнопки появились или исчезли, как теперь формируется история заказов. Это ускорит обучение сотрудников и снизит количество ошибок при работе с новой системой. Если плагин меняет логику отображения статусов заказа, обязательно зафиксирйте эти изменения в инструкции.
Используйте резервную копию для тестирования планов действий. Перед внедрением изменений на рабочем сайте проработайте сценарии отката и восстановления функций на тестовой копии базы данных. Это позволит проверить, работает ли предложенная альтернатива и не приводит ли она к конфликтам с другими модулями. Только после успешного прохождения тестов переходите к реализации плана на основной системе.
Вопросы и ответы
Можно ли временно отключить HPOS для отдельных плагинов?
Нет. Переключение на HPOS — это глобальная настройка WooCommerce, которая применяется ко всем заказам в магазине. Отдельные плагины не могут работать в старой и новой моделях одновременно без промежуточного слоя (middleware), который сам по себе является сложной архитектурой.
Как проверить, использует ли плагин кастомные таблицы?
Откройте файл `functions.php` темы или код плагинов и выполните поиск ключевых слов: `add_action('init', …)` с регистрацией метаданных через `update_post_meta` (старый стиль) или использование таблиц `wp_wc_*`. Если плагин создает таблицы вручную (например, `wp_custom_orders`), он требует переработки логики под нативные таблицы HPOS.
Что делать, если платежный шлюз перестал работать после миграции?
Проверьте, не изменились ли поля в объекте заказа, которые использует API шлюза. В HPOS структура заказа стандартизирована, но некоторые шлюзы могут ожидать специфические метаданные старой модели. Если интеграция зависит от кастомных полей, их нужно либо перенести в нативные поля `meta`, либо настроить плагин-адаптер, который преобразует данные перед отправкой API.
