Использование WordPress для разработки веб-приложений: перезапись URL-адресов

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

Например, получив некоторые данные — скажем, для персональной страницы — вы сможете выполнить следующие действия:

  • Добавить;
  • Обновить;
  • Удалить;
  • И так далее.

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

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

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

На самом деле, мы можем задавать правила перезаписи ссылок, чтобы они соответствовали и обрабатывались так же, как и в современных фреймворках на базе MVC.

Обзор правил перезаписи

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

Например, по умолчанию структура назначения постоянных ссылок в WordPress выглядит следующим образом:

http://domain.com/?p=123

Этот URL-адрес включает в себя строку запроса параметра с ключом значения параметра p=123 в системе WordPress, которые указывают «вывести пост с ID 123».

Если предметно рассмотреть параметры в панели «Настройки постоянных ссылок», то здесь поддерживается множество различных вариантов:

Настройки постоянных ссылок

Другой пример из правил настройки, с которым вы вероятно имели дело, это опция известная как «весьма постоянные ссылки», или, как они называются, в панели управления WordPress, «Заголовок записи».

В этом формате URL-адрес выглядит следующим образом:

http://domain.com/post-title/

Здесь запрос страницы поступает на веб-сервер, а затем на основе набора правил определяется ID сообщения, имеющего такой заголовок, и сообщение возвращается запрашивавшему его клиенту (в качестве которого в данном случае выступает браузер).

Между этими двумя примерами существует связь, определяемая принципами работы системы. Она и демонстрирует, что же такое правила перезаписи URL-адресов.

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

Естественно, тут сразу возникают два вопроса:

  • Как составляются правила перезаписи?
  • И, возможно, что еще более важно, почему они так сложны?

Как обстоят дела с правилами перезаписи

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

Есть хорошее высказывание Джейми Завински насчет стандартных выражений:

«Некоторые люди, столкнувшись с проблемой, думают: «Я знаю, для решения проблемы надо использовать стандартные выражения». И теперь у них появляются сразу две проблемы».


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

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

Очистка правил перезаписи

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

Существует два способа, с помощью которых это можно сделать:

  1. Вы можете нажать кнопку «Сохранить изменения» в панели «Настройка постоянных ссылок». Несмотря на то, какой вариант вы выберете, в любом случае все изменения отражаться в файле functions.php;
  2. Вы можете вызвать функцию $wp_rewrite->flush_rules(); и решить проблему программно.

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

Как работают функции перезаписи?

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

Весь процесс можно условно разделить на четыре этапа:

  • Запрос URL-адреса с веб-сервера;
  • Если контент существует по запрошенному URL-адресу, то он будет выведен (это может быть изображение, шрифт или что-либо еще);
  • Если контент не существует, то запрос будет направлен к файлу index.php, который соответствует шаблону URL-адреса;
  • Затем содержимое выдается из WordPress клиенту.

Если вам интересно поближе познакомиться с правилами перезаписи, которые устанавливаются на основе настроек раздела «Постоянные ссылки» в панели администрирования, вы можете попробовать плагин Rewrite Rules Inspector.

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

Постоянные ссылки

Улавливаете мысль? Если нет, то давайте рассмотрим несколько простых, практических примеров.

Пример правил перезаписи

Учитывая, что шаблоны распознаются и передаются через файл index.php, мы можем воспользоваться функцией add_rewrite_rule, чтобы определить, как будут работать наши пользовательские URL-адреса.

Краткое название для ID записи

Давайте предположим, что мы рассматриваем первый пост в системе — то есть, мы рассматриваем запись с ID 1.

В большинстве только что установленных систем WordPress, это «Привет, мир», и URL-адрес этой записи выглядит следующим образом http://domain.com/hello-world или http://domain.com/?p=1 , в зависимости от настроек постоянных ссылок (то есть, текущего набора правила перезаписи).

Но давайте зададим правило, согласно которому с адреса http://domain.com/first также будет загружаться первое сообщение в базе данных:

function example_add_rewrite_rules() {
 
    add_rewrite_rule( 'first', 'index.php?p=1', 'top' );
    flush_rewrite_rules();
 
}
add_action( 'init', 'example_add_rewrite_rules' );

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

А именно, http://domain.com/?p=2:

function example_add_rewrite_rules() {
 
    add_rewrite_rule( 'first', 'index.php?p=1', 'top' );
    add_rewrite_rule( 'second', 'index.php?p=2', 'top' );
 
    flush_rewrite_rules();
 
}
add_action( 'init', 'example_add_rewrite_rules' );

Если вы ознакомились с документацией по add_rewrite rule, то это вполне понятно, не так ли?

Короче говоря, функция принимает три аргумента:

  • Первый аргумент является стандартным выражением, соответствующим запрашиваемому URL-адресу. В нашем случае, мы используем простые слова;
  • Вторым аргументом является сам URL-адрес, который мы запрашиваем. Опять же, в нашем случае мы извлекаем первую и вторую запись соответственно;
  • И, наконец, последним аргументом является приоритет, который может принимать значения «top» или «bottom«. Если установлено значение «top«, то это правило будет иметь более высокий приоритет, по сравнению с другими. Но, если «bottom«, тогда оно будет иметь низший приоритет.

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

Примечания к запрашиваемым правилам перезаписи

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

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

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

Более сложный подход к правилам перезаписи

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

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

Теперь, предположим, что у нас есть записи пользовательского типа под названием «Персональная страница», представляющая данные пользователя приложения.

И, предположим, что для персональной страницы также заданы следующие методы и соответствующие им схемы URL-адресов:

all: http://domain.com/individuals/;
update: http://domain.com/individual/update/1, который используется для обновления от первого лица;
delete: http://domain.com/individual/delete/1, который используется для удаления от первого лица.

Таким образом, схема теоретически достаточно проста, но как нам реализовать ее на практике?

Во-первых, мы должны определить правила перезаписи:

function example_add_rewrite_rules() {
 
    // Задаем тег для ID персональной страницы
    add_rewrite_tag( '%individual_id%', '([0-9]*)' );
 
    // Задаем правила перезаписи для каждого человека
    add_rewrite_rule( '^individual/update/([0-9]*)', 'index.php?individual=update&individual_id=$matches[1]', 'top' );
    add_rewrite_rule( '^individual/delete/([0-9]*)', 'index.php?individual=delete&individual_id=$matches[1]', 'top' );
 
}
add_action( 'init', 'example_add_rewrite_rules' );

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

В этом случае мы определяем две функции — одна для обновления персональных страниц, вторая — для их удаления.

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

В частности, требуется, чтобы для обновления персональной страницы ID, имя, фамилия, и другая информация были отправлены в соответствующей форме:

function example_process_individual( $input ) {
 
    if ( example_updating_user() ) {
        example_update_individual( $input );
    } else if ( 'true' == $input['delete_individual'] ) {
        example_delete_individual( $input['individual_id'] );
    }
 
}
if( ! is_admin() ) add_action( 'init', 'example_process_individual' );
 
function example_update_individual( $input ) {
 
    /* Входящий набор $input требуемой формы,
     * которая используется для обновления пользователя.
     *
     * Он может содержать такие данные, как ID, имя,
     * фамилию и т.д.
     *
     * В случае если все верно, используется <code>wp_redirect</code>
     * для перехода назад на домашнюю страницу, либо же перезагрузка
     * страницы и вывод сообщения об ошибке.
     */
 
}
 
function example_delete_individual( $individual_id ) {
 
    /* Используется входящий ID для нахождения записи персональной страницы
     * и удаления ее из базы данных.
     *
     * В случае если все верно, используется <code>wp_redirect</code>
     * для перехода назад на домашнюю страницу, либо же перезагрузка
     * страницы и вывод сообщения об ошибке.
     */
 
}
 
function example_updating_user() {
    return 0 == strpos( $_SERVER['REQUEST_URI'], '/individual/update' );
}
 
function example_deleting_user() {
    return 0 == strpos( $_SERVER['REQUEST_URI'], '/individual/delete' );
}

Обратите внимание, что первая функция связана с действием init и запускается только, если пользователь не вошел в систему под логином администратора.

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

Также ознакомьтесь с кодом комментариев для функций Update и Delete , чтобы понять, как они должны работать.

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

Это, конечно, не все

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

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

Тем не менее, это важный компонент приложений WordPress, который позволяет системе служить основой для разработки веб-приложений.

Что дальше?

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

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

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

Перевод статьи «Using WordPress For Web Application Development: Available Features, Part 6: URL Rewriting (or Routes)» был подготовлен дружной командой проекта Сайтостроение от А до Я.