Wordpress api в cron задании.

Пришлось делать крон задание с использованием api Wordpress. Есть у него константа SHORTINIT. Позволяет включить из WP только api по работе с БД.

Выглядит это так:

<?php
// указываем, что нам нужен минимум от WP
define('SHORTINIT', true);
require_once( __DIR__ . '/wp-load.php' );

После этих строк нам доступна $wpdb.

Для использования других функций надо посмотреть wp-settings.php и подключать файлы что нужны ниже верхних строк. Файлы для подключения вида require( ABSPATH . WPINC . '/formatting.php' );. В этом же файле ниже идёт ряд инициализирующих функций. Используются опять же таки по необходимости.

Но самое интересное это то, что cron задание выполненное и отлаженное локально, при правильном переносе самого сайта на сервер, может просто не работать. Оказывается хостер при команде php -f /route-to-file/cron.php может спокойно запускать версии php 5.3.19(в моём случае) и ниже. Что приводит к потере использования кодировки utf8mb4. И поэтому все русские буквы превращаются в знак вопроса. Это пол беды. Из-за этого может "сыпаться" функция maybe_unserialize(). А это уже приводит к многочисленным ошибкам(не получаем опции в частности). Хуже то, что для старой php нужно указать в конфиге define('DB_CHARSET', 'utf8');, но нам ведь для сайта надо сохранять utf8mb4, тем более, что с большой долей вероятности кодировка всех таблиц идёт в ней. В общем не очень приятно менять кодировку. Приходится городить костыль, проверяющий поддержку кодировки utf8mb4 раньше, чем вызываем wp-load.php, чтобы объявить при необходимости define('DB_CHARSET', 'utf8');. Ещё один вариант решения на скорую руку это писать в кроне lynx dump путь-к-файлу-крона , или использовать вместо lynx wget. Но я думаю это более прожорливый метод. У меня на хостинге был ещё один способ указать версию php для крон-файла: например седьмая верси php вызывалась как php70 -f /route-to-file/cron.php. В ней тоже будет уже работать utf8mb4.

Заметили ошибку, можете подсказать еще что-то? - Обращаемся сюда