Статьи

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

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

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

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

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

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

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


В предыдущей статье мы дали два определения – одно специально для действий, а другое специально для хуков:

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

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

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

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

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

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

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

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

1
2
3
4
function example_add_theme_scripts() {
    wp_enqueue_script( ‘re-example-script’, get_stylesheet_directory_uri() . ‘/js/example.js’, array( ‘jquery’ ), ‘1.0.0’, FALSE );
}
add_action( ‘wp_enqueue_scripts’, ‘re_add_theme_scripts’ );

Это достаточно легко понять, верно?

Скопируйте скрипт в файле example.js темы из каталога JavaScript, убедитесь, что он помечен как зависимый от загрузки jQuery, обратите внимание, что это версия скрипта 1.0.0, и мы не хотим загружать его в сноска.

Изначально WordPress предоставляет возможность добавить ссылку «Подробнее …» или «Продолжить чтение …», которая достигается с помощью <!--more--> в сообщении. редактор.

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

Затем вы можете использовать следующее действие:

01
02
03
04
05
06
07
08
09
10
function example_add_more_link_class( $link, $text ) {
 
    $html = ‘<div class=”more-link-wrapper”>’;
        $html .= ‘<div class=”more-link”>’ .
    $html .= ‘</div>’;
 
    return $html;
 
}
add_action( ‘the_content_more_link’, ‘example_add_more_link_class’, 10, 2 );

Обратите внимание, что мы подключаемся к the_content_more_link которая принимает the_content_more_link и текст привязки для дополнительной ссылки.

Внутри функции мы затем оборачиваем фактическую ссылку в ее собственный контейнер div чтобы иметь больший контроль над стилем ссылки.

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

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
function example_get_user_name() {
 
    $user = null;
 
    if ( isset( $_GET[‘user_id’] ) && 0 < strlen( trim( $_GET[‘user_id’] ) ) ) {
 
        $user = get_user_by( ‘id’, $_GET[‘user_id’] );
 
        if ( FALSE == $user ) {
            echo $user->first_name;
        } else {
            echo ‘-1’;
        }
 
    } // end if
 
    die;
 
} // end re_get_employee_by_name
add_action( ‘wp_ajax_example_get_user_name’, ‘example_get_user_name’ );
add_action( ‘wp_ajax_nopriv_example_get_user_name’, ‘example_get_user_name’ );

Таким образом, в приведенном выше примере мы сначала проверяем, установлен ли user_id в коллекции $_GET , и, если это так, он будет пытаться извлечь пользователя из этого идентификатора.

Если пользователь существует, то он будет возвращать имя пользователя обратно клиенту; в противном случае он будет отображать « -1 ». Это тогда дает нам гибкость, чтобы адекватно реагировать на стороне клиента.

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

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

Это может быть достигнуто с помощью следующего кода:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
function example_append_post_content( $content ) {
 
    if ( is_single() ) {
 
        $html = ‘<div class=”post-suffix”>’;
            $html .= ‘This content will appear at the end of a post.’;
        $html .= ‘</div>’;
 
        $content .= $html;
 
    }
 
    return $content;
 
}
add_filter( ‘the_content’, ‘example_append_post_content’ );

Это достаточно легко понять, верно?

the_content передает фактическое содержание сообщения в подключенную функцию. Оттуда мы можем свободно манипулировать данными любым удобным для нас способом.

В нашем случае мы сначала проверяем, является ли это одной страницей. Если это так, то мы добавим контейнер с post-suffix с одним предложением, добавим его к содержимому и вернем.

Если это не один пост, то контент будет возвращен как обычно.

Другой тип фильтра, которым вы можете воспользоваться, – это перенаправление пользователей после того, как они вошли в приложение.

Например, возможно, если они администратор, они должны быть направлены на панель сообщений; в противном случае они должны быть перенаправлены на домашнюю страницу сайта.

Для этого мы можем воспользоваться login_redirect filter:

1
2
3
4
function example_login_redirect( $redirect_to, $request, $user ) {
    return ( isset( $user->roles ) && is_array( $user->roles ) && in_array( ‘administrator’, $user->roles ) ) ?
} // end soi_login_redirect
add_filter( ‘login_redirect’, ‘example_login_redirect’, 10, 3 );

В приведенном выше коде мы предоставили пользовательский фильтр для login_redirect который выполняет следующее:

  • Если пользователь является администратором, перенаправьте их на панель инструментов
  • В противном случае направьте их на home_url сайта.

Достаточно просто.

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

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

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

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

Для этого нам сначала нужно определить функцию:

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
function example_exmail_user( $input ) {
 
    // Code removed from brevity.
    // Assume $message is defined as the content of the email
 
    add_filter( ‘wp_mail_content_type’, create_function( ”, ‘return “text/html”;’ ) );
    add_filter( ‘wp_mail_from’, ‘example_mail_from’ );
    add_filter( ‘wp_mail_from_name’, ‘example_mail_from_name’ );
 
    if ( wp_mail( $input[’email-address’], ‘Your Account Has Been Created!’, $message ) ) {
 
        // Redirect back home
        wp_redirect( home_url() );
 
    } else {
 
        // Specify a page to which to direct upon an error
 
    }
 
    exit;
 
}
 
function example_mail_from( $email ) {
    return ‘donotreply@emailaddress.com’;
}
 
function example_mail_from_name( $name ) {
    return ‘Example Web App’;
}

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

  • wp_mail_content_type
  • wp_mail_from
  • wp_mail_from_name

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


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

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

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

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


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

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