cbnet Ping Optimizer

Привет! Вам может быть интересно, почему вы читаете это, вместо того, чтобы смотреть на настройки плагина. Что ж, причина, по которой вы не смотрите на настройки плагина, заключается в том, что больше нет никаких настроек плагина. Фактически, этот плагин больше не имеет никакой функциональности. Почему? Потому что функциональность этого плагина больше не нужна. Фактически, функциональность этого плагина, возможно, вообще никогда не понадобилась. Но, несмотря на это, сейчас это точно не нужно. Как работают пинги в WordPress Позвольте мне объяснить, почему, начиная с пошагового руководства по работе пингов в WordPress, любезно предоставлено @ Otto42: когда сообщение создается, обновляется, вставляется, изменяется и т. Д., В конце концов, оно всегда проходит через wp_insert_post () . wp_insert_post () вызывает wp_transition_post_status (). wp_transition_post_status () выполняет различные действия, но, что важно, делает следующее: do_action («{$ new_status} _ {$ post-> post_type}», $ post-> ID, $ post); Так вызывается действие new-status и new-post-type. В данном случае нас интересует статус публикации для типа записи post, поэтому publish_post - это ловушка действия. В wp-includes / default-filters.php у нас есть это: ** add_action ('publish_post', '_publish_post_hook', 5, 1); ** Таким образом, publish_post вызывает _publish_post_hook (). _publish_post_hook (), среди прочего, добавляет мета сообщения '_pingme' к сообщению и планирует действие do_pings для одноразового вызова cron, который произойдет при следующей загрузке страницы (потому что он привязан к time () для график). Снова в wp-includes / default-filters.php у нас есть это: ** add_action ('do_pings', 'do_all_pings'); Функция do_all_pings () выполняет все проверки связи для всех сообщений, которые помечены как требующие их выполнения в данный момент. Что касается черновиков, запланированных (будущих) и отредактированных сообщений: черновики сообщений имеют post_status of draft, что означает, что wp_transition_post_status () вызывает do_action () для draft_post, а не для publish_post. Запланированные сообщения имеют post_status of future, что означает, что wp_transition_post_status () вызывает do_action () для future_post, а не для publish_post. Таким образом, ни черновики, ни запланированные публикации не получают эхо-запросы до тех пор, пока они не перейдут на публикацию, поскольку именно тогда будет запущено действие publish_post. Редактирование сообщений: редактирование существующего сообщения отправит пинг для сообщения, но do_all_pings () умен. Он вызывает функцию pingback () для отправки pingback-сообщений в блоги, а это, в свою очередь, вызывает функцию get_pung () для получения URL-адресов в сообщении, которые уже были успешно проверены ранее. Это очень старый код - настолько старый, что список проверенных блогов фактически является основным столбцом (проверяемым) в таблице wp_posts. Почему не нужен плагин Ping Optimizer Итак, рассмотрите еще раз описание плагина: знаете ли вы, что ваш блог WordPress без надобности пингует каждый раз, когда вы редактируете сообщение? Подумайте, сколько раз вы нажимаете кнопку «Сохранить и продолжить редактирование» или «Сохранить». Ваш блог будет без необходимости пинговать, когда вы нажимаете эти кнопки много раз. Защитите свой блог от пометки ping-спамером, установив этот плагин. После установки cbnet Ping Optimizer: когда вы создаете новое сообщение, ваш блог будет пинговать и уведомлять все службы проверки связи, что он был обновлен. Это побуждает поисковые системы и различные каталоги / службы блогов правильно индексировать ваш обновленный блог. Когда вы редактируете существующий пост, он не отправляет ненужный ping в службы ping и спасает ваш блог от блокировки такими службами. Когда вы публикуете будущую публикацию, редактируя метку времени, она будет пинговать только тогда, когда ваша публикация появится в будущем. Когда вы планируете публикации, он не будет бесполезно пинговать много раз, как это делает WordPress по умолчанию. Должно быть очевидно, что большая часть этого больше не соответствует действительности. Подумайте, сколько раз вы нажимаете кнопку «Сохранить и продолжить редактирование» или «Сохранить». Ваш блог будет без необходимости пинговать, когда вы нажимаете эти кнопки много раз. Как вы видите выше, это неправда. Сохранение черновика сообщения не запускает действие publish_post; следовательно, никакие эхо-запросы не запускаются. Когда вы создаете новое сообщение, ваш блог будет проверять связь и уведомлять все службы проверки связи, что он был обновлен. Базовая функциональность WordPress уже делает это. Когда вы редактируете существующий пост, он не отправляет ненужный ping в службы ping и спасает ваш блог от блокировки такими службами. Как вы видите выше, WordPress разумно запускает эхо-запросы при редактировании публикации, отслеживая предыдущие успешные эхо-запросы и не повторяя их. Когда вы публикуете будущую публикацию, редактируя метку времени, она будет пинговать только тогда, когда ваша публикация появится в будущем. Когда вы планируете публикации, он не будет бесполезно пинговать много раз, как это делает WordPress по умолчанию. Как вы видите выше, планирование публикации запускает действие future_post, а не действие publish_post. Таким образом, до тех пор, пока запланированная публикация не перейдет к публикации, тем самым запустив действие publish_post, пинги не запускаются. Таким образом, ни одна из функций этого плагина не нужна. Вы можете безопасно деактивировать и удалить его, понимая, почему основная обработка пингов WordPress работает нормально.

Автор: chipbennett

Версия: 3.0

Последнее обновление: 2012-12-20 1:25pm GMT