Статьи

Использование WordPress для разработки веб-приложений: доступные функции, часть 6: перезапись URL (или маршруты)

Ноябрь 8, 2018

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

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

  • добавлять
  • Обновить
  • удалять

И так далее.

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

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

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

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

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

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

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

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

Этот URL содержит параметр строки запроса, а именно пару значений ключа p=123 которая в контексте WordPress говорит: «получить сообщение с идентификатором 123».

Если вы более подробно рассмотрите параметры на экране « Постоянная ссылка» , вы также увидите различные варианты:

Permalinks

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

В этом формате URL выглядит так:

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

Отсюда запрошенный URL-адрес поступает на веб-сервер, а затем на основе набора правил определяет идентификатор сообщения, имеющего этот заголовок, и возвращает его запрашивающему клиенту (который будет браузером).

Между этими двумя примерами есть основной принцип, который демонстрирует, какие именно правила переписывания.

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

Конечно, это поднимает два вопроса:

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

Бизнес переписать правила

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

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

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

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

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

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

Есть два способа сделать это:

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

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

Как работает Rewrite API?

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

Это может быть переработано в четыре этапа:

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

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

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

Переписать правила инспектора

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

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

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

Краткое название для идентификатора сообщения

Допустим, мы смотрим на первое сообщение в системе, то есть на сообщение с идентификатором 1.

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

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

1
2
3
4
5
6
7
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 .

1
2
3
4
5
6
7
8
9
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», то это правило будет оцениваться выше всех других правил; однако, если «снизу», то оно будет оцениваться последним.

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

Импорт заметок о правилах перезаписи Flushing

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

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

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

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

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

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

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

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

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

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

01
02
03
04
05
06
07
08
09
10
11
function example_add_rewrite_rules() {
 
    // Define the tag for the individual ID
    add_rewrite_tag( ‘%individual_id%’, ‘([0-9]*)’ );
 
    // Define the rules for each of the individuals
    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’ );

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

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

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
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 ) {
 
    /* The incoming $input collection from an assumed form
     * that will be used to update the user.
     *
     * It may include information such as the ID, the first name,
     * last name, and so on.
     *
     * Upon success, use <code>wp_redirect</code> to go back to the homepage, or reload
     * the page to show an error.
     */
 
}
 
function example_delete_individual( $individual_id ) {
 
    /* Use the incoming ID to locate the individual record and remove it
     * from the database.
     *
     * Upon success, use <code>wp_redirect</code> to go back to the homepage, or reload
     * the page to show an error.
     */
 
}
 
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 Rewrite API, обсудить преимущества его использования и поговорить о как это можно использовать для создания более чистых маршрутов URL.

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

Следующий

После всего вышесказанного пришло время перейти к концепции кеширования .

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

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

38
Share: