ГлавнаяРазноеКак создать собственную страницу регистрации в WordPress Multisite

Как создать собственную страницу регистрации в WordPress Multisite

Режим Multisite позволяет использовать одну установку 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).

Настройки сети в режиме Multisite

Настройки сети в режиме Multisite

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

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

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

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

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

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

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

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

Что такое MU-плагины?

MU-плагины (Must Use Plugins) загружаются при открытии любого сайта сети. Их нельзя отключить или включить в административной части WordPress, они работают всегда. Стоит отметить, что MU-плагины загружаются раньше обычных плагинов, тем оформления и до полной загрузки ядра WordPress, поэтому вызов некоторых функций может привести к фатальным ошибкам в PHP.

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

В Jetpack, например, есть события вида jetpack_module_loaded_related-posts (related-posts — название модуля), с помощью которых можно отслеживать активность модулей. К этому событию невозможно «прицепиться» из functions.php, потому что оно срабатывает еще до загрузки темы — плагины загружаются раньше тем.

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

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

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».

Содержимое файла wp-signup.php

Содержимое файла wp-signup.php

В самом начале файла с 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. В самом конце удалим два лишних закрывающих </div> (строчки 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' );
    // ...
}

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

Для наглядности я опубликовал свою версию измененного wp-signup.php на Github.

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

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

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

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

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

Собственная страница регистрации в WordPress Multisite

Собственная страница регистрации в WordPress Multisite

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

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

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

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

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

Создадим страницу 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-плагинов во все функции-переводчики, по умолчанию он нигде не установлен).

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

Финальный вариант wp-activate.php на Github.

Собственная страница активации в WordPress Multisite

Собственная страница активации в WordPress Multisite

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

Страница активации готова к работе, но 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 - [R=404,L]
RewriteRule ^wp-activate\.php - [R=404,L]

# BEGIN WordPress
# Правила от WordPress по умолчанию не трогаем :)
# ...
# END WordPress

Заключение

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

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

P.S.

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

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

Подписаться на рассылку

