Как регистрировать действия плагина (cron)?

Есть ли рекомендуемый способ регистрации (неудачных) действий cron из вашего плагина? Например, у меня есть плагин, который каждый час синхронизируется с внешней службой. Я хочу регистрировать, сколько было изменено, но также и при сбое синхронизации. Что бы вы порекомендовали здесь? Новая таблица базы данных? Плагин « Логарифмические устаревшие уведомления» делает это с настраиваемым типом сообщений, но это может быть слишком много накладных расходов? Я считаю, что WordPress не поставляется со стандартным протоколом регистрации ?

Solutions Collecting From Web of "Как регистрировать действия плагина (cron)?"

  1. Используйте файл для записи событий. Здесь есть несколько недостатков;

    • Разрешения файловой системы . При развертывании приложения вам придется позаботиться о том, чтобы предоставить разрешение веб-сервера на запись в файл. И, конечно же, вам придется писать код, который проверяет, можете ли вы писать в файл и выпустить предупреждение, когда вы не можете. Это добавляет сложности и, вероятно, является причиной проблем с развертыванием.
    • Случайное удаление . Вы можете случайно удалить собственный файл журнала и потерять свои записи. Это может быть неудобно.
    • Пользовательский формат . Вам нужно придумать специальный (машиночитаемый?) Текстовый формат для записи событий в ваш файл. Когда вам нужно изменить формат журнала, нет удобного способа переноса старых записей. Когда вы хотите сделать какой-то анализ в журналах, вам придется разбирать записи. Это приводит к большему количеству кода и сложности. Сложность плохая.
  2. Используйте таблицу базы данных . Создайте свою собственную таблицу базы данных и зарегистрируйте там события. Ни один из недостатков, перечисленных выше, не применяется. Это не добавляет много сложности. Автоматизируйте создание и удаление таблицы с помощью плагина-крючка, и, как мне кажется, у вас достаточно надежная система журналов.

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

  4. Используйте регистратор ОС . Когда вы используете функцию syslog в PHP, вы можете записывать события в системный регистратор (syslog в Unix, журнал событий в Windows NT). Настройка заданного пользователем syslog усложняет развертывание.

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

Надеюсь это поможет!

Используйте такую ​​функцию ведения журнала, чтобы она записывала ваш выход в debug.log, настроив ваш wp-config.php следующим образом, который я нашел здесь :

 /** * This will log all errors notices and warnings to a file called debug.log in * wp-content (if Apache does not have write permission, you may need to create * the file first and set the appropriate permissions (ie use 666) ) */ define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors',0); 

Это должно работать, по крайней мере, для целей отладки / разработки (я не уверен, насколько это было бы полезно для ведения журнала, но оно работает для разработки).

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

Я не боюсь плагинов, которые создают таблицы, но, возможно, это потому, что я видел базы данных WordPress с 8 000 000 записей wp_term_relationships и 300 000 сообщений, и я знаю, насколько неприятен этот опыт.

dbDelta() и register_activation_hook() будут вашими друзьями здесь. См. Создание таблиц с плагинами .