Ajax в WordPress
Что такое AJAX?
Как работает AJAX.
Как AJAX работает в WordPress
AJAX в админ-панели WordPress
AJAX во внешней части WordPress
Правильное подключение AJAX хуков
Защита: используем nonce и проверяем права
Отлавливаем баги
Функции AJAX
Пример
Widgets API
Как добавить или удалить виджеты
Базовая структура
Конструктор
widget_init
Метод form()
Метод update()
Метод widget()
Функции Widgets
Dashboard Widgets API
Функция
Действие
Продвинутое использование: принудительное перемещение виджета наверх
Продвинутое использование: удаление виджетов консоли
Продвинутое использование: добавление виджета в боковой столбец
Использование AJAX-обработчика WordPress
Выполнение AJAX запросов в WordPress
Динамический архив блога с использованием jQuery (Ajax)
5 TIPS FOR USING AJAX IN WORDPRESS
Создание виджетов для WordPress
Ajax в WordPress
С помощью AJAX, клиент (т.е. браузер) обменивается данными с веб-сервером и запрашивает данные. Затем он обрабатывает ответ сервера и вносит изменения в страницу без полной ее перезагрузки.
Давайте разберем аббревиатуру AJAX по частям:
«Асинхронный» означает то, что пользователь может перемещаться по страницам после своего запроса к серверу и как только сервер возвращает ответ, соответствующая функция берёт на себя управление по возвращению данных незаметно для пользователя.
«Javascript» это язык, который создает экземпляр запроса AJAX, анализирует соответствующий ответ AJAX, и, наконец, обновляет DOM.
Клиент использует XMLHttpRequest или XHR API для создания запроса к серверу. Идея API (Application Programming Interface) задает методы которые определяют правила соединения между двумя заинтересованными сторонами. Однако, отметим, что входящие данные из AJAX запроса могут быть любого формата, не только xml.
Изображение описывает типичный AJAX сценарий:
Пользователь хочет просмотреть больше информации, поэтому он нажимает на соответствующую кнопку. Это событие вызывает AJAX.
Запрос отправляется на сервер. Вместе с запросом могут быть переданы различные данные. Запрос может указывать на статичный файл (например, example.json), который хранится на сервере. В качестве альтернативы, можно выполнить динамический сценарий (например, functions.php) который указывает, что сценарий говорит базе данных (или другой системе) какие данные нужно извлекать.
База данных возвращает запрашиваемые данные на сервер. Затем сервер отправляет их браузеру.
JavaScript разбирает ответ и обновляет определенные части DOM.
При разработке мощных AJAX приложений мы в состоянии контролировать объем данных, который загружается с сервера.
AJAX уже используется в движке WordPress и готов для работы. Всё, что от Вас требуется – использовать доступные функции Давайте сначала посмотрим на этот процесс в общих чертах, прежде чем погрузиться в код.
Каждый AJAX-запрос проходит через файл admin-ajax.php, который находится в папке wp-admin. Пусть название файла Вас не сбивает с толку.
Каждый запрос должен передавать (используя метод GET или POST) информацию о выполняемом действии. Исходя из этого действия, код в файле admin-ajax.php создает два хука, wp_ajax_my_action и wp_ajax_nopriv_my_action, где my_action – переменная GET или POST, в которой хранится информация о действии.
Первый хук предназначен для авторизованных пользователей, а второй для неавторизованных.
add_action(‘wp_ajax_(action)’, ‘my_action_callback’);
add_action(‘wp_ajax_nopriv_(action)’, ‘my_action_callback’);
С тех пор, как AJAX был встроен в админ-панель WP, использовать функционал AJAX в плагинах стало очень удобно. Небольшой пример. Все делается в одном файле (файле плагина или файле темы functions.php).
Добавляем javascript. AJAX в админ-панели WordPress
Сначала добавляем на страницу админки javascript код, который будет посылать AJAX запрос.
//add_action(‘admin_print_scripts’, ‘my_action_javascript’); // такое подключение будет работать не всегда add_action(‘admin_print_footer_scripts’, ‘my_action_javascript’, 99);
function my_action_javascript()
{
<script type=«text/javascript» >
jQuery(document).ready(function($) { var data = { action: ‘my_action’, whatever: 1234 };
jQuery.post( ajaxurl, data, function(response) { alert(‘Получено с сервера: ‘ + response); }); });
</script> }
С версии 2.8 javascript переменная ajaxurl определена глобально на всех страницах админки. Используйте её в js коде, как ссылку на файл обработчик AJAX запроса. Обычно это файл /wp-admin/admin-ajax.php. В теме (шаблоне) эта переменная не определена. Чтобы использовать её во фронт-энде, её нужно определить самостоятельно.
Создаем PHP функцию.
Теперь, создадим PHP функцию, которая будет обрабатывать переданный AJAX запрос. Для этого добавляем следующий код в functions.php (можно в плагин):
<?php
add_action(‘wp_ajax_my_action’, ‘my_action_callback’);
function my_action_callback() {
$whatever = intval( $_POST[‘whatever’] );
$whatever += 10;
echo $whatever;
wp_die(); // выход нужен для того, чтобы в ответе не было ничего лишнего, только то что возвращает функция
}
Тут мы цепляемся на хук wp_ajax_my_action — это динамический хук и выглядит он так: wp_ajax_(action), где вместо (action) вставляется значение передаваемой в первом коде переменной action — my_action.
По возможности всегда используйте wp_die() вместо die() или exit(), в вашей функции обработки AJAX запроса. Так вы добьетесь лучшей интеграции с WordPress и в случае ошибок в коде, получите данные о них.
Вот и все, за исключением одной детали: проверка запроса, что он пришел с правильной страницы. Для такой проверки используется функция check_ajax_referer().
Примера выше будет достаточно, чтобы начать использовать AJAX в админ-панели WordPress.
AJAX во внешней части WordPress
Первое в чем нужно проверить — установлена ли на сайте библиотека jQuery.
Во фронт-энде (внешней части сайта) нужно использовать еще один хук для обработки AJAX запросов: wp_ajax_nopriv_(action). Этот хук в отличии от wp_ajax_(action), срабатывает для неавторизованных пользователей.
Т.е. чтобы создать обработчик запроса для всех пользователей: авторизованных и нет, PHP функцию нужно прикреплять сразу к двум хукам:
add_action(‘wp_ajax_(action)’, ‘my_action_callback’);
add_action(‘wp_ajax_nopriv_(action)’, ‘my_action_callback’);
‘wp_ajax_nopriv_(action)’ можно не указывать если не нужно, чтобы AJAX запрос обрабатывался для неавторизованных пользователей.
Переменная ajaxurl есть только в админке и её нет в лицевой части сайта (фронт-энде), поэтому её нужно определить (создать). Но мы назовем её по-другому — myajax.url, для фронта так удобнее, потому что так в объект myajax можно будет добавить еще данные связанные с AJAX запросом.
Правильный способ создать такую переменную — это использовать функцию wp_localize_script().
// Подключаем локализацию в самом конце подключаемых к выводу скриптов, чтобы //скрипт.
// ‘twentyfifteen-script’, к которому мы подключаемся, точно был добавлен в очередь //на вывод.
// Заметка: код можно вставить в любое место functions.php темы.
add_action( ‘wp_enqueue_scripts’, ‘myajax_data’, 99 );
function myajax_data(){
// Первый параметр ‘twentyfifteen-script’ означает, что код будет прикреплен к //скрипту с ID ‘twentyfifteen-script’.
// ‘twentyfifteen-script’ должен быть добавлен в очередь на вывод, иначе WP не //поймет куда вставлять код локализации.
// Заметка: обычно этот код нужно добавлять в functions.php в том месте где //подключаются скрипты, после указанного скрипта.
wp_localize_script(‘twentyfifteen-script’, ‘myajax’, array(‘url’ => admin_url(‘admin-ajax.php’))); }
В результате, получим в head части сайта прямо перед скриптом ‘twentyfifteen-script’:
<script type=’text/javascript’>
/* <![CDATA[ */
var myajax = {«url»:»http://wptest.ru/wp-admin/admin-ajax.php»};
/* ]]> */
</script>
<script type=’text/javascript’ src=’http://wptest.ru/wp-content/themes/twentyfifteen/js/functions.js?ver=20150330′></script>
На этом теория AJAX закончена, теперь все как для админ части, только вместо ajaxurl указываем myajax.url и нужно прикрепить функцию обработчик на еще один хук wp_ajax_nopriv_(action).
Пример AJAX кода для фронтенда.
<?php
add_action( ‘wp_enqueue_scripts’, ‘myajax_data‘, 99 );
function myajax_data(){
wp_localize_script(‘twentyfifteen-script’, ‘myajax’,
array( ‘url’ => admin_url(‘admin-ajax.php‘))); }
add_action(‘wp_footer’, ‘my_action_javascript‘, 99); // для фронта
function my_action_javascript() {
?>
<script type=»text/javascript» >
jQuery(document).ready(function($) {
var data = {
action: ‘my_action’,
whatever: 1234};
// ‘ajaxurl’ не определена во фронте, поэтому мы добавили её аналог с //помощью wp_localize_script()
jQuery.post( myajax.url, data, function(response) {
alert(‘Получено с сервера: ‘ + response);});
});
</script>
<?php }
add_action(‘wp_ajax_my_action’, ‘my_action_callback‘);
add_action(‘wp_ajax_nopriv_my_action’, ‘my_action_callback‘);
function my_action_callback() {
$whatever = intval( $_POST[‘whatever’] );
echo $whatever + 10;
// выход нужен для того, чтобы в ответе не было ничего лишнего, кроме того, что возвращает функция
wp_die();
}
Код рассчитан на тему twentyfifteen. Вставлять код можно в functions.php темы.
Этот код будет работать для любой темы, единственное что для этого нужно — это поменять название основного скрипта темы twentyfifteen-script, который подключается после jquery.
Правильное подключение AJAX хуков
Функции обработчики установленные хукам: wp_ajax_(action) и wp_ajax_nopriv_(action) всегда удовлетворяют условиям: if( is_admin() ) или if( defined(‘DOING_AJAX’) && DOING_AJAX ). А значит сами хуки нужно подключать только если срабатывает одно из этих условий или сразу оба.
Используя это правило, можно не подключать хуки там где в этом нет смысла. Например, при генерации страницы шаблона или страницы админки. Эта маленькая деталь — позволит чуточку сэкономить на производительности, добавит больше логики в код и некоторых случаях избавит от багов.
Пример того, как рекомендуется подключать все AJAX хуки:
// подключаем AJAX обработчики, только когда в этом есть смысл
if( defined(‘DOING_AJAX’) && DOING_AJAX ){
add_action(‘wp_ajax_myaction’, ‘ajax_handler’);
add_action(‘wp_ajax_nopriv_myaction’, ‘ajax_handler’);
}
// или так
if( is_admin() ){
add_action(‘wp_ajax_myaction’, ‘ajax_handler’);
add_action(‘wp_ajax_nopriv_myaction’, ‘ajax_handler’);
}
// или так с WP 4.7
if( wp_doing_ajax() ){
add_action(‘wp_ajax_myaction’, ‘ajax_handler’);
add_action(‘wp_ajax_nopriv_myaction’, ‘ajax_handler’);
}
В обоих случаях данные отправляемые с фронтенда на файл wp-admin/admin-ajax.php обрабатываются функцией ajax_handler, независимо авторизован пользователь или нет.
Защита: используем nonce и проверяем права
Нет острой необходимости проверять каждых AJAX запрос и разработчики часто игнорируют такую проверку, получая самый неожиданный результат. Недобросовестные пользователи могут каким-либо образом изменить свои права и навредить сайту над которым вы работали долгие месяцы.
Существует 2 вида защиты, которые нужно использовать в AJAX запросах в большинстве случаев.
nonce (случайный код).
Nonce — это уникальная строка, которая создается и используется один раз (once). Nonce проверка используется, когда нужно убедится, что запрос был послан с указанного места.
В WordPress есть функции wp_create_nonce() и wp_verify_nonce() — это базовые функции для создания и последующей проверки nonce кода. С их помощью мы и будем создавать защиту nonce для AJAX запросов.
Для начала создадим nonce код:
add_action( ‘wp_enqueue_scripts’, ‘myajax_data’, 99 );
function myajax_data(){
wp_localize_script(‘twentyfifteen-script’, ‘myajax’,
array( ‘url’ => admin_url(‘admin-ajax.php’), ‘nonce’ => wp_create_nonce(‘myajax-nonce’))
); }
Здесь ‘twentyfifteen-script’ это название основного скрипта темы (см. выше), который подключается на сайте с помощью wp_enqueue_script().
Затем, в AJAX запросе добавим переменную с кодом nonce:
var ajaxdata = { action : ‘myajax-submit’, nonce : myajax.nonce };
jQuery.post( myajax.url, ajaxdata, function( response ) { alert( response ); });
Теперь, в обработке заброса необходимо проверить nonce код:
add_action( ‘wp_ajax_nopriv_myajax-submit’, ‘myajax_submit’ );
add_action( ‘wp_ajax_myajax-submit’, ‘myajax_submit’ );
function myajax_submit(){
$nonce = $_POST[‘nonce’];
// проверяем nonce код, если проверка не пройдена прерываем обработку
if( ! wp_verify_nonce( $nonce, ‘myajax-nonce’ ) )
die( ‘Stop!’);
// обрабатываем данные и возвращаем
echo ‘Возвращаемые данные’;
// Не забываем завершать PHP
die(); }
Проверка прав доступа
Тут AJAX запросы будут срабатывать только для пользователей с правом author. Для всех остальных включая неавторизованных пользователей, AJAX запрос вернет ошибку.
Особенность тут в том, что неавторизованные пользователи тоже должны видеть сообщение об ошибке при AJAX запросе. Для этого нужно обрабатывать запрос для них возвратом ошибки:
add_action( ‘wp_ajax_nopriv_myajax-submit’, ‘myajax_submit‘ );
add_action( ‘wp_ajax_myajax-submit’, ‘myajax_submit‘ );
function myajax_submit(){
$nonce = $_POST[‘nonce’];
// проверяем nonce код, если проверка не пройдена прерываем обработку
if ( ! wp_verify_nonce( $nonce, ‘myajax-nonce’ ) )
die(‘Nonce error’)
// текущий пользователь имеет права автора или выше
if( ! current_user_can(‘publish_posts’) )
die(‘Этот запрос доступен пользователям с правом автора или выше.’)
// Делаем что нужно и выводим данные на экран, чтобы вернуть их скрипту
// Не забываем выходить
die; }
Отлавливаем баги
Проблемы могут возникнуть при AJAX запросе и появлении ошибок PHP. Заметки или сообщения могут изменить возвращаемый результат или вызвать ошибку javascript.
Дебаг (вывод ошибок на экран).
Вариант: Как правило запросы отправляются с браузера в файл. Поэтому чтобы увидеть результат запроса, ошибку или что-либо еще, можно открыть панель разработчика, выбрать именно наш запрос среди многих и посмотреть что он вернул:
При этом в коде можно использовать привычные функции print_r() или var_dump(), чтобы увидеть что находится в нужных переменных.
Если по ходу написания кода нужно заглянуть в переменную $myvar, то еще можно использовать такой код в обработчике ajax запроса:
error_log( print_r($myvar, true) );
В результате, в файл логов сервера (error.log) будет записано содержимое переменной $myvar. Так можно выполнить ajax, и заглянуть в лог.
Если не получается увидеть сообщение об ошибке и нужно работать в режиме разработчика, можно очистить буфер сразу перед возвратом данных:
ob_clean();
echo $whatever;
die();
После этого нужно посмотреть что возвращает запрос через дебаг браузера или как-то еще…
Также, для дебага можно воспользоваться инструментом FirePHP, который записывает ошибки в консоль браузера.
Если AJAX запрос на в файл wp-admin/admin-ajax.php провалился, то будет возвращен ответ -1 (не указан параметр action) или 0 (обработка запроса вернула пустой результат). 0 также возвращается по умолчанию во всех остальных случаях.
Функции AJAX
check_ajax_referer() — проверяет Ajax запрос, не пускает внешние запросы (не со страниц сайта).
wp_doing_ajax() — проверяет является ли текущий запрос AJAX запросом WordPress.
wp_send_json_error() — возвращает JSON данные. Используется для возврата ошибок в AJAX запросах. Ответ будет всегда содержать элемент success=false по которому выявляется ошибка при обработке AJAX ответа.
wp_send_json_success() — возвращает JSON данные. Используется для возврата успешных ответов в AJAX запросах. Ответ будет всегда содержать элемент success=true, по которому определяется успешная обработка AJAX запроса.
check_ajax_referer() — проверяет Ajax запрос, не пускает внешние запросы (не со страниц сайта).
Функция check_ajax_referer() может быть переопределена плагинами
Если $query_arg не указан (по дефолту false), то функция подразумевает что nonce код находится в переменных $_REQUEST[‘_ajax_nonce’] или $_REQUEST[‘_wpnonce’]
Если $die установлено в true, выполнение скрипта будет прервано, при неудачной проверке nonce и функция выведет на экран ‘-1’
Хуки из функции check_ajax_referer, возвращает true или false, если аргумент $die установлен в false.
<?php
// установим Nonce
$ajax_nonce = wp_create_nonce(«my-special-string»);
?>
<script type=»text/javascript»>
jQuery(document).ready(function($){
var data = {
action: ‘my_action’,
security: ‘<?php echo $ajax_nonce; ?>’,
my_string: ‘Hello World!’};
$.post(ajaxurl, data, function(response) {
alert(«Response: » + response);
}); });
</script>
Затем, проверяем nonce строку при обработке Ajax запроса:
add_action( ‘wp_ajax_my_action’, ‘my_action_function’ );
function my_action_function() {
check_ajax_referer( ‘my-special-string’, ‘security’ );
echo $_POST[‘my_string’];
die; } // Мы создали nonce строку с идентификатором my-special-string и при обработке её проверили
wp_send_json_success() — возвращает JSON данные и используется для возврата успешных ответов в AJAX запросах, ответ будет всегда содержать элемент success=true, по которому определяется успешная обработка AJAX запроса.
Если в параметр $data передать данные, то они будут добавлены:
// вид возвращаемых данных, перед кодированием в JSON
$response = array( ‘success’ => true ); // если $data не указан
$response = array( ‘success’ => true, ‘data’ => $data ); // если $data указан
wp_send_json_error() — аналогичная функция, только используется для возврата ошибок, а не успешных ответов.
Работает на основе: wp_send_json(), хуков нет.
wp_send_json_success() выводит на экран JSON данные и обрывает работу php.
wp_send_json_success( $data, $status_code );
$data(строка/массив/число/объект/логический) данные, которые будут добавлены в результат в элемент массива data, перед кодирование в JSON. По умолчанию: нет
$status_code(число) HTTP статус код, который нужно установить. Какие бывают статус коды, смотрите здесь. C WP 4.7.
По умолчанию: null
Определение успешной обработки AJAX запроса
Этот jQuery код отправляет AJAX запрос на страницу плагина ‘ajax/save_field.php’:
jQuery(document).ready(function(){
jQuery(‘#btn_save’).click(function(e){
e.preventDefault();
jQuery.post( pluginUrl+’ajax/save_field.php’,jQuery(‘#my-form’).serialize(), function( data ){
if( data.success )
alert( data.data );
else
alert( ‘Ошибка’ + data.data );
}); }); });
Это код файла save_field.php, который обрабатывает переданный запрос. Здесь показано, как использовать wp_send_json_success():
<?php
// загрузка среды WP
$return = array(
‘message’ => ‘Сохранено’,
‘ID’ => 1 );
wp_send_json_success( $return );
Пример
Для примера работы AJAX сделаем форму для добавления в гостевую книгу данных без перезагрузки страницы. Форма будет вставляться через шорткод. Чтобы создать шорткод создадим класс контролер шорткода который будет отвечать за работу шорткода. Класс контроллера будет наследовать базовый класс для создания шорткодов.
Добавляем шорткод [step_by_step_guest_book]
namespace includes\controllers\site\shortcodes;
// Наследуем базовый класс StepByStepShortcodesController в котором реализован некоторый функционал для создания
// шорткода
Перейдем на страницу записи у нас появиться форма для добавления она пока что ничего не делает
Создадим класс ответственный за обработку ajax StepByStepGuestBookAjaxHandler.
Подключаем ajax обработчик в методе all класса StepByStepLoader.
StepByStepGuestBookAjaxHandler::newInstance();
Нам нужно для шорткода гостевой книги подключить javascript файл который будет посылать ajax запросы. Для этого создаем файл assets/site/js/StepByStepMain.js и подключим его в загрузчике скриптов StepByStepLoaderScript в методе loadScriptSite.
Переменная ajaxurl есть только в админке и её нет в лицевой части сайта (фронт-энде), поэтому её нужно определить (создать).
В файле StepByStepMain.js будем отслеживать нажатие на кнопку Add и будет отправлять данные через ajax.
Widgets API
Виджеты wordpress – это независимые блоки содержимого,которые можно разместить в боковых колонках, или в специальных областях предусмотренных шаблоном wordpress.
По сути виджеты можно добавлять куда угодно на страницах сайта, но это зависит от темы WordPress, которую вы используете, точнее от количества зарегистрированных в ней сайдбаров. Есть темы, которые и вовсе не поддерживают виджеты.
Создавать виджет WordPress – это примерно, как создавать плагин, но гораздо проще и понятнее. Все, что вам нужно, это один файл со всем PHP кодом, который писать гораздо проще, чем плагин, у которого несколько файлов.
В WordPress есть класс WP_Widget, который предоставляет доступ к API виджетов. Когда вы наследуете этот класс, ваш виджет будет доступен для любого сайдбара, который поддерживает ваша тема. В комплекте WordPress уже есть некоторые виджеты, например «Свежие записи» или «Архив», они тоже наследуют класс WP_Widget.
Класс WP_Widget содержит четыре метода, которые должны быть перегружены:
__construct() — вызывает родительский конструктор и инициализирует виджет
form() — выводит форму для настройки виджета
update() — обновление настроек виджета, которые были указаны в форме администратором
widget() — отображение виджета на сайте
Конструктор ничем не отличается от тех, что вы обычно пишете. Главное, что нужно сделать — это вызвать родительский конструктор, который принимает три аргумента: идентификатор виджета, название виджета (это имя будет показано на странице виджетов) и массив с другими деталями виджета (нужно только «description»): StepByStepGuestBookWidget.
widget_init
Теперь нужно зарегистрировать виджет. Для этого используется функция register_widget(), которая в качестве аргумента принимает имя класса вашего виджета. Эта функция должна быть вызвана в определенное время, поэтому нам нужно использовать систему хуков в WordPress. Нужный нам хук называется «widgets_init». Для связи регистрации виджета с хуком будем использовать функцию add_action(), у которой два аргумента: первый — имя хука, второй — имя функции, которую надо выполнить (вторым аргументом может быть строка или замыкание). Этот код должен быть расположен в основном файле плагина step-by-step-development-plugin.php
add_action(‘widgets_init’, create_function(», ‘return register_widget(«includes\widgets\StepByStepGuestBookWidget»);’));
Теперь, когда ваш плагин зарегистрирован и инициализирован, вы можете увидеть его на странице виджетов.
Метод form()
Виджет, который мы делаем должен давать возможность вводить заголовок и немного текста для отображения на страницах сайта. Исходя из этого нам надо создать форму для ввода этих значений. Метод form() используется для отображения настроек виджета на странице виджетов. У метода один аргумент — $instance — массив переменных, связанных с виджетом. Когда форма отправится на сервер, будет вызван метод update() и мы сможем обновить переменные в массиве $instance. После, метод widget() будет использовать этот массив для отображения виджета.
Методы get_field_id() и get_field_name() класса WP_Widget используются для генерации уникальных имен и идентификаторов для полей вашего плагина. Использование этих методов позволяет избежать конфликтов.
Внешний вид формы виджета на странице виджетов: родительский элемент <form>, кнопки «удалить», «закрыть» и «Сохранить» WrodPress генерирует автоматически, что сильно упрощает нам жизнь, эта форма отправит введенные значения на сервер и вызовет метод update(), что бы мы смогли сохранить их.
Этот метод дает вам возможность проверить и обработать переданные значения перед использованием. Также у нас есть возможность принимать решения исходя из старых значений. Метод update() должен возвращать массив, содержащий переменные, которые вы собираетесь использовать для отображения виджета на сайте. WordPress передает два аргумента: массив новых значений и массив оригинальных значений.
public function update($newInstance, $oldInstance) {
$values = array();
$values[«title»] = htmlentities($newInstance[«title»]);
$values[«text»] = htmlentities($newInstance[«text»]);
return $values; }
WordPress сохранит эти значения самостоятельно, об этом можно не беспокоиться.
Этот метод используется для отображения виджета непосредственно в сайдбаре на сайте. У метода два аргумента: $args — аргументы виджета (массив, содержащий некоторую информацию о виджете), $instance — массив со связанными с виджетом переменными. В нашем случае $args не имеет значения.
Dashboard Widgets API
Главным инструментом, необходимым для добавления виджетов на консоль, является функция wp_add_dashboard_widget(). Вы можете найти исчерпывающее описание этой функции по ссылке выше, или же прочитать краткое описание ниже.
Добавляет виджет (метабокс) в консоль (основная страница админ-панели).
Функция должна вызываться во время события wp_dashboard_setup.
Работает на основе add_meta_box(), хуков нет, ничего не возвращает, а добавляет метабокс.
wp_add_dashboard_widget( $widget_id, $widget_name, $callback, $control_callback,
$callback_args );
$widget_id(строка) (обязательный) идентификатор виджета, будет использован в CSS классе блока виджета, станет ключом виджета в массиве виджетов.
$widget_name(строка) (обязательный) название виджета, будет видно в верхней части виджета, пр.: «Последние комментарии».
$callback(строка) (обязательный) название PHP функции, которая будет выводить на экран содержание виджета.
$control_callback(строка) название функции которая будет обрабатывать запрос редактирования виджета, в этой функции нужно сохранять настройки виджета а также выводить форму настроек, по умолчанию: null.
$callback_args(массив) (обязательный) аргументы, которые будут переданы в функцию обратного вызова. callback функция получит объект $post и другие параметры переданные через эту переменную, по умолчанию: null.
Пример
Добавление виджета в консоль
Это демонстративный пример добавления виджета на страницу админ-панели:
StepByStepGuestBookDashboardWidget.php
Для запуска функции вам необходимо подключиться к действию ‘wp_dashboard_setup’ через функцию add_action().
Продвинутое использование: принудительное перемещение виджета наверх
Как правило, вы должны просто позволить пользователям вашего плагина разместить ваш виджет где они хотят путём перетаскивания. В настоящее время в API нет лёгкого способа предварительной сортировки виджетов по умолчанию, что означает, что ваш новый виджет всегда будет находиться внизу списка. Пока функция сортировки не добавлена в API, обойти эту проблему непросто.
Ниже приведён пример подключаемой функции, которая пытается поместить ваш виджет перед уже существующими. Она делает это, вручную изменяя внутренний массив метабоксов (в котором виджеты консоли являются одним из типов) и помещает ваш виджет наверх списка, так что он будет показываться первым.
Продвинутое использование: удаление виджетов консоли
В некоторых случаях, особенно на многопользовательских блогах, может быть полезно полностью удалить виджеты из интерфейса. Каждый пользователь может, по умолчанию, выключить любой виджет используя вкладку «Параметры экрана» в верхней части страницы, но если у вас есть много неопытных пользователей, для них может быть проще вообще не видеть виджетов.
Для удаления виджетов консоли, используйте функцию remove_meta_box(). Смотрите пример кода ниже для понимания того, какие параметры ей следует передать.
Вот имена виджетов по умолчанию в консоли:
// Главный столбец (левый):
$wp_meta_boxes[‘dashboard’][‘normal’][‘high’][‘dashboard_browser_nag’]
$wp_meta_boxes[‘dashboard’][‘normal’][‘core’][‘dashboard_right_now’]
$wp_meta_boxes[‘dashboard’][‘normal’][‘core’][‘dashboard_activity’]
// Боковой столбец (правый):
$wp_meta_boxes[‘dashboard’][‘side’][‘core’][‘dashboard_quick_press’]
$wp_meta_boxes[‘dashboard’][‘side’][‘core’][‘dashboard_primary’]
Продвинутое использование: добавление виджета в боковой столбец
Функция не позволяет вам выбирать, где вы хотите расместить ваш виджет и автоматически добавляет его в «core«, которое находится с левой стороны. Однако, вы можете очень просто поместить его на правую сторону.
Вы можете использовать функцию add_meta_box() вместо функции wp_add_dashboard_widget. Просто определите фактический параметр функции $post_type как ‘dashboard’. Например:
add_meta_box(‘id’, ‘Заголовок виджета консоли’, ‘dash_widget’, ‘dashboard’, ‘side’, ‘high’);
add_meta_box(
‘step_by_step_guest_book_dashboard_widget_new’,
__(‘Guest book new’, STEPBYSTEP_PlUGIN_TEXTDOMAIN),
array( &$this, ‘renderDashboardWidget’ ),
‘dashboard’,
‘side’,
‘high’ );
пример реализации шорткода:


admin
Подключил виджеты взаимодействующие с базой данных:
— в сабменю контроллера
— в боковой панели футера
— на фронте посредством шорткода
Получил от сервера AJAX response