Кратко — причина почти всегда не в «баге» плагина, а в том, как плагин сравнивает входные данные с уже записанными в товаре значениями, либо в том, что на самом деле он получает другой XML/другие поля при запуске cron. Ниже — практический чек‑лист и методы отладки, которые помогут найти причину.
1) Сразу проверьте источник данных (XML при запуске cron)
- Убедитесь, что cron реально скачивает тот же файл, который вы редактируете вручную. Часто бывает CDN/кэш или URL с авторизацией, и cron получает старую версию.
- Сделайте на сервере wget/curl того же URL, что использует cron, и сохраните файл: curl -sS 'URL' -o /tmp/feed.xml; md5sum /tmp/feed.xml. Сравните с локальной копией.
- Проверьте логи cron (в /var/log/cron или вывод вызова), чтобы убедиться, что задача запускается вовремя и без ошибок.
2) Убедитесь, что плагин сопоставляет записи правильно
- В настройках импорта вы используете _sku для поиска соответствия — убедитесь, что SKU уникальны и одинаковы в XML и в базе (нет лишних пробелов, нет регистра/скрытых символов).
- Проверьте, что вы не сопоставляете родительский товар вместо вариации (для вариативных товаров SKU обычно принадлежат вариациям).
- Проверьте, что поле для сравнения — именно то, которое плагин использует как уникальный идентификатор (часто есть выбор: ID, SKU, кастомное поле).
3) Проверьте, какие именно ключи метаданных обновляются (WooCommerce)
- Цены обычно хранятся в _price, _regular_price, _sale_price; наличие в _stock, _stock_status, _manage_stock.
- Убедитесь, что в шаблоне импорта вы обновляете именно те ключи, которые смотрит WooCommerce/ваша тема/плагины.
4) Возможные причины «иногда обновляет всё, иногда — ничего»
- Формат/нормализация данных: «100» vs «100.00» vs «100,00» vs «100 ₽» — плагин может рассматривать это как изменение (или не рассматривать, если он нормализует). Проверяйте точно текст/число в XML и в базе.
- Скрытые символы/пробелы/переносы строки. Сделайте trim и уберите ненужные символы.
- Порядок и типы: если XML присылает строку, а в БД хранится число (или наоборот), сравнение может давать неожиданный результат.
- Кэш/объектный кэш (Redis/Memcached) или транзиенты могут показывать старые значения и мешать видимой проверке.
- Конфликты с другими плагинами или кастомными хуками, которые меняют мета при сохранении (после импорта может быть обратная перезапись).
- Тайминги/совпадение запусков: если импорт начал выполняться одновременно с другим процессом, возможна конкурентная запись.
5) Как детально отладить: практические шаги
a) Логирование XML, который получает cron
- На время отладки добавьте cron‑задачу, которая сохраняет XML в /tmp/feed_cron_{ts}.xml и пишет md5 + timestamp в файл логов. Так вы точно увидите, какой файл обрабатывался.
b) Сравнение значений вручную (пример)
- Извлеките конкретный SKU из XML (grep/xpath) и сравните с базой:
- curl -s 'URL' | xmllint --xpath "//*[sku='THE_SKU']/price/text()" -
- SELECT meta_value FROM wp_postmeta WHERE post_id = (SELECT ID FROM wp_posts p JOIN wp_postmeta m ON p.ID=m.post_id AND m.meta_key='_sku' AND m.meta_value='THE_SKU') AND meta_key='_regular_price';
Это покажет, были ли реальные различия.
c) Тестовый запуск для одного товара
- Сделайте маленький XML с одним товаром (тот же SKU) и запустите импорт вручную через интерфейс. Посмотрите лог — что обновилось и почему. Повторите несколько раз, меняя формат цены (100, 100.00, 100 ₽) — посмотрите, когда WP All Import считает запись изменённой.
d) Включите WP_DEBUG и смотрите PHP‑логи
- В wp-config.php включите define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); и проверьте wp-content/debug.log на ошибки/предупреждения во время запуска импорта.
e) Используйте Query Monitor / проследите хуки
- Установите плагин Query Monitor, запуск импорта вручную и просмотрите запросы к wp_postmeta, чтобы увидеть, какие значения читаются/пишутся.
- Если есть навыки PHP, временно подпишитесь на хуки WP All Import (pmxi_*): логируйте входные значения и существующие мета перед сохранением, чтобы понять, что сравнивается. (Документация WP All Import описывает хуки pmxi_before_xml_import, pmxi_saved_post и др.)
f) Посмотрите логи самого WP All Import
- В разделе Manage Imports -> Log смотрите, какие ID/SKU отмечены как обновлённые. Плагин показывает, какие записи были обработаны, но иногда не показывает старое/новое значение — тогда используйте шаги (b) и (e).
6) Проверка cron и способа запуска импортов
- Если вы используете системный cron, убедитесь, что он вызывает правильный URL/скрипт. Если он вызывает wp-cron.php, то проверьте, не отключен ли wp-cron в конфигурации.
- Проверьте, нет ли ошибок прав доступа или таймаутов при запуске импорта (веб‑сервер/timeout PHP).
7) Если ничего не помогает — временный обход
- В настройках импорта есть опция «Force update»/«Update even if no changes» — можно её включить до выяснения причин, чтобы гарантировать актуальность данных. Но это костыль — лучше найти первопричину.
8) Приоритет действий (быстрое/незамедлительное)
- Сохраните XML, который использует cron, и сравните md5 с тем, что вы редактировали.
- Для нескольких проблемных SKU вручную сравните XML‑значение и meta_value в БД.
- Запустите тестовый одноэлементный импорт вручную и посмотрите поведение.
- Включите WP_DEBUG и просмотрите логи.
9) Когда обращаться в поддержку
- Если вы удостоверились, что XML корректен и плагин получает правильные данные, но логика сравнения ведёт себя непредсказуемо, соберите: пример XML, SKU проблемных товаров, логи импорта (включая timestamps и md5 файла), включённые настройки импорта — и отправьте в поддержку WP All Import (они знают внутренние детали сравнения/нормализации).
Если хотите, могу:
- Составить конкретный набор SQL‑запросов для проверки значений по SKU.
- Придумать простую функцию/хук для логирования входных и существующих значений при импорте (пример кода).
- Помочь настроить сохранение XML, получаемого cron, и проверить MD5/время.
Напишите, хотите ли пример запросов/скрипта для логирования — я подготовлю.