Подписаться → Подпишитесь на бесплатную рассылку журнала WP Magazine и получайте новости, события, подборки тем и плагинов, уроки, советы и многое другое в мире WordPress!

  • Sfx-2013

    Спасибо за время и за старание оказанное вами.

    • Пожалуйста :) Кстати, предлагаю всем, кто сумел переварить материал и сделал страницы, поделиться ссылками в комментариях, интересно посмотреть.

  • Хм! А я в прошлом году делал все с нуля свое… Нет, чтобы полистать код и поискать фильтры. Поленился, в результате потратил больше времени.

    • В принципе, сделать редирект через Apache с wp-signup.php на уже свою страницу не так уж сильно страшно и хуже :)

      Не очень будет, если начать переписывать оригинальный файл wp-signup.php, потому что даже в контроле версий непонятно как сохранять его, ведь тема в другой папке лежит (дополнительные проблемы при выгрузке проекта). А в духе последних новостей, когда даже в самых популярных плагинах находят дыры (я про add_query_arg()), то очень опасно выходить за «пределы», начиная создавать свои функции для работы с какими-нибудь _POST _GET и т. п. Надо четко понимать что происходит, а как показывает практика даже опытные разработчики, иногда забывают что-нибудь проверить.

      • Апача нет, Nginx) Кроме того, я принципиально убежден в том, что подобные вещи должны делаться на уровне кода, а не конфигов. Оригинал, естественно, я не переписывал, но пошел не самым оптимальным путем — создал свои query_args, rewrite_rules, а дефолтовые адреса перехватывал и редиректил на них. А вот уже сами обработчики — таки да, писал с нуля все свое. Но там у нас много фронтенд-форм было — и редактирование расширенного профиля, и публикация контента с фронта, так что такой путь в тот момент казался наиболее оптимальным. Сейчас, спустя год, я многие вещи сделал бы по-другому.

        • Да в принципе для сайта все равно конфиги надо писать — какие домены, поддомены, выключать .htaccess и т. п. Владельцы Энджи-серверов, я думаю, чаще имеют дело с конфигами, чем те, у кого Апачи и htaccess :) Так что одним правилом больше, одним меньше… Все эти конфигурации конечно кажутся ух, но я вот сейчас начал в Chef вникать и то, что инфраструктура может также как и обычный код храниться в контроле версий — это очень здорово.

          • Ну, все конфиги в Git валяются, это факт. Жить на VPSках и не делать этого — как минимум странно. Что касается конфигов Nginx — они модульные, все основное делается один раз, домен прописывается тоже один раз, поддомены для Multisite — это wildcard *.domain.com, там нечего дописывать. Так что лезть туда, как правило, незачем. Предпочитаю, чтоб так и оставалось)

          • К сожалению, не все в этом мире системные администраторы :)

          • Да ну, там никакого rocket science, на том же Digital Ocean есть очень подробные уроки по всем аспектам. Один раз настроить сам сервер, потом LEMP-стек — и порядок, дальше лазить не надо, раз в 2 недели выполнять пару команд для обновления софта, и все. А можно вообще готовый образ системы с LEMP-стеком установить, или даже сразу с WordPress — у того же Digital Ocean есть готовые образы. Разворачивается все за пару минут :) Ну а если эти уроки внимательно читать, гуглить что непонятно — так можно быстро освоиться. А пользы — масса. Сисадмином быть не так сложно, как кажется. Если не лезть глубоко в дебри системы и не заниматься компилированием ядра Linux и подобным хардкором)) В остальном — все достаточно просто.

          • Сисадмином быть не так сложно, как кажется.

            Ну-ну. Веб-разработчиком тоже быть достаточно легко – купил тему за $35, скопипастил пол сотни разных снипетов в functions.php, удалил файл xmlrpc.php, отключил WP_DEBUG чтобы не ругался и вперед за следующим проектом :)

          • Костя, верное замечание, под**б засчитан)) Но, тем не менее, нормальному администрированию готового VPS сервера для хостинга своих сайтов (или даже нескольких серверов) можно научиться в достаточно разумные сроки, как и веб-разработке на уровне чуть большем чем «скопипастил пару снипетов». А дальше — постоянное обучение на ходу и развитие. Это наш джедайский путь — учиться каждый день. Материалов в сети — тьма, StackOverflow и прочие ресурсы в помощь. Для того же, чтобы начать с одного сервера и правильно все настроить по урокам DO хватит одного дня. Развернуть систему, закрыть все, кроме ssh для себя и http для мира через ufw / iptables (Ubuntu / Debian), установить fail2ban, развернуть и настроить LEMP, Memcached, Git и еще парочку полезных штук типа WP-CLI, добавить пару системных утилиток типа htop, logwatch — и можно работать. Для дальнейшей работы, если не лезть в дебри, достаточно 2-3 десятков команд. А через полгода-год и не заметишь, что установка и настройка, например, SSL и SPDY на Nginx, сборка того же Nginx из исходников, Elastic Search, Varnish, разведение архитектуры на несколько серверов и тд. уже не так уж и сложно, и все очень даже понятно. Естественно, этого уровня недостаточно, чтобы называть себя сисадмином и претендовать на должность главного сисадмина в крупном датацентре, но для собственных потребностей — вполне достаточно.

          • Обо всем выше сказанном знаешь уже когда все узнал. А когда тебе дали просто сервер и ты ничего не знаешь, то тяжело. На Digital Ocean полно уроков в духе «вот мы напишем пару команд, сервер установлен, пользуемся». А про тонкую настройку нет. У меня все знакомые и друзья наверное смогут Апач установить, но адекватно настроить — никто. Например, у меня стоял вот VPS и он переодически падал из-за нехватки ОЗУ. Пока я разбирался и пытался понять в чем дело, мне высказывали самые разные версии «да тебя досят», «взломать хотят» и еще не пойми чего. А просто у Апача стоял Timeout 300 дефолтный и кол-во одновременных процессов выходящее далеко за пределы ОЗУ. Перекопав интернет (на digital ocean вот ничего не нашел) я посмотрел сколько чего и куда, настроил и теперь сервер стабильно работает несколько месяцев не вылетая.

            Про компиляции и многосерверные архитектуры пока отложим, потому что это уже вообще слишком высоко.

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

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

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

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

            Константин, тему за 9.99 $ :)

  • Что-то не получается….

    Сделал все как у вас описано, даже попробовал в виде обычного плагина сделать, но во всех случаях выдает ошибку на строке

    require WPMU_PLUGIN_DIR . ‘/selena-network/signup/wp-signup.php’;

    Пробовал пути по другому прописывать, например, просто wp-signup.php, т.к. этот файл лежит в одной папке с самим плагином

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

    Плагин произвёл при активации 20 символов неожиданного вывода. Если вы заметите ошибку «headers already sent», проблемы с RSS-лентами или другие неполадки, попробуйте деактивировать или удалить этот плагин.

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

    Версия вордпресс 4.2.1

    Файл wp-signup.php и wp-activate.php скачал ваши с гитхаба

    Может я что-то не так делаю?

    У вас есть готовый пример всех файлов, которые нужно просто залить в папку mu-plugins, скажем так версия для чайников типа меня))

    А то боюсь я тут сам не разберусь.

    • Если ошибка на строчке require WPMU_PLUGIN_DIR . ‘/selena-network/signup/wp-signup.php’;, то нужно убедиться, что такой php-файл действительно есть :)

  • Скажите пожалуйста, у меня в мультисайте нет подпапки му-плагинс я не совсем понял куда неоходимо все это писать

    • Вы можете создать эту директорию.

    • Да, по умолчанию этой папки нету. Ее нужно сделать самостоятельно, как и все содержимое.

  • Souz2000

    Здравствуйте. Шорткод нужно создавать в function.php темы?

    • Лучше в mu-plugins.

      • Souz2000

        То есть в /selena-network/signup/plugin.php?

      • Souz2000

        И тот же вопрос про обработчики, внутри которых отправлять письма через wp_mail() – их так же mu-plugins?

        • Весь этот функционал, как и сказал выше Константин, лучше в mu-plugins держать, хотя, если по какой-то причине удобнее в теме, то можно и там (например, тема заточена под какой-то один конкретный сайт). Как лучше организовать файлы внутри mu-plugins или папке с темой это уже на усмотрение разработчика. Я положил в /selena-network/signup/plugin.php. Это вероятно не самое «правильное» решение. Потому что можно все это написать с помощью классов, а не просто плейн-функциями (это сложнее). Также можно и Composer использовать и тогда расположение файлов тоже отличаться будет, например, при использовании стандарта PSR-4 и автозагрузчиков.

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

  • Souz2000

    И еще вопрос – про разные роли регистрируемых. В системе есть разные созданные роли, и при регистрации пользователи выбирали роль сами – форма регистрации генерировалась темой. Сейчас, когда я создал свою signup страницу для регистрации на конкретном сайте сети – выбора ролей нету, есть только поля username и email adress, что и понятно. Как можно в новой форме вывести роли пользователей на выбор?

    • Список доступных ролей можно получить из базы данных. Но, понятное дело, при регистрации новых аккаунтов пользователи не должны иметь возможность выбрать себе роль «администратор» или что-то такое. Поэтому просто где-то в коде нужно создать отдельный массив со списком доступных ролей, которые можно выбрать (можно и внутри wp_options это где-то сохранять, но мне кажется лишнее). Внутри формы регистрации это список выводить. А при обработке формы проверять, есть ли выбранная роль в списке разрешенных и есть ли такая роль вообще и если все верно, то устанавливать эту роль новому аккаунту.