Creating admin pages wordpress

How To Create WordPress Custom Admin Pages

WordPress, the world’s most popular CMS is also quite beloved by developers. Among many of its possible customizations and flexibilities that can be pointed out is extending the admin side of WordPress. In this post, we will show you how to use WordPress custom admin pages to bring more options for the user.

What is WordPress Custom Admin Pages?

The WordPress admin dashboard is the first page you’ll see after logging in. Using the side menu, you can navigate to other admin pages like Appearance, Plugins, Settings, Users, etc.

You may also see new menu items after activating a theme or a plugin that redirects you to a new admin page. It can be a settings page for the plugin, control panel of your theme, a page to show the status of your site or even a document page. The custom admin page is a very helpful feature which allows the developer to extend admin rights with new options.

How to Add WordPress custom Admin Pages

In order to add a custom admin page in WordPress, we need 2 things:

1. An admin menu (add_menu_page function)
2. Page content (custom function)

In order to add a new admin menu item, we can use the following function:

Let’s dive into each item to learn what they are.

1. $page_title The text to be displayed in the title tags of the page when the menu is selected. Choose a meaningful page title. For example, if your custom admin page is an options page for the plugin, it could be “My plugin options”. Note that it should be translatable. So use _ function like the following example: _( ‘My Plugin Options’, ‘my-plugin-textdomain‘)

2. $menu_title The text to be used for the menu.

3. $capability The capability required for this menu to be displayed to the user. For example, if it contains some general options for the site, manage_option could be the best choice. Just set it carefully to avoid any possible security issue.

Check out the WordPress Roles and Capabilities page and see what the proper capability is for your custom admin page.

4. $menu_slug The slug name that refers to this menu. It should be unique for this menu page and only include lowercase alphanumeric, dashes, and underscores to be compatible with sanitize_key(). This will be used as a parameter in the URL of your custom admin page as it’s shown in the picture.

5. $function The function to be called to show the output content for this page. For a simple example, we can use the following code to show a header in the admin page:

6. $icon_url The URL of the icon to be used for this menu. You can use an image, encoded SVG, or dash icons.

• In order to use an image, simply pass the URL of the image.
• If you want to have an icon like WordPress defaults, which has a different color on hover, you can pass an encoded SVG file. The http://b64.io/ can convert your SVG file to base64 encoded data. After uploading your SVG, simply copy the link that starts with data:image/svg+xml;base64, and paste it.
• You can use existing WordPress icons. Find a proper icon from WordPress Dashicons page and pass the class name like dashicons-schedule as icon URL argument.
• Also, you can use none value to leave div.wp-menu-image empty, so an icon can be added via CSS.

7. $position The position in the menu order should appear. Here is the list of numbers of default admin menus:

• 2 – Dashboard
• 4 – Separator
• 5 – Posts
• 10 – Media
• 15 – Links
• 20 – Pages
• 25 – Comments
• 59 – Separator
• 60 – Appearance
• 65 – Plugins
• 70 – Users
• 75 – Tools
• 80 – Settings
• 99 – Separator

So, if you want to show your menu after Dashboard, you should use 3.

In the following table, you can see a piece of brief information about each item.

Add_menu_page arguments

Putting it all together, you’ll have:

You should know that it is possible to add a submenu to existing menus or newly added menu using the following functions:

• add_posts_page Adds a submenu under Posts menu
• add_pages_page Adds a submenu under Pages menu
• add_media_page Adds a submenu under Media menu
• add_comments_page Adds a submenu under Comments menu
• add_theme_page Adds a submenu under the Appearance menu
• add_plugin_page Adds a submenu under Plugins menu
• add_users_page Adds a submenu under Users menu
• add_management_page Adds a submenu under Tools menu
• add_options_page Adds a submenu under Settings menu

And all of them are a wrapper of add_submenu_page function, so we use them in the same way:

And that’s it. We have a custom admin page. But, what about adding custom styles and scripts for its content?

Adding Styles and Scripts to WordPress Custom Admin Pages

