Intereting Posts
Цикл в сообщениях категории Поддерживает ли WordPress какие-либо файлы вне основной папки (и базы данных)? Отображение цен без налога в определенных категориях удалять пункты меню, если пользователь не может читать Могу ли я использовать ту же функцию санитизации в нескольких текстовых блоках темы? создать пользовательский макет списка продуктов woocommerce Включить CORS для отправки метода POST с помощью React Преобразование каждой новой строки в текстовое поле как новое значение в массиве Включить загрузку пользовательского логотипа, если логотип отсутствует в заголовке Показать изображение EXIF ​​info Непосредственные ссылки WordPress неверны. Он хочет, чтобы я изменил файл htaccess. Но затем сбои сайта Как сделать глобальную работу почты с пользовательским типом сообщения? Почему при навигации по home.php разбивается страница на пустую страницу? Ошибка анализа: синтаксическая ошибка, неожиданный T_ENDWHILE в Как я могу ссылаться на последнее сообщение в категории?

Удалять сообщения из типа сообщения автоматически через Cron

как я могу использовать Cron для удаления сообщений определенного типа сообщений, когда они достигнут определенного предела, например, сохранить максимум 50 сообщений?

Причина в том, что эти сообщения периодически импортируются автоматически, поэтому я хочу, чтобы БД становилась слишком большой, кроме того, что старые сообщения не нужны.

Solutions Collecting From Web of "Удалять сообщения из типа сообщения автоматически через Cron"

Хотя я не понимаю мотивацию усечения сообщений, я думаю, что это упражнение полезно для вас, чтобы понять, как использовать cron + WordPress.

Создание функции для усечения сообщений

Это можно использовать для обоих методов ниже WP-cron или UNIX cron.

function foobar_truncate_posts(){ global $wpdb; # Set your threshold of max posts and post_type name $threshold = 50; $post_type = 'foobar'; # Query post type $query = " SELECT ID FROM $wpdb->posts WHERE post_type = '$post_type' AND post_status = 'publish' ORDER BY post_modified DESC "; $results = $wpdb->get_results($query); # Check if there are any results if(count($results)){ foreach($result as $post){ $i++; # Skip any posts within our threshold if($i <= $threshold) continue; # Let the WordPress API do the heavy lifting for cleaning up entire post trails $purge = wp_delete_post($post->ID); } } } 

Вот два основных подхода к планированию событий в WordPress.

Подход №1: Использование WP-Cron

Поскольку это WP-способ сделать это, мы сначала рассмотрим этот подход. Обратите внимание: WP Cron не является истинным cron, и он часто называется psuedo-cron. Это непротиворечиво, если у вас низкий трафик на сайте, поскольку он основан на запросах на сервер. Если запросы не поступают, ваше запланированное событие задерживается.

Расписание вашего мероприятия

 if(!wp_next_scheduled( 'foobar_truncate_posts_schedule')){ wp_schedule_event(time(), 'daily', 'foobar_truncate_posts_schedule'); } 

Подключиться к вашему графическому действию

 add_action('foobar_truncate_posts_schedule', 'foobar_truncate_posts'); 

Если вы обнаружите, что WP-Cron не хватает вашего расписания, публикации запланированных сообщений и т. Д., Вы можете автоматизировать его с помощью cron UNIX. Вот отличная статья, чтобы показать вам, как выполнить ping wp-cron.php через определенные промежутки времени. Вот что они рекомендуют держать wp-cron вовремя с помощью UNIX cron.

 wget http://www.server.com/wp-cron.php > /dev/null 2>&1 

Подход №2: Использование UNIX cron

Вы можете использовать настоящие UNIX-клоны с собственной функциональностью admin-ajax.php.

Проверьте cURL на своем сервере

Этот подход использует cURL, который должен быть установлен на вашем сервере. Если нет, и вы используете Apache, sudo apt-get install php5-curl а затем sudo /etc/init.d/apache2 restart .

Создайте крючок AJAX

Не забудьте установить его в nopriv, поскольку ваш сервер не будет аутентифицироваться с помощью WP.

 add_action('wp_ajax_nopriv_truncate_posts', 'foobar_truncate_posts_cron'); function foobar_truncate_posts_cron(){ # We use the user-agent as a shared key $shared_user_agent = 'FooBar TruncatePostsCron/1.0'; # Block unwanted IP addresses $whitelisted_ips = array( //IPs allowed to run this operation '192.168.1.1', '127.0.0.1' ); # Retrive Request Information $request_user_agent = $_SERVER['HTTP_USER_AGENT']; $request_ip = $_SERVER['REMOTE_ADDR']; # Authenticate if($request_user_agent === $shared_user_agent && in_array($request_ip, $whitelisted_ips)) echo foobar_truncate_posts(); // Reusable function else echo 'Authentication failed for post trucation cron.'; exit; } 

Добавьте свой Crontab

Эта конфигурация будет работать один раз в день последовательно. -A устанавливает секретный секретный агент пользователя -o указывающий выходной файл, action=truncate_posts относительно вашего действия ajax hook. Verify /user/bin/curl – это правильный путь для выполнения команды cURL. Вместо этого вы можете просто использовать curl .

 0 0 * * * /usr/bin/curl -A 'FooBar TruncatePostsCron/1.0' -o ~/truncate_posts.log http://yourdomain.com/wp-admin/admin-ajax.php?action=truncate_posts 

И, наконец, всегда убедитесь, что вы установили register_globals=off в свой php.ini, чтобы предотвратить спуфинг любого типа.

И наконец…

Это два основных подхода к WordPress + cron (истинно или нет). Существует много способов foobar_truncate_posts() кошку с вашим конкретным вариантом использования в foobar_truncate_posts() . Я уверен, что вы можете настроить его здесь. Надеюсь, что это помогает вам!

Наиболее солидным методом было бы использование самого WP-Cron. Но если у вас есть очень легкое требование, вы можете оставить его как таковое, и никакие проблемы, такие как множественные посещения, не могут вызвать многократную попытку wp-cron и перекрытие событий, никогда не произойдет.

Должен упоминаться, безопасно ли запустить wp-cron.php дважды, если первый экземпляр занимает слишком много времени?

Здесь четко указано (на самом деле ответ, который заслуживает большего количества голосов) имеет утверждение в абзаце thrid: «потому что wp-cron перенацеливает и выполняет задания unschedules, когда он идет. Перед тем, как он выполнит задание, он запустит его. Это предотвратит выполнение задания два раза ", да есть опасения, что может быть состояние гонки, которое может возникнуть там, где тяжелый болотистый блог может разыграть одно и то же событие дважды.

Теперь у команды wordpress есть решение для того же самого, и это нужно отключить cron в wp-config.php. Это не отключает cron, но фактически отключает запуск cron при посещении. После этого веб-cron может быть настроен с использованием wget или curl, но если мы не уверены, что службы завершатся через 30 секунд, что является тайм-аутом по умолчанию для php-скрипта, тогда cron должен быть настроен на самом сервере, используя php cli. Более подробный документ о том, как это сделать, можно найти на странице https://rtcamp.com/tutorials/wordpress/wp-cron-crontab/