Верх страницы
Обложка к записи Запуск WP All Import из командной строки
Время для прочтения: 1 мин. 6 сек.

Запуск WP All Import из командной строки

WP All Import — это самый лучший в своей нише WordPress-плагин для импорта XML, XLS, который можно, например, использовать для синхронизации товарного каталога WooCommerce с данными 1С.

Что же с ним не так?

WP All Import не использует WP-Cron в полной мере, а требует явного вызова wp-cron.php со своими параметрами.

В WP All Import Pro v4.6.1 появился интерфейс командной строки WP-CLI прямо «из коробки».

Фактически он требует двух вызовов: первый, так называемый триггер, запускающий импорт, и второй — шаг итерации импорта (тик), в котором обрабатывается очередная порция данных.

Разработчики рекомендуют для тика ставить время повторения около 2 минут, но на практике этого времени может не хватить. Увеличение же этого времени приводит к увеличению пауз в импорте и росту общего времени импорта. В результате оно реально может вырасти до нескольких часов на больших объемах данных.

Хоть WP All Import и умеет скачивать файлы у поставщика, но работает только с кодировкой UTF-8, а большинство российских поставщиков дают те же CSV файлы в Windows-1251. Загрузки все равно требуют дополнительной обработки.

Всё это явно просится быть перенесённым на уровень серверного ПО, а не выполняться в админке WordPress или вызываться wget ом по крону. Но, к сожалению, этот плагин не умеет работать ни с WP-CLI, ни в командной строке. Так как же быть?

Решение было найдено в виде поста «WP All Import cron from CLI«.

Идея, реализованная Rolandow, заключается в прямом вызове PHP CLI сначала триггера, а потом последовательном вызове тиков WP All Import с секундной задержкой до тех пор, пока очередной тик не скажет, что импортировать больше нечего.

Какие плюсы данного подхода?

  • Так как всё выполняется через CLI — лимитов никаких нет
  • Веб-сервер (Apache, nGinx) не грузится
  • Тики итераций идут вплотную, не образуя дыр по времени
  • Данное решение удобно вешается на крон

Импорт, который до переделок занимал 10 часов и выполнялся в браузере (при этом он должен был быть в открытом состоянии), после указанной доработки — стал бегать за час-полтора. Прирост по скорости налицо.

Также стоит сказать отдельное спасибо Ивану Никитину за прекрасную доработку данного решения и доведения его до продуктового состояния.

Итак, чтобы всё это заработало, в скрипте задать следующие переменные:

  • JOB_ID — номер задания WP All Import (берется в админке WP All Import)
  • KEY — ключ для запуска (берется там же)
  • LOGFILE — имя и расположение файла лога
  • CURLOG — имя временного лога (он жизненно необходим для работы!)
  • ROOT_DIR — путь к руту сайта

Собственно, доработанный bash-скрипт wpallimport.sh:

#!/bin/bash
 
SITE="your-site.ru"
JOB_ID=999
KEY="Your-Key"
LOGFILE=/var/www/$SITE/logs/wp-all-import.log
CURLOG=/var/www/$SITE/logs/wp-all-import-$JOB_ID.tmp
ROOT_DIR=/var/www/$SITE/www
DONE=0
 
function log {
  echo "$(date): $*" >>$LOGFILE
}
 
echo "WP All Import:" $SITE " job id:" $JOB_ID
cd $ROOT_DIR
log "Start import for job id $JOB_ID"
 
php -e -r 'parse_str("import_key='$KEY'&import_id='$JOB_ID'&action=trigger", $_GET); include "wp-cron.php";' >>$LOGFILE 2>&1
sleep 1
 
while [ $DONE -eq 0 ]
do
  php -e -r 'parse_str("import_key='$KEY'&import_id='$JOB_ID'&action=processing", $_GET); include "wp-cron.php";' >$CURLOG 2>&1
  cat $CURLOG >>$LOGFILE
  DONE=$(grep 'is not triggered' $CURLOG | wc -l)
  sleep 1
done
rm $CURLOG
 
log "End of import for jobId" $JOB_ID
log ""
log ""

Запуск

Запускать скрипт можно по крону раз в сутки:

59 23 * * * $user /home/user/wpallimport.sh > /dev/null 2>&1

Или ручками в фоне (чтобы не держать консоль открытой) через nohup:

nohup ~/wpallimport.sh &

Комментарии и вопросы приветствуются.

Ссылки

ВКонтакте
Одноклассники
Telegram

Комментарии
Подписаться
Уведомить о
guest
19 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
Виталий
Виталий
1 год назад

Выскакивает ошибка /home/renshop/**мой сайт**/clcr/run-wp-cron.sh: line 20: php: command not found

Viktor Hryn
Viktor Hryn
8 месяцев назад

В лог добавляется код html страницы с таким содержимым:

p>There has been a critical error on your website.</p><p><a href=»https://ru.wordpress.org/support/article/debugging-in-wordpress/»>Узнайте больше про отладку в WordPress.</a>

включил дебуг

Parse error: syntax error, unexpected ‘:’, expecting ‘{‘ in /home/s/хххххх/хххххх.ru/public_html/wp-content/plugins/woocommerce/woocommerce.php on line 56

Последний раз редактировалось 8 месяцев назад Viktor Hryn ем
Viktor Hryn
Viktor Hryn
8 месяцев назад
Ответить на  Кобзарёв Михаил

было PHP 7,3
понизил до 7,2

в файле так вот функция записана:

56я строка —> function wc_get_container() : \Psr\Container\ContainerInterface {
   return $GLOBALS[‘wc_container’];
}

Alex
Alex
1 месяц назад

На хостинге рег.ру пишет

Your server is running PHP version 5.4.16 but WordPress 5.8 requires at least 5.6.20.

На вашем сервере работает PHP версии 5.4.16, но для WordPress 5.8 требуется не менее 5.6.20.

а на самом деле версия пхп 7.4 стоит
что делать?

Alex
Alex
1 месяц назад
Ответить на  Кобзарёв Михаил

Спасибо!
Заработало!

Alex
Alex
1 месяц назад
Ответить на  Кобзарёв Михаил

как завершить процесс wpall.sh по окончанию
после заливки висит процессах, и суммируется со следующим по расписанию

Alex
Alex
1 месяц назад
Ответить на  Кобзарёв Михаил

Это ежедневное обновление цен
и ежедневно киллять в PuTTY

Alex
Alex
1 месяц назад
Ответить на  Кобзарёв Михаил

Хостинг на рег.ру
оставил без присмотра на выходные
в итоге насумировало незакрытыми процессами до 178% процессорного времени
хотя в будни, укладывался в 7% отключая вручную. exit ставил, не помогло, видимо криво.

Alex
Alex
1 месяц назад
Ответить на  Кобзарёв Михаил

тех поддержка хостинга работает по своему хостингу, и не отвечает за исполняемые скрипты на стороне сайта

Alex
Alex
1 месяц назад
Ответить на  Кобзарёв Михаил

CentOS Linux release 7.8.2003 (Core)