WP: синхронизация остатков и цен по расписанию (XML/CSV/API) — как оптимизировать с WP-Cron
Вечер, 22:47, телефон вибрирует где-то под подушкой. Менеджер склада шлет CSV с остатками: «Срочно обновите, завтра придет проверка». Вы, конечно, молодец, переносите все в WooCommerce, жмете обновить и выдыхаете. Утром выдыхаете второй раз, когда звонит клиент: «Вы продали мне то, чего нет». Виноваты не вы, виноват тайминг. На сайте данные живут отдельно от реальности, а реальность любит бить по голове тем, кто не синхронизирует.
Я Артур Хорошев. Ниже — рабочая схема, как навести порядок в синхронизации остатков и цен в WordPress с помощью WP-Cron и автоматики через make.com. Без драм, с нормальными примерами, с теми мелочами, из-за которых обычно все и ломается. Если интересно копнуть глубже и прокачать автоматизации под ваши процессы, пригодятся мои материалы и обучение: Обучение по make.com и готовые сценарии как подписка — Блюпринты по make.com. Хотите научиться автоматизации рабочих процессов с помощью сервиса make.com и нейросетей ? Подпишитесь на наш Telegram-канал.
Почему WP-Cron ведет себя как ленивый сторож и как его приструнить
WP-Cron в WordPress — это не настоящий cron, а имитация по событию. Он срабатывает, когда кто-то заходит на сайт. На сайтах с низким трафиком задачи могут подвисать минутами и часами, на нагруженных — стартовать несколько раз одновременно и бодаться за ресурсы. Для синхронизации цен и остатков это боль: вы либо опаздываете, либо грузите сервер, либо получаете гонки обновлений. Решение простое и скучное — отключить WP-Cron и подружить сайт с системным cron на сервере. С тех пор расписание будет выполняться по минутам, а не по погоде.
В wp-config.php ставим простой флажок, после которого WordPress перестанет дергать крон при каждом посещении, а будет ждать системный вызов. Тут нет магии, только дисциплина:
define('DISABLE_WP_CRON', true);
Дальше включаем системный cron. На VPS это одна строка в crontab, на shared-хостинге чаще дают веб-интерфейс. Суть одна — раз в 5 минут аккуратно дергать файл wp-cron.php.
*/5 * * * * php /var/www/site/public_html/wp-cron.php >/dev/null 2>&1
Если PHP-cli не доступен, можно использовать curl к вашему домену, но обязательно по https и по внутреннему адресу, чтобы не ловить лишние плагины кэширования по дороге. После этого расписание перестает быть «по вдохновению» и становится по секундам, как бухгалтерия любит.
Что именно синхронизируем и как это не сломать
В интернет магазине обычно живут две вещи, которые мечтают убежать в разные стороны: цена и остаток. Плюс вариации, статусы наличия, распродажи, иногда валюта и округления. Ключ практической жизни — каждый товар должен иметь стабильный внешний идентификатор. Идеально — артикул SKU. Именно по нему вы сопоставляете позиции, а не по названию «Кроссовки Nike 42 черные», которое поставщик вчера переименовал в «Кроссовки Nike Black 42» и сделал вид, что ничего не было. Если SKU нет, придумываем суррогат — код из системы учета, штрихкод, GUID, но пусть он будет один и навсегда.
Синхронизацию делим по типу данных. Остатки чаще меняются, их можно дергать хоть каждые 5 минут. Цены трогают реже — раз в день или при поступлении нового прайса. Смены статусов и распродаж — по мере необходимости. И да, лучше делать инкрементальные обновления: если у вас 50 тысяч SKU, то крутить каждый раз все позиции — это как таскать воду ведрами, когда рядом есть кран. Выгоднее обновлять только то, что изменилось.
Где брать данные: XML, CSV и API от 1С, МойСклад и друзей
Россия — страна CSV, XML и 1С. У поставщика может быть хоть CommerceML XML, хоть CSV на SFTP, хоть API МойСклад, иногда — Excel на почте, да. make.com как раз и нужен, чтобы не городить самостоятельно десятки интеграций. Он заберет файл с SFTP, распарсит XML, вызовет API, разложит все по колонкам, отфильтрует и отдаст в WooCommerce через REST API. Сценарий выглядит приземленно: по расписанию забираем источник, приводим к единому виду, маппим поля, обновляем магазин пакетами и пишем лог. Если источник нестабилен, ставим повторные попытки и таймауты, а еще лучше — резервный источник или буфер на своем сервере.
Для WooCommerce работаем через /wp-json/wc/v3. Авторизация — ключ и секрет, которые вы создаете в настройках WooCommerce, права ставим read/write, трафик только по https. Для больших партий у Woo есть пакетный метод products/batch, он экономит запросы и время. Важно обновлять по SKU: сначала ищем id продукта по метаполю _sku, потом шлем обновление. Это привычнее, чем пересоздавать карточки, и точно безопаснее для SEO, фото и отзывов.
Роль WP-Cron, когда рулит make.com
Синхронизация может жить и без WP-Cron, если весь график в make.com. Но удобнее разделить задачи. Пусть make.com по расписанию вытягивает источник и складывает результат в ваш WordPress через API или в промежуточную таблицу, а WP-Cron на стороне сайта запускает точечные сервисные процессы: прогрев кэша, пересчет вариаций, пересборку цен с налогами, чистку временных данных. Так меньше риск упереться в таймауты веб-сервера и легче масштабировать. Если очень хочется, можно сделать и наоборот — WP-Cron дергает ваш приватный вебхук в make.com, и сценарий там решает все целиком.
Технические мелочи, которые спасают утро
Блокировка от наложения задач. Самая частая проблема — следующий запуск начинает работать, пока предыдущий еще крутится. Ставим легкий замок через опцию в БД. Перед стартом проверяем флаг, если процесс идет — выходим. Если процесс завис, таймаут снимает блокировку. Примерно так, без излишеств:
$lock = get_option('my_sync_lock');
if ($lock && time() - $lock < 15 * 60) { return; }
update_option('my_sync_lock', time());
// ... ваша синхронизация ...
delete_option('my_sync_lock');
Пакеты вместо одиночных запросов. Обновлять 500 позиций по одному запросу — это попросить сервер разозлиться. Лучше собирать по 50-100 товаров в один batch, особенно если дергаете вариации. На стороне make.com есть модули, которые аккуратно режут массивы на чанки, на стороне WooCommerce это сильно экономит на сетевых накладных.
Вариации и остатки. В WooCommerce остаток вариации хранится у вариации, а не у родителя. Когда поставщик отдает одну строку на модель без разбивки по размерам, придется раскладывать на стороне make.com: XL обновляется одной цифрой, M — другой. Это норм, но не пытайтесь пересоздавать вариации на лету каждый запуск. Лучше один раз подготовить структуру и дальше только обновлять qty и price.
Кэш и фронт. Любимый эффект: в админке остатки уже новые, на витрине старые. Виноваты кэширующие плагины и CDN. Лечится тонкой очисткой только затронутых страниц. После пакетного обновления соберите список product_id и очистите кэш по ним. Если в лоб — инвалидируйте кэш архива и фида. Только не выключайте кэш полностью, это выстрел в ногу.
Часовые пояса. В настройках WordPress ставим «Европа/Москва», в make.com тоже выставляем московское время для расписаний. Иначе ночные прайсы внезапно превращаются в утренние и бухгалтер снова смотрит на вас, как на эксперимент.
Сценарий make.com: живой пример
Возьмем кейс: поставщик отдает CSV на SFTP, в котором 60 тысяч строк, цены меняются раз в день, остатки — каждый час. В make.com настраиваем расписание. Ночью забираем цены, парсим CSV потоково, приводим к единой схеме с ключом SKU, пересчитываем валюту, округляем по правилам магазина. Дальше отправляем в WooCommerce батчами по 100 позиций, логируем результаты, а ошибки — в отдельный Google Sheet и в Telegram уведомление. Днем, каждые 10 минут, запускается короткий маршрут только для остатков. Он берет файл остатков, обновляет только qty, не трогая цены и статусы.
Если источник временно недоступен, маршрут делает три попытки с экспоненциальной паузой и уходит спать. Если недоступен ваш сайт, make.com аккуратно складывает неотправленные пакеты в очередь, а WP на своей стороне через WP-Cron чистит замки и обновляет только то, что реально приехало. Получается аккуратная схема без драм и ночных созвонов.
Как не словить бан по ресурсу сервера
Уважайте лимиты. Даже если у WooCommerce нет жестких квот, у вашего сервера есть CPU, память и таймауты PHP-FPM. На пакетное обновление ставьте разумный рейт, например 10-15 батчей в минуту, и разносите тяжелые задачи по ночи. Action Scheduler, который живет в WooCommerce, отлично справляется с очередями, его можно дергать прямым импортом и пускать обработку в фоне. Сложные обновления перемещайте туда, чтобы не душить публичный сайт. И да, не включайте verbose-логирование на проде навсегда, логи тоже едят диск, иногда жадно.
Про деньги, курсы и здравый смысл
Есть соблазн сделать «быстрый импорт»: кнопка в плагине, заливаем CSV, готово. Он даже работает — один раз. Когда процессы становятся регулярными, восторг заканчивается, а начинается рутина. Обучиться нормальной автоматизации дешевле, чем месяцами тушить мелкие пожары. Я делаю курс по make.com, где показываю на живых сценариях, как привязывать API, парсить XML и CSV с российских сервисов, чинить узкие места и не терять заказы. А еще есть готовые сборки на базе типовых кейсов — Блюпринты по make.com. Хотите автоматизацию без боли и с людьми, которые отвечают, а не исчезают — присоединяйтесь. Ну или соберите сами, если руки чешутся, я не против.
Мини-кейс из практики
Интернет-магазин одежды с 38 тысячами SKU. Источник — МойСклад API, обновление остатков каждые 7 минут, цены — ночью. Сначала магазин падал от одиночных запросов и дублировал вариации, потому что разные названия размеров. Решение: жесткое сопоставление по SKU, пакетные обновления, замок на время работы, Action Scheduler для вариаций, отдельный модуль очистки кэша только по затронутым товарам. На стороне make.com — резка массивов на 80-товарные чанки, два маршрута, расширенный лог и уведомления в Telegram. Время синхронизации сократилось с 1 часа до 6 минут, продавцы перестали играть в угадайку «на складе что-то есть или его нет». Кофе снова стал вкусным, а не тревожным.
Чек на здравость
Если коротко: WP-Cron в одиночку — ненадежный напарник, но в паре с системным cron работает как часы. make.com вытягивает грязную работу по интеграции, а WooCommerce через REST и пакетные обновления понимает и принимает данные. Дальше все про дисциплину: SKU как ключ, блокировки, расписание, аккуратные логи, разумные лимиты и уведомления. И да, тестируйте на стейдже, а не на живом магазине. Иначе утром будет не кофе, а совещание.
FAQ
WP-Cron или системный cron — что выбрать для синхронизации?
Системный cron надежнее. Отключаем псевдо-крон в WordPress, запускаем wp-cron.php через cron на сервере. Так задачи идут по расписанию независимо от трафика на сайте. WP-Cron оставляем как интерфейс планировщика, но дергает его уже системный таймер.
Как часто обновлять остатки и цены, чтобы не убить сервер и не словить пересортицу?
Остатки — по 5-15 минут для ходовых категорий, остальные раз в 30-60 минут. Цены — ночью или 1-2 раза в день. Ставьте отдельные расписания и не мешайте разные типы данных в одну задачу. Так вы не будете гонять лишний трафик.
Поставщик высылает CSV на почту. Это вообще реально автоматизировать?
Реально. В make.com есть модули для IMAP, они забирают письма, вытаскивают вложения, складывают файл в облако или на SFTP и тут же запускают парсинг. Дальше как обычно — маппинг и обновление WooCommerce.
У нас 1С с CommerceML. Нужно писать свой импорт?
Не обязательно. В make.com можно распарсить XML CommerceML, но удобнее, когда 1С отдает нормализованный выгрузочный XML или JSON с ключом SKU и датой обновления. Если не получается, делайте преобразование в промежуточный формат на своей стороне и уже его отдавайте в магазин.
Как не получить дубликаты и гонки при одновременных запусках?
Ставьте блокировку задачи на уровне опции в БД и делайте разумный таймаут. Разносите обновления цен и остатков по времени. Используйте пакетные методы WooCommerce и не дергайте одну и ту же позицию несколькими сценариями.
Можно ли обойтись без программиста?
Если кейс типовой, да. make.com закроет 80 процентов задач мышкой. Останутся пара мест, где пригодится код — например, кастомная логика маппинга, расчеты или тонкий кэш. Для старта этого вполне достаточно. Если хотите ускориться — посмотрите обучение и мои блюпринты.
Как мониторить, чтобы узнать о сбое до того, как позвонит клиент?
Логи в make.com и в WordPress, плюс уведомления в Telegram при ошибках, нуле пустых остатков и при необычно длинном времени работы. Можно добавить контрольный счетчик измененных позиций и тревожиться, если цифра упала к нулю.
Shared-хостинг потянет такую схему?
Потянет, если не устраивать штурм. Ставьте частоту на разумном уровне, используйте пакетные обновления и выносите тяжелую обработку в make.com. Если упираетесь в лимиты — пора на VPS, дешевле, чем терять заказы.
Что с безопасностью ключей WooCommerce и доступов к API?
Храните ключи в переменных окружения или закрытых настройках, трафик только по https, ограничьте IP, если возможно. Не давайте прав больше, чем нужно, и ротируйте ключи раз в несколько месяцев. Банально, но работает.
Можно ли запускать обновление по событию, а не по расписанию?
Да. Поставщик может дергать ваш вебхук в make.com при изменении остатков. Это быстрее, чем ждать крон. Главное — иметь запасной план на случай, если вебхук не пришел, и ночной пересчет как страховку.
