Статьи

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

Февраль 28, 2019

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

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

В качестве напоминания мы упомянули:

  • Управление пользователями
  • права доступа
  • Управление сессиями
  • Функциональность электронной почты
  • Сериализация и поиск данных
  • Маршрутизация URL (иногда упоминается как переписывание URL или правила перезаписи или даже просто маршруты)
  • Кэширование
  • Поддержка пользовательских запросов

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

В этом посте мы рассмотрим, как включать сессии в приложение на основе WordPress; однако мы предполагаем, что вы — или другие читатели — совсем не знакомы с сессиями.

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

Введение в сессии

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

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

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

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

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

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

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

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

Загрузка приложения без сеанса

Итак, вот как выглядит типичное приложение с поддержкой базы данных с точки зрения отсутствия какой-либо информации о сеансе. Вместо этого все статически предоставляется на страницах и / или загружается из базы данных:

Простой пример поддерживаемого базой данных веб-приложения
Простой пример поддерживаемого базой данных веб-приложения.

Довольно легко понять, не так ли?

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

Загрузка приложения с сеансом

Если на приведенной выше диаграмме показано, как выглядит веб-приложение, поддерживаемое базой данных, без какого-либо механизма сеансов, как оно выглядит, когда оно предлагает поддержку сеансов?

Прежде чем мы рассмотрим диаграмму, на что это похоже, давайте зададим следующие параметры:

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

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

Простой пример веб-приложения с поддержкой сеансов
Простой пример веб-приложения с поддержкой сеансов.

Ничего страшно сложного, а?

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

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

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

Правда о WordPress и сессиях

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

На самом деле, если вы уже работали с PHP, вы, вероятно, также знакомы с работой сессий.

Но вот интересный факт (по крайней мере, я думаю, что это интересно!):

Основное приложение WordPress не использует сессии.

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

Как мы реализуем сессии?

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

В частности, это означает, что вы знаете, как:

  • Начать сеанс
  • Хранить информацию в сеансе
  • Получить информацию из сеанса (и как извлечь информацию из базы данных, если она не находится в сеансе)
  • Уничтожить сессию

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

Начать сессию

Первое, что вам нужно отметить, это то, что сеансы должны быть запущены. Это делается путем вызова функции PHP session_start() .

При запуске сеанса в PHP нужно отметить две вещи:

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

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

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

Показательный пример: в приведенном ниже коде я запускаю сеанс во время действия init WordPress.

1
2
3
4
5
6
7
function example_login() {
 
    if ( ! session_id() && is_user_logged_in() ) {
        session_start();
    }
}
add_action( ‘init’, ‘example_login’ );

Теперь, когда сеанс начался, мы можем начать хранить информацию.

Хранить информацию о сессиях

Работа с данными сеанса очень похожа на работу с данными, хранящимися в $_GET , $_POST или даже в обычном ассоциативном массиве. Короче говоря, PHP предлагает коллекцию $_SESSION которая позволяет нам хранить информацию через пары ключ / значение.

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

01
02
03
04
05
06
07
08
09
10
11
12
13
function example_login() {
 
    if ( ! session_id() && is_user_logged_in() ) {
 
        session_start();
 
        if ( ! isset( $_SESSION[‘time’] ) ) {
            $_SESSION[‘time’] = time();
        }
 
    }
}
add_action( ‘init’, ‘example_login’ );

Достаточно просто — во-первых, я проверяю, установлен ли session_id() и проверяю, вошел ли пользователь в систему. Если это так, сохраните время.

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

Получить информацию о сеансе

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

Мы можем сделать это используя простое условие:

1
2
3
if ( isset( $_SESSION[‘time’] ) && ! empty( $_SESSION[‘time’] ) ) {
    print_r( $_SESSION[‘time’] );
}

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

Уничтожить сессию

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

Наконец, поскольку мы устанавливаем сеанс при входе пользователя в систему, мы хотим уничтожить сеанс всякий раз, когда пользователь выходит из системы. Это относительно просто с помощью PHP-функции session_destroy() ; Однако есть некоторые более тонкие нюансы, которые необходимо понимать.

Прямо из руководства по PHP:

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

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

1
2
3
4
5
6
7
8
function example_logout() {
 
    if ( session_id() ) {
        session_destroy();
    }
 
}
add_action( ‘wp_logout’, ‘example_logout’ );

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

Есть некоторые ошибки!

Какой была бы статья о программировании без каких-либо ошибок, верно?

Во-первых, мы уже установили, что само ядро ​​WordPress не имеет состояния. Кроме того, он также поддерживает функцию, которая используется для сброса глобальных переменных (вы можете найти эту функцию в wp-includes / load.php — просто найдите wp_unregister_GLOBALS ).

Глядя на исходный код, вы заметите следующие строки:

1
2
3
4
5
$input = array_merge( $_GET, $_POST, $_COOKIE, $_SERVER, $_ENV, $_FILES, isset( $_SESSION ) && is_array( $_SESSION ) ? $_SESSION : array() );
foreach ( $input as $k => $v )
    if ( !in_array( $k, $no_unset ) && isset( $GLOBALS[$k] ) ) {
        unset( $GLOBALS[$k] );
    }

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

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

Что делать разработчику?

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

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

Сессии имеют значение?

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

Но возникает вопрос: важны ли сессии?

Я считаю этот вопрос немного субъективным.

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

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

Все это говорит: это зависит от характера вашего проекта.

На данный момент мы готовы перейти к следующему общему компоненту веб-приложений: электронная почта.

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

105
Share: