Як створити власну сторінку реєстрації в wordpress multisite - wp magazine
Головна → Різне → Як створити власну сторінку реєстрації в WordPress Multisite
Режим Multisite дозволяє використовувати одну установку WordPress для декількох сайтів одночасно. При цьому кожен сайт отримує свої власні таблиці в базі даних з унікальним префіксом.
У режимі Multisite ядро WordPress починає вести себе трохи інакше і при переході по посиланню wp-login.php? Action = register відбудеться редирект на wp-signup.php. Це сторінка реєстрації вашої мережі, яка за замовчуванням є в WordPress.
Сторінка реєстрації за замовчуванням
Налаштування мережі в режимі Multisite
У більшості тим сторінка реєстрації виглядає не зовсім добре. Багато тем оформлення використовують CSS-фреймворки, наприклад, Bootstrap, і власні специфічні класи для стилізації різних елементів на сторінках, тому важко написати єдиний HTML, який підійде всім.
Але не варто впадати у відчай, якщо сторінка виглядає неохайно. Файл wp-signup.php відмінна річ на перших порах, коли немає часу опрацьовувати кожну деталь сайту - можна зосередитися на інших більш важливих сторінках і контенті.
Основний сайт мережі
За замовчуванням, WordPress відкриває сторінку реєстрації (wp-signup.php) на основному домені (сайті) мережі. Проте, можна створювати сторінки реєстрації для кожного сайту мережі, навіть якщо у них різні домени і теми.
Ми будемо розглядати випадок, коли на всіх сайтах мережі використовується одна тема, але на кожному з них є сторінка реєстрації. Сайти розрізняються мовою (англійська та українська), тому сторінка реєстрації буде виводитися на «рідному» мовою сайту. У разі, якщо сайти використовують різні теми, все буде залежати від того, які саме це теми, чи підійде їм однакова верстка (відмінна ситуація, яка може підштовхнути вас до уніфікації всіх своїх тем) або стоїть опрацьовувати сторінки індивідуально.
альтернатива functions.php
Файл functions.php знайомий багатьом користувачам WordPress завдяки подіям і фільтрів. за допомогою яких дуже просто вносити правки. У нашому випадку, з урахуванням того, що функціонал реєстрації розрахований на кілька сайтів, має сенс винести його в MU-плагіни.
Що таке MU-плагіни?
MU-плагіни (Must Use Plugins) завантажуються при відкритті будь-якого сайту мережі. Їх не можна відключити або включити в адміністративній частині WordPress, вони працюють завжди. Варто відзначити, що MU-плагіни завантажуються раніше звичайних плагінів, тим оформлення і до повного завантаження ядра WordPress, тому виклик деяких функцій може привести до фатальних помилок в PHP.
Подібна «рання» завантаження має і свої плюси. Скажімо, всередині будь-якої теми не можна чіплятися до деяких подій з плагінів, які спрацьовують ще до завантаження functions.php.
Поглянути на загальну картинку порядку завантаження WordPress і виникнення подій можна на сторінці Action Reference в Кодексі.
Порядок в файлах
MU-плагіни можуть містити будь-яку кількість файлів і структуру, яка здасться вам логічною. Я дотримуюся приблизно такої ієрархії:
У файлі load.php підключаються переклади і всі необхідні «плагіни»:
Всередині директорії selena-network зберігаються папки плагінів. У кожної є свій plugin.php. які ми і підключаємо в load.php. Це дає гнучкість і можливість миттєво відключати і включати окремі компоненти на робочому проекті в разі екстреної необхідності.
сторінка реєстрації
Розібравшись з тим, де і як ми будемо писати код, можна переходити до створення сторінки реєстрації.
Редирект на потрібну сторінку реєстрації
Щоб WordPress дізнався про нашу нову сторінку реєстрації і виробляв редирект саме на неї, якщо клікнути на посилання «Зареєструватися», використовується фільтр wp_signup_location. Його можна знайти всередині wp-login.php і саме він відповідає за редирект на wp-signup.php за замовчуванням.
Як ви пам'ятаєте, за замовчуванням, сторінка реєстрації відкривається на основному домені мережі. Саме тому тут використовується network_site_url ().
Функціонал wp-signup.php
Файл wp-signup.php містить велику кількість функцій і коду. Щоб побачити картину в цілому можна скористатися згортанням коду. Як правило, по-англійськи це називається «code folding».
Вміст файлу wp-signup.php
На самому початку файлу з 1 по 80 рядок (у версії 4.1.1) проводяться різні перевірки і висновок «старту» сторінки за допомогою get_header ().
Далі оголошуються безліч методів і перед тим, як ми почнемо працювати з ними, варто розібратися що робить кожна функція. Усередині багатьох з них часто використовуються інші функції з префіксом wpmu_. всі вони оголошуються в файлі wp-includes / ms-functions.php. Цей розділ важко зрозуміти не бачачи код самостійно. Нижче невеликий опис основних функцій на випадок, якщо у вас виникнуть труднощі.
У самому низу файлу 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 і непотрібні перевірки. У версії 4.1.1 це весь код з 1 по 80 рядок.
Тепер ми готові створити головну функцію для виведення форми реєстрації. Для цього всю логіку з рядка 646 і до самого кінця файлу перенесемо в функцію c назвою selena_network_signup_main. В самому кінці видалимо два зайвих закривають
У щойно створеної selena_network_signup_main () на самому початку оголосимо глобальну змінну active_signup. яку використовують всі інші методи з цього файлу. І додамо виклик події before_signup_form. яке ми видалили з самого початку файлу.
Тепер залишається лише змінити верстку в усіх місцях де це необхідно і сторінка реєстрації готова.
Висновок форми реєстрації
Другий варіант - створити в папці дочірньої теми шаблон сторінки page-signup.php. Замість слова «signup» можна використовувати унікальний ID, присвоєний сторінці. Всередині шаблону додати необхідну верстку і зробити виклик selena_network_signup_main () в потрібному місці.
В результаті моя сторінка реєстрації стала виглядати набагато краще і чистіше.
Власна сторінка реєстрації в WordPress Multisite
сторінка активації
За виведення сторінки активації відповідає файл wp-activate.php розташований в кореневій директорії WordPress. wp-activate.php можна так само повністю змінити. Процес схожий з тим, що ми вже робили для wp-signup.php.
Сторінка активації в WordPress Multisite
Скопіюємо файл wp-activate.php до себе в MU-плагіни і підключимо його в mu-plugins / selena-network / signup / plugin.php.
Видалимо всі непотрібні перевірки і require - з 1 по 69 рядок в WordPress 4.1.1. В самому кінці приберемо виклик get_footer (). Час, що залишився вміст перенесемо в функцію selena_network_activate_main ().
Цікаво зауважити, що тут перед завантаженням WordPress (wp-load.php) оголошувалася константа WP_INSTALLING. Її наявність змушує WordPress не завантажувати плагіни.
Як і у випадку зі сторінкою реєстрації залишається лише виправити верстку там, де це необхідно. Також можна змінити текст виведених повідомлень (в цьому випадку не забудьте додати текстовий домен своїх MU-плагінів в усі функції-перекладачі, за замовчуванням він ніде не встановлено).
Готову функцію можна використовувати на заздалегідь створеній сторінці через шорткод або окремий шаблон в дочірньої темі.
Власна сторінка активації в WordPress Multisite
Після, в залежності від функції, викликається wpmu_signup_user _notification () або wpmu_signup_blog _notification (). Обидві функції мають схожий функціонал - генерують і відправляють лист з посиланням активації, але приймають різні аргументи. В обох є фільтри для «перехоплення» події.
Залишається лише написати свої обробники, всередині яких відправляти листи через wp_mail (). а в самому кінці обов'язково віддавати false. щоб WordPress не відправив лист активації двічі - одне ваше, інше - лист за замовчуванням з посиланням на wp-activate.php.
Якщо ви відправляєте листи через SMTP-сервер або кількість реєстрацій дуже велике, слід задуматися про те, щоб не відправляти листи миттєво. Замість цього можна додавати Cron-завдання за допомогою WordPress Cron.
Закриваємо доступ до wp-signup.php і wp-activate.php
Створивши свої власні сторінки реєстрації та активації, необхідно буде закрити «оригінали». Наприклад, якщо на сторінці реєстрації є додаткові поля, які необхідно обов'язково заповнити. Також багато WordPress сайти піддаються спам-реєстрацій.
Вирішити дві проблеми одним дією можна попросивши Apache віддавати 404 в разі спроби відкриття цих сторінок. Для цього потрібно лише прописати пару додаткових RewriteRule в ваш файл-конфігурацію або .htaccess.
висновок
Для цієї та багатьох інших «проблем» пов'язаних з WordPress в інтернеті є безліч рішень. Наприклад, для створення сторінок реєстрації та активації деякі пропонують переписувати оригінальні wp-signup.php і wp-activate.php. Цього не варто робити, тому що в разі поновлення WordPress ви втратите всі зміни, внесені в файли, а також не зможете, перевірити цілісність ядра за допомогою WP-CLI.
При розробці будь-якого доповнення, теми або рішення слід витратити трохи часу на те, щоб розібратися з тим, що відбувається всередині WordPress. Для цього є безліч корисних дебаг-інструментів.
Для автоматичного призначення різних ролей новим користувачам можна використовувати плагін Multisite User Management.
І те ж питання про обробники, всередині яких відправляти листи через wp_mail () - їх так само mu-plugins?
Весь цей функціонал, як і сказав вище Костянтин, краще в mu-plugins тримати, хоча, якщо з якоїсь причини зручніше в темі, то можна і там (наприклад, тема заточена під якийсь один конкретний сайт). Як краще організувати файли всередині mu-plugins або папці з темою це вже на розсуд розробника. Я поклав в /selena-network/signup/plugin.php. Це ймовірно не саме «правильне» рішення. Тому що можна все це написати за допомогою класів, а не просто плейн-функціями (це складніше). Також можна і Composer використовувати і тоді розташування файлів теж відрізнятися буде, наприклад, при використанні стандарту PSR-4 і Автозавантажувач.
Але все це дуже на розсуд кінцевого розробника, тому що я стільки різних плагінів і тим бачив і скрізь хто як хоче той так і пише. Звичайно, краще слідувати стандартам або якийсь інший логіці, щоб через місяць можна було розібратися де що. І новий розробник не посивів побачивши код.
І ще питання - про різні ролі реєстрованих. В системі є різні створені ролі, і при реєстрації користувачі вибирали роль самі - форма реєстрації генерировалась темою. Зараз, коли я створив свою signup сторінку для реєстрації на конкретному сайті мережі - вибору ролей немає, є тільки поля username і email adress, що й зрозуміло. Як можна в новій формі вивести ролі користувачів на вибір?
Раз в тиждень, тільки все найновіше про WordPress і ніякого спаму!