Как создать собственную страницу регистрации в WordPress Multisite. Как создать собственную страницу регистрации в WordPress Multisite Заметка про область переменных

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

Эта функция прикрепляет указанную callback функцию к хуку activate_(plugin) и является оберткой для этого хука.

(plugin) в хуке activate_(plugin) заменяется названием относительного пусти до главного файла плагина. Например, если плагин расположен: wp-content/plugins/sampleplugin/sample.php , то название хука будет: activate_sampleplugin/sample.php .

С версии 3.1. хук срабатывает только во время активации плагина, и не срабатывает во время автоматического обновления плагина.

Как это работает

Плагин активируется функцией activate_plugin() , в которой срабатывает хук activate_(plugin) .

Функция activate_plugin() в ядре вызывается уже после загрузки среды ВП . Эта функция подключает главный файл плагина (и все что в нем указано), а затем через хук активирует указанную callback-функцию. За счет этого в нашей callback-функции доступны все функции и классы плагина. Но, так как все основные хуки WP уже сработали во время загрузки среды ВП, то никакие события плагина повешенные на хуки, например plugins_loaded , уже не сработают при подключении главного файла плагина. А значит наш плагин будет подключен, но не полностью: не так как он должен подключаться, когда уже активирован.

Так, например, если плагин делает что-либо во время события plugins_loaded , то все эти действия просто не произойдут при активации плагина. Например, если он подключает файл перевода, то файл перевода не будут подключен в момент срабатывания callback-функции указанной для register_activation_hook() .

Как правило, после срабатывания callback-функции есть 2 события на которые можно повесить функции: activated_plugin и shutdown .

Чтобы сделать что-то неординарное при активации плагина, смотрите пример 5.

Правила использования

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

    register_activation_hook() должен вызываться из основного файла плагина, из того где расположена директива Plugin Name: ... и не должна вызываться из какого-либо хука, вроде plugins_loaded или init .

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

    В функции хука не работает вывод на экран (echo). Потому что происходит редирект и echo вы не увидите. Но можно использовать die() .

  1. Глобальные переменные (если они есть) должны быть определены явно, чтобы был доступ к ним из функции хука.

Заметка про область переменных

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

Так, функция, которая используется в register_activation_hook() может не видеть глобальные переменные, даже если вы объявили их как глобальные внутри этой функции. Пример:

$myvar = "что-то"; register_activation_hook(__FILE__, "myplugin_activate"); function myplugin_activate(){ global $myvar; echo $myvar; // Переменная не равна "что-то" }

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

Global $myvar; // указываем явно что это глобальная переменная $myvar = "что-то"; register_activation_hook(__FILE__, "myplugin_activate"); function myplugin_activate(){ global $myvar; echo $myvar; //> что-то }

Хуков нет.

Возвращает

null. Ничего не возвращает.

Использование

register_activation_hook($file, $function); $file(строка) (обязательный) Путь до главного php файла плагина включая название самого плагина. Обычно используется волшебная константа PHP __FILE__ . $function(строка/массив/лямбда) (обязательный)

Название функции обратного вызова. Для классов используйте массив: array($this, "название_функции"); .

Функция получит логическую переменную $network_wide - активируется ли плагин для всей сети сайтов, при мультисайте.

Примеры

#1. Запуск функции при активации плагина

Предположим у нас есть функция my_plugin_activate() в основном файле плагина: wp-content/plugins/myplugin/myplugin.php , тогда для запуска этой функции во время активации плагина используйте такой код:

Register_activation_hook(__FILE__, "my_plugin_activate"); function my_plugin_activate() { // Код активации... }

#2. Запуск метода класса

Если плагин использует PHP класс, код активации добавляется так:

Register_activation_hook(__FILE__, array("My_Plugin", "install")); class My_Plugin { static function install() { // Не создавайте здесь никакого вывода... } }

#3. Запуск метода класса из отдельного файла

Если класс, который содержит функцию активации находится в отдельном файле, то регистрируйте функцию активации так:

Include_once __DIR__ . "/class-My_Plugin.php"; register_activation_hook(__FILE__, array("My_Plugin", "on_activate_function"));

#4. Запуск метода класса из самого класса

Если вы находитесь внутри __construct() . Важно, __FILE__ должен «смотреть» на главный файл плагина:

Register_activation_hook(__FILE__, array($this, "YOUR_METHOD_NAME"));

#5 Делаем что-либо сразу после активации плагина

После активации плагина срабатывают только два хука: activated_plugin и shutdown .

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

Когда такое решение не подходит, можно использовать опции WP: сохранять данные в опцию и затем проверять наличие опции, и делать что-либо, если опция есть:

// Основной файл плагина. ... function my_plugin_activate() { // добавляем опцию, чтобы потом если она есть сделать что-либо. add_option("Activated_Plugin", "Plugin-Slug"); // Здесь код активации... } register_activation_hook(__FILE__, "my_plugin_activate"); function load_plugin() { if (is_admin() && get_option("Activated_Plugin") == "Plugin-Slug") { // удаляем добавленную опцию, чтобы она больше не срабатывала // и делаем что нужно... delete_option("Activated_Plugin"); // Делаем что-либо единожды, после активации плагина // Например: add_action("init", "my_init_function"); } } add_action("admin_init", "load_plugin");

Другой вариант сделать что-то во время активации плагина - это создать свое событие так:

Function my_plugin_activate(){ // Устанавливаем свой хук, чтобы к нему можно было прицепиться из файлов самого плагина do_action("my_plugin_activate"); } register_activation_hook(__FILE__, "my_plugin_activate");

#6 Еще демонстрация использования функции

Небольшой плагин, демонстрирующий как нужно использовать функцию:

/* Plugin Name: A Test Description: A Test */ require_once dirname(__FILE__) . "/my_other_file.php"; /* Этот код не будет работать. Хук активации должен вызываться из основного файла. register_activation_hook (dirname(__FILE__) . "/my_other_file.php", "my_other_function"); */ // Это рабочий код. register_activation_hook(__FILE__, "test_activated"); /* Это правильный вариант объявления и доступа к глобальным переменным. Глобальные переменные должны объявляться четко. Без этого у вас не будет доступа к ним. */ global $some_var; $some_var = "hey"; // Функция активации function test_activated(){ // тут $some_var не будет равно hey global $some_var; // А тут $some_var будет равно hey // Эта функция определена в файле "my_other_file.php" my_other_function(); /* Этот вариант не будет работать. Если нужно записать логи во временный файл, используйте fopen/fwrite. Если вы хотите проверить, работает ли хук активации, используйте exit() внутри функции хука. */ echo "test_activated called!"; }

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

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

В обычной установке WordPress страницу регистрации, авторизации и сброса пароля выводит файл wp-login.php .

  • wp-login.php — авторизация
  • wp-login.php?action=register — регистрация
  • wp-login.php?action=lostpassword — сброс пароля

В режиме Multisite ядро WordPress начинает вести себя несколько иначе и при переходе по ссылке wp-login.php?action=register произойдет редирект на wp-signup.php . Это страница регистрации вашей сети, которая по умолчанию есть в WordPress.

Помимо регистрации обычных пользовательских аккаунтов на ней можно создать и новый сайт, если суперадминистратор включил такую возможность в настройках сети (Network Admin → Settings → Network Settings).

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

Но не стоит отчаиваться, если страница выглядит неопрятно. Файл wp-signup.php отличная вещь на первых порах, когда нет времени прорабатывать каждую деталь сайта — можно сосредоточиться на других более важных страницах и контенте.

Когда вы будете готовы сделать свою собственную страницу регистрации, wp-signup.php будет хорошим образцом и примером, по которому легко разобраться в спектре функций, которые предоставляет WordPress для обработки и проверки введенных пользователями данных и создания новых аккаунтов.

Основной сайт сети

По умолчанию, WordPress открывает страницу регистрации (wp-signup.php) на основном домене (сайте) сети. Тем не менее, можно создавать страницы регистрации для каждого сайта сети, даже если у них и темы.

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

Альтернатива functions.php

Порядок в файлах

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

| mu-plugins | | load.php | | selena-network | | | signup | | | | plugin.php | | | ... | | | jetpack | | | | plugin.php

В файле load.php подключаются переводы и все необходимые «плагины»:

// Загрузка переводов для MU-плагинов load_muplugin_textdomain("selena_network", "/selena-network/languages/"); // Функционал для страницы регистрации require WPMU_PLUGIN_DIR . "/selena-network/signup/plugin.php"; // Еще один плагин // require WPMU_PLUGIN_DIR ...

Внутри директории selena-network хранятся папки плагинов. В каждой есть свой plugin.php , которые мы и подключаем в load.php . Это дает гибкость и возможность мгновенно отключать и включать отдельные компоненты на рабочем проекте в случае экстренной необходимости.

Страница регистрации

Разобравшись с тем, где и как мы будем писать код, можно переходить к созданию страницы регистрации.

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

Редирект на нужную страницу регистрации

Чтобы WordPress узнал о нашей новой странице регистрации и производил редирект именно на нее, при клике на ссылку «Зарегистрироваться», используется фильтр wp_signup_location . Его можно найти внутри wp-login.php и именно он отвечает за редирект на wp-signup.php по умолчанию.

Case "register" : if (is_multisite()) { wp_redirect(apply_filters("wp_signup_location", network_site_url("wp-signup.php"))); exit; // ...

Как вы помните, по умолчанию, страница регистрации открывается на основном домене сети. Именно поэтому здесь используется network_site_url() .

Добавим свой обработчик к фильтру в mu-plugins/selena-network/signup/plugin.php , который будет отдавать адрес страницы регистрации на текущем сайте:

Function selena_network_signup_page($url) { return home_url("signup"); } add_filter ("wp_signup_location", "selena_network_signup_page", 99);

selena_network — префикс, который я использую в именах всех функций внутри MU-плагинов на своем сайте для избежания коллизий, его следует заменить на свой собственный уникальный префикс. Приоритет добавления фильтра 99, потому что некоторые плагины, например, bbPress и BuddyPress могут перезаписать этот адрес на свой собственный (MU-плагины загружаются раньше, чем обычные плагины, см. выше).

Обратите внимание, что используется home_url() , которая в отличие от network_site_url() , отдает адрес текущего сайта, а не главного сайта сети.

Функционал wp-signup.php

Файл wp-signup.php содержит большое количество функций и кода. Чтобы увидеть картину в целом можно воспользоваться сворачиванием кода. Как правило, по-английски это называется «code folding».

В самом начале файла с 1 по 80 строчку (в версии 4.1.1) производятся различные проверки и вывод «старта» страницы с помощью get_header() .

Далее объявляются множество методов и перед тем, как мы начнем работать с ними, стоит разобраться что делает каждая функция. Внутри многих из них часто используются другие функции с префиксом wpmu_ , все они объявляются в файле wp-includes/ms-functions.php . Этот раздел тяжело понять не видя код самостоятельно. Ниже небольшое описание основных функций на случай, если у вас возникнут затруднения.

  • wpmu_signup_stylesheet() — вывод дополнительного CSS на странице регистрации.
  • show_blog_form() — поля для регистрации сайта (адрес, название видимость для поисковых систем).
  • validate_blog_form() — проверка введенного адреса сайта и названия с помощью wpmu_validate_blog_signup() .
  • show_user_form() — поля для регистрации пользователя (логин и адрес эл. почты).
  • validate_user_form() — проверка введенного логина и адреса эл. почты с помощью wpmu_validate_user_signup() .
  • signup_another_blog() — поля для регистрации новых сайтов с помощью show_blog_form() для пользователей, которые уже зарегистрированы на сайте.
  • validate_another_blog_signup() — проверяет адрес сайта и название с помощью validate_blog_form() .
  • signup_user() — основная функция для вывода полей страницы регистрации.
  • validate_user_signup() — проверяет логин и адрес эл. почты с помощью validate_user_form() .
  • signup_blog() — поля для ввода адреса, названия и видимости сайта (второй шаг регистрации) с помощью show_blog_form() .
  • validate_blog_signup() — проверяет логин, адрес эл. почты, адрес и название сайта.

В самом низу файла wp-signup.php (со строчки 646 в версии 4.1.1) основная логика работы страницы регистрации, которая использует все выше описанные методы. Эта часть кода не вынесена в функцию. В конце вызывается get_footer() .

Копируем функционал wp-signup.php

Далее будет описана процедура копирования wp-signup.php в MU-плагины и внесению изменений в «форк». Возможно, это может показаться не самым правильным путем. Вместо этого можно с нуля написать свои функции для проверки и вывода форм используя классы, а не обычные функции. На мой взгляд в wp-signup.php уже есть вся необходимая логика для нашей страницы, остается лишь внести небольшие изменения.

При обновлении WordPress время от времени меняется и wp-signup.php , но это не значит что при каждом релизе придется синхронизировать свой «форк». Функции внутри wp-signup.php по сути занимаются лишь выводом HTML, проверкой данных, созданием учетных записей и сайтов занимаются методы с префиксом wpmu_ , объявленные в ms-functions.php .

Займемся созданием функции, которая будет выводить форму регистрации на странице. Для этого скопируем wp-signup.php из корня WordPress в mu-plugings/selena-network/signup/ . Подключим его внутри mu-plugins/selena-network/signup/plugin.php).

Require WPMU_PLUGIN_DIR . "/selena-network/signup/wp-signup.php";

Удалим из самого начала скопированного файла все require и ненужные проверки. В версии 4.1.1 это весь код с 1 по 80 строчку.

Теперь мы готовы создать главную функцию для вывода формы регистрации. Для этого всю логику со строчки 646 и до самого конца файла перенесем в функцию c названием selena_network_signup_main . В самом конце удалим два лишних закрывающих

(строчки 722 и 723), а также вызов get_footer() .

В только что созданной selena_network_signup_main() в самом начале объявим глобальную переменную active_signup , которую используют все остальные методы из этого файла. И добавим вызов события before_signup_form , которое мы удалили из самого начала файла.

Function selena_network_signup_main() { global $active_signup; do_action("before_signup_form"); // ... }

Теперь остается лишь изменить верстку во всех местах где это необходимо и страница регистрации готова.

Вывод формы регистрации

Здесь есть как минимум два варианта. Более удобный способ — создать шорткод и разместить его на странице через обычный редактор.

// Создаем шорткод network_signup add_shortcode("network_signup", "selena_network_signup_main");

Второй вариант — создать в папке дочерней темы шаблон страницы page-signup.php . Вместо слова «signup» можно использовать уникальный ID, присвоенный странице. Внутри шаблона добавить необходимую верстку и сделать вызов selena_network_signup_main() в нужном месте.

В результате моя страница регистрации стала выглядеть намного лучше и чище.

Страница активации

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

За вывод страницы активации отвечает файл wp-activate.php расположенный в корневой директории WordPress. wp-activate.php можно так же полностью изменить. Процесс схож с тем, что мы уже делали для wp-signup.php .

Создадим страницу example.org/activate/ через обычный интерфейс. В качестве адреса используйте любой URL, который покажется вам подходящим.

Скопируем файл wp-activate.php к себе в MU-плагины и подключим его в mu-plugins/selena-network/signup/plugin.php .

Require WPMU_PLUGIN_DIR . "/selena-network/signup/wp-activate.php";

Внутри не так много содержимого, в отличие от wp-signup.php . Файл выполняет единственную операцию — активирует аккаунт, если получен верный ключ и выводит сообщение об ошибке или успешном выполнении операции.

Удалим все ненужные проверки и require — с 1 по 69 строчку в WordPress 4.1.1. В самом конце уберем вызов get_footer() . Оставшееся содержимое перенесем в функцию selena_network_activate_main() .

Интересно заметить, что здесь перед загрузкой WordPress (wp-load.php) объявлялась константа WP_INSTALLING . Ее наличие заставляет WordPress не загружать плагины.

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

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

Письма активации с правильными ссылками

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

В момент заполнения и отправки формы на странице регистрации WordPress вызывает wpmu_signup_user () или wpmu_signup_blog () в зависимости от типа регистрации. Обе функции создают новую запись в таблице wp_signups заполняя ее необходимым содержимым, среди которого есть и ключ активации аккаунта.

После, в зависимости от функции, вызывается wpmu_signup_user _notification() или wpmu_signup_blog _notification() . Обе функции имеют схожий функционал — генерируют и отправляют письмо со ссылкой активации, но принимают разные аргументы. В обоих есть фильтры для «перехвата» события.

If (! apply_filters("wpmu_signup_user_notification", $user, $user_email, $key, $meta)) return false;

Для активации аккаунтов с созданием блога:

If (! apply_filters("wpmu_signup_blog_notification", $domain, $path, $title, $user, $user_email, $key, $meta)) { return false; }

Остается лишь написать свои обработчики, внутри которых отправлять письма через wp_mail() , а в самом конце обязательно отдавать false , чтобы WordPress не отправил письмо активации дважды — одно ваше, другое — письмо по умолчанию со ссылкой на wp-activate.php .

Function selena_network_wpmu_signup_user_notification($user, $user_email, $key, $meta = array()) { // Генерируем заголовок, текст и заголовки письма // ... // Отправляем письмо или добавляем Cron-задачу для отправки письма wp_mail($user_email, wp_specialchars_decode($subject), $message, $message_headers); // Отдаем false, чтобы WordPress не отправил письмо активации дважды return false; } add_filter("wpmu_signup_user_notification", "selena_network_wpmu_signup_user_notification", 10, 4);

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

Закрываем доступ к wp-signup.php и wp-activate.php

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

Решить две проблемы одним действием можно попросив Apache отдавать 404 в случае попытки открытия этих страниц. Для этого нужно лишь прописать пару дополнительных RewriteRule в ваш файл-конфигурацию или.htaccess .

RewriteEngine On RewriteBase / # Знание регулярных выражений никогда не будет лишним:) RewriteRule ^wp-signup\.php - RewriteRule ^wp-activate\.php - # BEGIN WordPress # Правила от WordPress по умолчанию не трогаем:) # ... # END WordPress

Заключение

Для этой и многих других «проблем» связанных с WordPress в интернете есть множество решений. Например, для создания страниц регистрации и активации некоторые предлагают переписывать оригинальные wp-signup.php и wp-activate.php . Этого не стоит делать, потому что в случае обновления WordPress вы потеряете все изменения, внесенные в файлы, а также не сможете, проверить целостность ядра с помощью .

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

P.S.

Для автоматического назначения разных ролей новым пользователям можно использовать плагин Multisite User Management .

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

27.03.2015 27.03.2015

WordPress разработчик. Любит порядок во всем и разбираться в новых инструментах. Вдохновлен архитектурой компонентов Symfony.

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

    Создание URL

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

    Http://example.com/activate?token=ee97780...

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

    CREATE TABLE pending_users (token CHAR(40) NOT NULL, username VARCHAR(45) NOT NULL, tstamp INTEGER UNSIGNED NOT NULL, PRIMARY KEY(token));

    В таблице будем хранить 3 поля: токен, имя пользователя и время. Для генерации токена мы воспользуемся функцией sha1(), которая выдаёт строку из 40 символов. Поле tstamp будет хранить время генерации токена для того, чтобы мы могли отследить ссылки с истёкшим сроком.

    Существует множество способов генерации токена, однако в этом уроке мы воспользуемся функциями uniqid() и sha1(). Независимо от способа генерации токена, убедитесь что генерируемые значения будут разными и вероятность появления дубликатов минимальна.

    $token = sha1(uniqid($username, true));

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

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

    $query = $db->prepare("INSERT INTO pending_users (username, token, tstamp) VALUES (?, ?, ?)"); $query->execute(array($username, $token, $_SERVER["REQUEST_TIME"]));

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

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

    $url = "http://example.com/activate.php?token=$token";

    $message = <<

    Проверка

    Теперь нам нужен скрипт, благодаря которому мы будем осуществлять проверку. Всё что нам нужно сделать, это сравнить токен из url адреса и токен из базы. Если такой имеется, и время его жизни не истекло, то всё ОК.

    // получаем токен if (isset($_GET["token"]) && preg_match("/^{40}$/i", $_GET["token"])) { $token = $_GET["token"]; } else { throw new Exception("токен не валиден."); } // проверяем токен $query = $db->prepare("SELECT username, tstamp FROM pending_users WHERE token = ?"); $query->execute(array($token)); $row = $query->fetch(PDO::FETCH_ASSOC); $query->closeCursor(); if ($row) { extract($row); } else { throw new Exception("токен не валиден."); } // активируем пользовательский аккаунт // ... // удаляем токен из базы $query = $db->prepare("DELETE FROM pending_users WHERE username = ? AND token = ? AND tstamp = ?",); $query->execute(array($username, $token, $tstamp));

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

    // 1 день в секундах = 60 секунд * 60 минут * 24 часа $delta = 86400; // проверка if ($_SERVER["REQUEST_TIME"] - $tstamp > $delta) { throw new Exception("время жизни токена истекло."); } // активируем пользовательский аккаунт // ...

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

    Итог

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

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