Let’s see how we can put styles after adding page content:

The above code will load admin-styles.css file only in the mypluginname page. If you wonder why we should do this, the reason is that loading styles in all admin pages can cause unwanted changes in other admin pages. For example, you don’t want to change the size of texts in the dashboard.

If you’re unsure what your $hook name is, use this to determine your hook name. And then, change it to the code below.

Note: Don’t use wp_die while you’re editing a file from the plugin editor. It can cause you to lose access to the admin page until you remove it.

You can also use default registered styles in WordPress, like this:

In the above code, we are not specifying any URL for the style file because it has already been registered once, and WordPress knows it. By registering a style file, you introduce it to WordPress without loading it. And then, you can load it by using a style handler name anywhere in the code. Have a look at the following code:

There are a lot of JavaScript libraries included in WordPress that you can use. There is also a list of default scripts included and registered by WordPress here.

Wrapping It Up in a Plugin

In this section, we put all codes in a single file, which you can install as a plugin to add new WordPress custom admin pages.

And the final result will be like this:

In the next post, we will show you how to add custom settings to WordPress Custom Admin Pages, how to process forms, and how to make them secure.

Источник

Создание пользовательских страниц в админке WordPress, Часть 3

Russian (Pусский) translation by Ellen Nelson (you can also view the original English article)

В этой серии мы рассмотрели способы создания пользовательских страниц в админке WordPress без использования API Настроек. Это не означает, что API Настроек бесполезен (потому что так и есть!), но может оказаться полезен, когда нам нужно внести пользовательскую функциональность или фишку, которая не предусмотрена в API.

Кроме того, мы рассматриваем некоторые из наиболее важных принципов разработки программного обеспечения, таких как единый принцип ответственности, и применяем его в нашей работе.

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

Краткий обзор

Хотя я не могу суммировать все, что мы уже рассмотрели в серии, я уверен, что я выделил важные моменты.

• Мы создали основу плагина и добавили пункт подменю и параметры страницы для плагина в Панели WordPress.
• Мы обсудили единый принцип ответственности и его роль в разработке.
• Мы добавили поле input для пользовательского ввода данных.
• Мы добавили значение элемента на странице, но посути мы еще не сделали с ним ничего.

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

Прежде чем мы начнем

Как и в других статьях, я полагаю, что WordPress установлен на вашей локальной машине.

Кроме того я предполагаю, что у вас последняя версия исходного кода и вы готовы продолжать разработку или вы легко читаете код, который здесь предоставлен и понимаете как он работает.

И наконец, мы постепенно пройдём через каждый кусок кода. Во-первых, я расскажу о том, что мы будем делать, затем я покажу код и объясню для чего он, так что не останется ничего, что могло бы вас запутать.

Если, однако, вы запутаетесь в коде и этот урок недостаточно хорошо объясняет что мы делаем, пожалуйста, оставьте комментарий и я помогу вам разобраться.

Реализация новых возможностей

В предыдущей статье мы закончили на том, что у нас получился плагин, который выглядит так, будто он что-то делает, но на самом деле он не сохраняет ничего в базу данных, не говоря уже о получении данных из базы.

Короче говоря у нас есть плагин, который выглядит рабочим, но это не так. И вот о чем будет этот урок.

В частности мы разберём следующие темы:

• Мы проверим значение nonce, которое мы создали и определили в предыдущем уроке, чтобы получить представление о том, как работает один из компонентов безопасности WordPress.
• Мы проверим, что существующий пользователь имеет разрешения на отправку информации (и предотвратим отправку, если разрешения нет).
• Если отправка данных безопасна и у пользователя есть разрешение, мы пропустим информацию через функцию очистки, чтобы убедиться, что вредоносное содержимое не попадет в базу данных

Это наш план и мы готовы вернуться к коду и продолжить работу над плагином.

Безопасность

Напомню, в предыдущем посте мы использовали функцию из API WordPress — wp_nonce_field . Эта конкретная функция выполняет следующие действия:

Поле nonce используется для проверки того, что содержимое формы запроса пришли от текущего сайта, а не откуда-то ещё. Nonce не гарантирует стопроцентной защиты, но должна защитить в большинстве случаев. Очень важно использовать поле nonce в формах.

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

Нам нужно ввести функцию, которая будет цепляться за один из доступных хуков WordPress и проверит, допустимо ли значение nonce. Если значение верно, то информация сохранится; в противном случае этого не произойдёт.

Поскольку мы находимся в бизнесе создания пользовательских страниц администрирования, нам понадобится другой хук, чем тот, что мы можем использовать в подобных ситуациях. В этом примере мы будем использовать хук admin_post .

Срабатывает при размещении запроса от администратора, когда никакие действия не ожидаются.

Напомню из предыдущих рассуждений, что мы не хотим перегружать наши классы большей ответственностью, чем требуется. Помните, что мы должны постоянно задавать себе вопрос: «По какой причине должен изменяться этот класс?»

Сейчас, у нас нет класса, который может управлять сохранением параметров. Поэтому введем его. В каталоге «admin» нашего плагина создадим класс Serializer . Он будет отвечать за сохранение значений наших опций.

Как вы видите, я назвал мой файл class-serializer.php . По опыту и из кода выше мы знаем, что нам нужeн хук admin_post , упомянутый выше, а также нам нужна функция отвечающяя за сохранение информации.

Давайте определим их.

Очевидно, это еще предстоит сделать (на самом деле, мы даже не создали этот класс!) но приведенного выше кода достаточно, чтобы увидеть куда мы движемся.

Быстро обсудим зависимости

Прежде чем добавлять какую-либо функциональность, давайте пройдем вперед и сначала настроим подгрузку нашего плагина. Для начала вернем custom-admin-settings.php . Теперь, мы должны спросить себя, должны ли какие-нибудь из наших существующих классов иметь как зависимость от Serializer.

Я думаю в нашем случае, Submenu_Page должен ссылаться на функцию очистки, поскольку страница содержит параметры для сохранения.

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

Так что давайте, добавим экземпляр класса Serializer , инициализируем его и затем передадим его в конструктор страницы подменю. Код в файле загрузки плагина теперь должен выглядеть следующим образом:

С этим мы готовы продолжать работу над сохранением наших параметров.

Вернёмся к разработке

Давайте вернёмся к Serializer . Теперь, когда мы прикрутили это к нашему плагину, пришло время написать немного кода, поэтому, следуя комментарию, давайте проверим значение nonce, которое мы создали.

К счастью, в WordPress это сделать легко через встроенную функцию API: wp_verify_nonce . Эта функция принимает два аргумента:

Если вы помните из предыдущей статьи, мы использовали acme-settings-save как наше действие и acme-custom-message как наше nonce значение. Чтобы проверить валидность, нам нужно проверить наличие его в коллекции $_POST и что оно проходит родную проверку кода в WordPress.

Для этого я создам метод private , который позволит мне заключить это действие в функцию, которую можно использовать в функции save , которую мы определили выше.

После этого, я могу включить вызов функции, которая позволит нам проверить правильность введённых данных и либо остановит процесс, либо перейдёт к следующей проверке (которая будет выполнена однократно).

Заметьте, что в данном случае просто вернуть false не является лучшим вариантом. Вместо этого, лучше настроить сообщение об ошибке, которая будет отображаться в панели WordPress. Это то, над чем мы будем работать в следущем уроке.

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

Разрешение

Несмотря на то, что число (nonce), использованное один раз, проверено, есть еще одна вещь, нам нужно проверить: нам нужно убедиться, что у текущего пользователя есть разрешение на сохранение данных.

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

Обратите внимание, что одна из возможностей администратор является управление параметрами. Теперь мы можем использовать функцию API WordPress current_user_can для проверки, может ли текущий пользователь сохранять параметры на этой странице.

Во-первых, это поднимает вопрос: если пользователь не может сохранить параметры, почему он вообще имеет доступ к этой странице?

Если вы помните, ранее в этой серии, мы написали следующий кусок кода:

