Хотя мы хорошо знаем WordPress, здесь не обошлось без проблем. Одна из проблем, которая весьма разочаровывает, — это архитектура базы данных, используемая WooCommerce. В частности, в папке хранятся различные записи. wp_posts таблица в WordPress, а тип записи классифицирует их. Вот список некоторых наиболее распространенных типов сообщений, а также краткое описание каждого типа.

1. Продукт: Тип сообщения product используется для хранения информации об отдельных продуктах в вашем магазине WooCommerce. Сюда входит название продукта, цена, описание и дополнительная информация.
2. Вариант продукта: Тип сообщения product_variation относится к различным вариантам продукта, таким как размер или варианты цвета. Они связаны с основным продуктом.
3. Заказ: Тип сообщения shop_order хранит информацию о заказах клиентов, включая статус заказа, информацию о клиенте и заказанные товары.
4. Возврат заказа: Тип сообщения shop_order_refund отслеживать возвраты, связанные с конкретными заказами.
5. Купон: Тип сообщения shop_coupon хранит информацию о купонах и скидках, которые можно применить к заказам.
6. Вебхук магазина: Тип сообщения shop_webhook используется для хранения информации, связанной с веб-перехватчиками, которые можно использовать для запуска действий в ответ на события в вашем магазине WooCommerce.
7. Подписка на магазин: Тип сообщения shop_subscription Это важно, если в вашем магазине есть товары по подписке и хранится информация о подписках клиентов.
8. Продление подписки магазина: Тип сообщения shop_subscription_renewal используется для регистрации продления подписки.
9. Переключатель подписки магазина: Тип сообщения shop_subscription_switch отслеживает изменения или переключения в продуктах по подписке.
10. Подписка магазина ожидает оплаты: Тип сообщения shop_subscription_pending_payment представляет собой заказы на подписку с непогашенными платежами.
11. Подписка в магазине не удалась: Тип сообщения shop_subscription_failed используется для записи неудачных платежей по подписке.
12. Обзор продукта: Тип сообщения product_review используется для хранения отзывов клиентов о продуктах. Каждый отзыв рассматривается как отдельная публикация, включая информацию о рецензенте, текст обзора и оценки соответствующего продукта.

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

Конфликты базы данных на wp_posts

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

• номер заказа не подряд. Если у вас есть один заказ, равный 5, а затем вы создаете 3 страницы, идентификатор вашего следующего заказа будет 9. Просмотр идентификатора заказа не дает вам никакой информации о количестве заказов, которые вы выполнили на своем сайте.
• номер заказа изменить нельзя! WooCommerce использует этот идентификатор и передает его непосредственно вашему клиенту во всех будущих счетах и ​​ссылках на заказы.

Весьма тревожно, что инженеры WooCommerce не использовали для заказов дополнительное поле, одновременно последовательное и уникальное, но отличающееся от их внутреннего идентификатора. Другими словами, идентификатор 6702 мог бы быть счетом 4322… и его можно было бы легко добавлять между базами данных с разными идентификаторами. wp_posts. Продукты делают это с помощью дополнительного поля SKU, но оно также не полностью интегрировано в платформу для использования в качестве первичного ключа.

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

Как это решить

Решение этой проблемы есть, но оно непростое. Import Export Suite for WooCommerce — это решение, которое я использовал, и оно делает процесс намного более управляемым.

Шаг 1. Экспортируйте данные текущего заказа из вашей производственной среды.

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

Шаг 2. Импортируйте данные текущего заказа в среду выпуска.

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

Шаг 3. Разрешение конфликтующих идентификаторов

По мере того, как плагин перебирает импортируемые записи, он сообщает, есть ли конфликты для определенных идентификаторов. Вот тогда становится немного сложнее.

При прямом подключении к базе данных MySQL мне пришлось искать эти идентификаторы. wp_posts table, чтобы узнать, какой тип записи это был. Если это была страница или сообщение, я просто копирую их, чтобы убедиться, что используется новый идентификатор. Если это было что-то другое, мне нужно было решить, как с этим справиться.

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