Это гарантирует, что страница параметров доступна только для администраторов; однако мы хотим быть осторожны и проверяем это также во время процесса прочистки (serialization).

Теперь мы можем обновить условие, где мы проверяем значение nonce, чтобы проверить разрешения текущего пользователя:

Теперь, когда у нас есть код, которым мы проверяем, что значение nonce установлено и что текущий пользователь может сохранять значение, мы можем двигаться дальше и выполнить очистку.

Помните, мы вернемся к месту, где говорится, что нам нужно отобразить сообщение об ошибке. Но не в этом уроке.

Очистка (Sanitization)

«Подожди!, скажите вы. «Я думал(а), мы уже готовы сохранять параметры!» Это так, но до этого, мы должны пройти через процесс очистки. Короче говоря, очистка, по своей идее, проверяет, что данные чистые и безопасные для базы данных.

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

Благодаря приятной вспомогательной функции WordPress, мы можем убедиться, что это так же просто, насколько это возможно. Для тех, кому интересно вы можете прочитать все о проверке и очистке данных (хотя мы рассмотрим проверку в следущем уроке).

В нашем коде мы будем использовать sanitize_text_field (как ссылаемся выше) Эта функция будет делать следущее:

• Проверит на недопустимый UTF-8
• Преобразует единичный символ ` save , с которой мы работали и обновите её, так чтобы она выглядела следующим образом:

Заметьте, что мы получаем ввод из $_POST , очищаем его и затем сохраняем результат в отдельной переменной. Дальше, эта переменная записывается в базу данных функцией update_option .

Для этой статьи я предпочитаю использовать ключ tutsplus-custom-data . Что бы вы не использовали, важно, чтобы добавляем префикс был уникальным или другой плагин или тема не смогли перезаписать наш параметр.

Наконец нам нужно перенаправление обратно на страницу параметров. Так как, мы не используем встроенную функцию API, нам нужно написать функцию, которая бы сделала это за нас. К счастью это очень просто.

Во-первых, создайте функцию с названием «redirect» и убедитесь, что она выглядит так:

Код, приведенный выше, должен говорить сам за себя, но чтобы прояснить, он делает следующее:

1. Он проверяет, что частное значение WordPress присутствует в коллекции $_POST . Если оно не установлено, когда оно будет установлено равным URL для входа в WordPress. Это перенаправит людей на страницу входа, если не задано URL перехода; однако нет никаких причин, почему его может не быть.
2. Далее мы берем это перенаправление и очищаем его данные. Это то, что называется стандартом кодирования и гарантирует, что данные чистые.
3. И наконец, мы инициализируем wp_safe_redirect на URL-адрес, таким образом нас вернёт к странице параметров.

Как только вы это сделали, добавьте это в последнюю строку функции save , см выше. В конечном счёте, код должен выглядеть примерно так:

Вот так: У нас тут безопасность, очистка, сериализация и перенаправление. Но мы все ещё не показываем сообщения об ошибках, и не извлекаем данные.

К этому мы доберёмся в следующем уроке.

Заключение

На данный момент у нас есть полу-рабочий плагин и тут ещё много над чем работать. Очевидно, что информация которую мы отправляем в базу данных пока нигде не отражается и это нехорошо.

Но также как сохранение информации, ещё есть важные вещи, которых мы коснёмся при извлечении информации. В следующем уроке, мы рассмотрим получения информации, отображение её на странице, отображение её на странице опций, а также обновление информации, когда пользователь изменяет значение в поле ввода.

В это же время, если вы ищете другие утилиты, для увеличения вашего набора инструментов для WordPress или код, на котором можно учиться и стать более продвинутым в WordPress, не забудьте посмотреть, что у нас есть в наличии на рынке Envato.

Помните, вы можете выловить все мои курсы и учебники на странице Моего профиля, и вы можете следовать за мной в моем блоге и/или Twitter @tommcfarlin, где я говорю о различных практиках разработки программного обеспечения и как мы можем использовать их в WordPress.

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

Источник