Ultimate Multisite 101

Ultimate Multisite — це плагін для WordPress Multisite, який дає змогу пропонувати клієнтам WaaS, тобто веб-сайти як послугу (Websites as a Service). Перш ніж зануритися в деталі й дізнатися, як Ultimate Multisite може допомогти вашому бізнесу та клієнтам, потрібно засвоїти базові поняття.

WordPress Multisite

Більшість із нас добре знайомі зі звичайною установкою WordPress. Ви або створюєте її через панель керування хостинг-провайдера, або, для хоробріших, налаштовуєте новий веб-сервер і базу даних, завантажуєте основні файли та починаєте процес встановлення.

Це чудово працює для мільйонів WordPress-сайтів по всьому світу, але з погляду агенції чи хостинг-провайдера давайте поговоримо про масштаби.

Створити один WordPress-сайт або навіть сотню через автоматизовану панель керування — справа нескладна. Але проблеми з'являються, коли доходить до управління цими сайтами. Залишені без нагляду, вони стають легкою мішенню для шкідливого ПЗ. А управління потребує зусиль і ресурсів, і хоча є зовнішні інструменти й плагіни для спрощення адміністрування WordPress-сайтів, той факт, що клієнти мають адміністративний доступ, означає, що всі ці зусилля можуть бути зведені нанівець.

У своєму ядрі WordPress має функцію під назвою «Multisite», яка бере початок ще з 2010 року, коли вийшов WordPress 3.0. Відтоді вона отримала чимало оновлень, спрямованих на додавання нових можливостей та посилення безпеки.

По суті, WordPress Multisite можна уявити так: університет має єдину установку WordPress, але кожен факультет підтримує власний WordPress-сайт.

Щоб краще зрозуміти це твердження, розгляньмо базову термінологію, яка використовується не лише в документації Ultimate Multisite, а й загалом у спільноті WordPress.

Мережа

У термінах WordPress мережа multisite — це середовище, де кількома підсайтами можна керувати з однієї панелі керування. Хоча процес створення мережі multisite відрізняється залежно від хостинг-провайдера, результатом зазвичай є кілька додаткових директив у файлі wp-config.php, які повідомляють WordPress, що він працює в цьому специфічному режимі.

Є кілька суттєвих відмінностей між мережею multisite та окремою установкою WordPress, які ми коротко розглянемо.

Піддомени vs. підкаталоги

Одне з перших рішень, яке вам потрібно буде прийняти — чи буде установка multisite працювати з підкаталогами, чи з піддоменами. Ultimate Multisite однаково добре працює з обома варіантами, але між цими двома конфігураціями є деякі архітектурні відмінності.

У конфігурації з підкаталогами мережеві сайти успадковують шлях на основі основного доменного імені. Наприклад, мережевий сайт з назвою «site1» матиме повну URL-адресу https://domain.com/site1. У конфігурації з піддоменами мережевий сайт матиме власний піддомен, похідний від основного доменного імені. Отже, сайт з назвою «site1» матиме повну URL-адресу https://site1.domain.com/.

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

З погляду DNS використання підкаталогів є відносно простим завданням. Оскільки мережеві сайти є просто дочірніми елементами батьківського шляху, потрібен лише один запис доменного імені для основного домену. Для піддоменів завдання дещо складніше й вимагає або окремого CNAME-запису для кожного мережевого сайту, або запису з підстановним знаком (*) у DNS-записах.

Ще один аспект, який варто врахувати, — це SSL та видача й використання SSL-сертифікатів. У конфігурації з підкаталогами можна використовувати один доменний сертифікат, оскільки мережеві сайти є просто шляхами основного доменного імені. Тому сертифікат для domain.com цілком забезпечить SSL для https://domain.com/site1, https://domain.com/site2 тощо.

У конфігурації з піддоменами одним із найпоширеніших варіантів є використання wildcard SSL-сертифіката. Цей тип SSL-сертифіката забезпечує шифрування для домену та його піддоменів. Таким чином, wildcard SSL-сертифікат забезпечить шифрування для https://site1.domain.com, https://site2.domain.com і самого https://domain.com.

Хоча існують й інші варіанти, вони часто обмежені за обсягом і застосуванням та потребують додаткової конфігурації й оцінки придатності.

Плагіни та теми

Що WordPress дає, те він і забирає — принаймні з погляду клієнта. В окремій установці WordPress, якщо адміністратор сайту встановить поганий плагін або не підтримуватиме свою установку в актуальному стані, єдиною жертвою цього буде він сам. Однак адміністратор сайту, який встановлює поганий плагін на установці multisite, ставить під загрозу кожен сайт у мережі.

З цієї причини, коли WordPress налаштований як multisite, він забирає в адміністраторів сайтів можливість встановлювати плагіни та теми, натомість передаючи цю можливість новоствореній ролі мережевого адміністратора або «суперадміна». Ця привілейована роль може потім вирішувати, чи дозволяти адміністраторам мережевих сайтів бачити або мати доступ до меню плагінів у їхній панелі керування і, якщо так, чи поширюються такі дозволи на активацію або деактивацію плагінів.

Таким чином, мережевий адміністратор відповідає за встановлення плагінів і тем у мережі та делегує дозволи на використання цих плагінів і тем мережевим сайтам. Адміністратори сайтів не можуть встановлювати плагіни й теми або отримувати доступ до плагінів і тем, не призначених їхньому сайту.

Користувачі та адміністратори

У WordPress Multisite усі мережеві сайти використовують одну базу даних і, відповідно, спільних користувачів, ролі та можливості. Найточніше це можна описати так: усі користувачі є членами мережі, а не якогось конкретного сайту.

З огляду на це може бути небажано дозволяти створення користувачів, і тому WordPress Multisite забирає цю можливість у адміністраторів сайтів і передає її мережевому адміністратору. У свою чергу, мережевий адміністратор може делегувати необхідні привілеї адміністратору сайту, щоб дозволити йому створювати облікові записи користувачів для свого сайту.

Повторюючи сказане вище: хоча облікові записи користувачів виглядають так, ніби належать конкретному сайту, насправді вони виділені мережі й тому мають бути унікальними в межах мережі. Можуть траплятися випадки, коли імена користувачів недоступні для реєстрації саме з цієї причини.

Хоча це не чужа концепція для корпоративних систем, таке єдине джерело реєстрації та автентифікації користувачів часто важко зрозуміти людям, звиклим до окремих установок WordPress, де адміністрування користувачів дещо простіше.

Медіа

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

Стандартне розташування WordPress (wp-content/uploads) залишається; однак його шлях змінюється, щоб відображати унікальний ID мережевого сайту. Відповідно, медіафайли для мережевого сайту відображаються як wp-contents/uploads/site/[id].

Постійні посилання

Раніше ми згадували, що конфігурація з піддоменами має суттєві переваги над конфігурацією з підкаталогами, і ось одна з них: шляхи.

У конфігурації з підкаталогами основний сайт (перший сайт, створений під час формування мережі) і мережеві підсайти повинні ділити один і той самий шлях від доменного імені. Це може призвести до великої кількості конфліктів.

Для записів до основного сайту додається обов'язковий шлях /blog/, щоб запобігти конфліктам із мережевими сайтами. Це означає, що красиві постійні посилання, такі як «Назва запису», будуть відображатися як domain.name/blog/post-name/

У конфігурації з піддоменами ця дія не потрібна, оскільки кожен мережевий сайт має повне доменне відокремлення й тому не залежить від єдиного шляху. Натомість вони підтримують власні окремі шляхи на основі свого піддомену.

Статичні сторінки

У конфігурації з підкаталогами можливість конфліктів імен поширюється на статичні сторінки, оскільки основний сайт і мережеві сайти ділять один шлях.

Щоб запобігти цьому, WordPress надає можливість додати певні назви сайтів до чорного списку, щоб вони не конфліктували з назвами першого сайту. Зазвичай мережевий адміністратор вводить кореневі шляхи сторінок основного сайту.

У конфігурації з піддоменами можливість конфліктів імен зменшується завдяки піддомену, оскільки він унікальний для мережевого сайту й жодним чином не пов'язаний з основним сайтом.

Реєстрація

У налаштуваннях мережі WordPress Multisite доступні кілька нових опцій реєстрації користувачів, що дозволяють новим і існуючим користувачам створювати сайти.

На відміну від окремих установок WordPress, мережеві сайти не мають звичних опцій для дозволу реєстрації користувачів або призначення цим реєстраціям ролей.

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

Наприклад, уявіть, що ваш WordPress Multisite займається новинами та інформацією. Ви створюєте multisite, а потім створюєте мережеві сайти для фінансів, технологій, розваг та інших тематик, зберігаючи загальний контроль над плагінами й темами. Кожен мережевий сайт, у свою чергу, матиме значно більший рівень контролю над зовнішнім виглядом і користувацьким досвідом свого мережевого сайту, ніж могли б забезпечити кастомні типи записів або звичайні категорії записів.

Таким чином, коли користувач входить у систему, він входить у мережу й автоматично входить на кожен мережевий сайт, забезпечуючи безперебійний досвід. Якщо ваш новий сайт працює за підпискою, це буде ідеальним рішенням і результатом.

Однак якщо призначення multisite полягає в тому, щоб пропонувати різнорідні мережеві сайти, які не мають зв'язку один з одним, майже завжди потрібні зовнішні або додаткові плагіни для маніпулювання ролями користувачів.

Домен і SSL

Поговоримо про установку WordPress Multisite, яка майже вислизає від нашої уваги — WordPress.com. Це найбільш масштабний приклад WordPress Multisite, який демонструє його широкі можливості налаштування та адаптації для виконання конкретних завдань.

Сьогодні в сучасному інтернеті використання SSL є майже обов'язковим, і мережеві адміністратори WordPress Multisite швидко стикаються з цими викликами.

У конфігурації з піддоменами сайти створюються на основі кореневого доменного імені. Тому сайт з назвою «site1» буде створений як «site1.domain.com». Використовуючи wildcard SSL-сертифікат, мережевий адміністратор може успішно вирішити цю проблему й забезпечити можливості SSL-шифрування для мережі.

WordPress Multisite містить функцію прив'язки доменів, яка дозволяє асоціювати мережеві сайти з кастомними доменними іменами або доменними іменами, відмінними від кореневого домену мережі.

Для мережевих адміністраторів це створює додатковий рівень складності як у конфігурації доменних імен, так і у видачі та підтримці SSL-сертифікатів.

Таким чином, хоча WordPress Multisite надає можливість прив'язати www.anotherdomain.com до «site1», мережевий адміністратор залишається з проблемою зовнішнього управління DNS-записами та впровадження SSL-сертифікатів.

Ultimate Multisite

Тепер, коли ми зрозуміли відмінності між окремою установкою WordPress і установкою Multisite, давайте подивимося, як Ultimate Multisite стає найкращим арсеналом для надання веб-сайтів як послуги.

Вступ

Ultimate Multisite — це ваш швейцарський армійський ніж, коли справа доходить до створення веб-сайту як послуги (WaaS). Подумайте про Wix.com, Squarespace, WordPress.com, а потім уявіть, що ви володієте власним таким сервісом.

Під капотом Ultimate Multisite використовує WordPress Multisite, але робить це так, що не лише вирішує безліч проблем, з якими стикаються мережеві адміністратори з установками multisite, але й розширює можливості, дозволяючи підтримувати широкий спектр сценаріїв використання.

У наступних розділах ми розглянемо деякі типові сценарії використання та особливості, необхідні для їх підтримки.

Сценарії використання

Випадок 1: Агенція

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

Для агенцій Ultimate Multisite представляє неймовірну цінність завдяки своїм можливостям розміщувати й керувати кількома веб-сайтами на єдиній платформі. Тим більше для агенцій, які стандартизують свої дизайни на певних темах, таких як GeneratePress, Astra, OceanWP чи інших, — вони можуть використовувати можливості Ultimate Multisite для автоматичної активації цих тем для кожного нового сайту.

Аналогічно, з огляду на численні пропозиції агентського ціноутворення для поширених і популярних плагінів, використання Ultimate Multisite дозволяє агенціям максимально використовувати наявні інвестиції, забезпечуючи спільну платформу, з якої плагіни можна встановлювати, підтримувати й використовувати.

Найімовірніше, буде потрібна конфігурація з кастомними доменами, і, на щастя, Ultimate Multisite робить надзвичайно простим прив'язку доменів та SSL-сертифікатів завдяки інтеграціям із низкою популярних хостинг-провайдерів, а також із такими сервісами, як Cloudflare та cPanel.

Таким чином, використовуючи одного з цих провайдерів або розміщуючи Ultimate Multisite за Cloudflare, такі аспекти, як управління доменами й SSL-сертифікатами, стають досить тривіальними.

Агенції, які віддають перевагу суворому контролю над створенням сайтів, оцінять легкість, з якою вони можуть створювати сайти та асоціювати сайти з клієнтами й тарифними планами через зручний інтерфейс Ultimate Multisite.

Суворий контроль над плагінами й темами підтримується на рівні кожного продукту через інтуїтивні інтерфейси Ultimate Multisite, що дозволяють робити плагіни й теми доступними або прихованими, а також визначати їх стан активації при створенні нового сайту.

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

Агенції знайдуть спокій з Ultimate Multisite, що дозволить їм робити те, що вони роблять найкраще — створювати винятковий дизайн веб-сайтів.

Випадок 2: Нішевий провайдер

Є стара приказка: «Роби одну справу, але роби її добре». Для багатьох спеціалістів це означає створення продукту чи послуги навколо однієї основної ідеї.

Можливо, ви захоплений гольфіст, який просуває веб-сайти для клубів, або ви завзятий кіберспортсмен, який надає веб-сайти для кланів. А може, ви пропонуєте сервіс бронювання для ресторанів?

З багатьох причин ви хотіли б надавати послуги на основі єдиного фреймворку та платформи. Можливо, ви розробили або інвестували в спеціалізовані плагіни для забезпечення необхідної функціональності, або галузеві найкращі практики вимагають певного стандартизованого підходу до дизайну.

Однією з інноваційних функцій Ultimate Multisite є використання шаблонних сайтів. Шаблонний сайт — це сайт, де тема встановлена й активована, необхідні плагіни встановлені й активовані, а також створені зразкові записи або сторінки. Коли клієнт створює новий сайт на основі шаблону, вміст і налаштування шаблону копіюються на новостворений сайт.

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

Залежно від вимог можуть підійти як конфігурації з підкаталогами, так і з піддоменами, і в такому разі архітектурний вибір буде між простим SSL-сертифікатом для підкаталогів або wildcard SSL-сертифікатом для піддоменів.

Випадок 3: WordPress веб-хостинг

Існує безліч способів хостингу WordPress-сайтів, але рідко це так просто, як надати клієнту веб-простір із попередньо встановленою версією WordPress. Це тому, що ряд рішень і міркувань повинні зійтися разом, щоб забезпечити змістовну послугу.

Ultimate Multisite відмінно справляється в цій сфері, надаючи комплексне рішення «під ключ» для хостингу WordPress-сайтів. До рішення входять основні механізми для надання підписних послуг, збору платежів, форм оформлення замовлення, знижкових купонів і комунікації з клієнтами.

Значна частина внутрішньої роботи, необхідної для правильної установки, конфігурації та підтримки WordPress Multisite, полегшується Ultimate Multisite настільки, що мережевим адміністраторам потрібно враховувати лише аспекти, що стосуються їхнього сервісу чи ніші, такі як рівні продуктів, ціноутворення та сервісні пропозиції.

Для розробників, які бажають інтегруватися з Ultimate Multisite, рішення також пропонує комплексний RESTful API та Webhooks для сповіщень про події.

Без залежності від безлічі зовнішніх плагінів і ліцензій Ultimate Multisite надає багатофункціональне рішення, порівнянне з такими сервісами, як Wix, Squarespace, WordPress.com та інші.

Архітектурні міркування

Хоча це не є вичерпним посібником, наступні пункти мають слугувати орієнтиром для правильного вибору технологій для підтримки установки Ultimate Multisite.

Спільний vs. виділений хостинг

На жаль, не всі хостинг-провайдери однакові, і деякі практикують надмірну щільність серверів. Бюджетні провайдери зазвичай отримують дохід, максимізуючи щільність серверів. Таким чином, ваша установка Ultimate Multisite може бути лише одним із кількох сотень сайтів на тому самому сервері.

Без належних запобіжних заходів з боку провайдера, сайти на спільному сервері стикаються з проблемою «галасливого сусіда». Тобто сайт на тому ж сервері споживає так багато ресурсів, що інші сайти змушені боротися за залишки. Часто це проявляється як повільні сайти або такі, що не відповідають вчасно.

Як провайдер веб-хостингу, ви відчуєте ці наслідки: ваші клієнти матимуть низьку швидкість, низький рейтинг сторінок і високий показник відмов, що часто призводить до відтоку клієнтів, які шукають послуги деінде.

Коротко кажучи, дешево не означає добре.

Ultimate Multisite, як відомо, працює з низкою хороших хостинг-провайдерів і добре інтегрується з їхнім середовищем для забезпечення таких функцій, як прив'язка доменів і автоматичний SSL. Ці провайдери цінують продуктивність і надають послуги вищого класу, ніж спільний хостинг.

Для переліку сумісних провайдерів і повних інструкцій з налаштування для кожного, будь ласка, перегляньте документацію «Сумісні провайдери».

Міркування щодо продуктивності

Ultimate Multisite не є повільним додатком — навпаки, він надзвичайно швидкий. Однак він працює лише настільки добре, наскільки дозволяє базовий додаток та інфраструктура, і може використовувати лише те, до чого має доступ.

Розгляньте це: ви мережевий адміністратор установки Ultimate Multisite зі 100 сайтами. Деякі з цих сайтів успішні й щодня приваблюють чимало відвідувачів.

Цей сценарій виглядав би інакше в меншому масштабі, скажімо, від одного до п'яти сайтів, але незабаром проблеми масштабу стануть очевидними.

Без належної уваги єдиний сайт Ultimate Multisite буде відповідальним за обробку запитів усіх відвідувачів усіх сайтів. Ці запити можуть бути на динамічні PHP-сторінки або статичні ресурси, такі як стилі, JavaScript чи медіафайли. Чи це один сайт, чи сто — ці завдання стають повторюваними, монотонними й марнотратними. Немає необхідності використовувати потужність процесора та пам'ять для обробки PHP-файлу, коли результат — та сама статична інформація для кожного запиту.

Аналогічно, один запит на PHP або HTML-сторінку, у свою чергу, генерує кілька наступних запитів на скрипти, стилі та зображення. Ці запити спрямовані безпосередньо на ваш сервер Ultimate Multisite.

Можна легко вирішити цю проблему, оновивши сервер, але це не вирішує вторинну проблему — географічні затримки. Лише кілька серверів у кількох локаціях можуть належним чином вирішити цю проблему.

З цієї причини більшість мережевих адміністраторів використовують рішення для фронтенд-кешування та мережі доставки контенту (CDN) для обробки запитів на статичні сторінки. Обробка цих запитів і надання ресурсів до того, як запит досягне сервера, економить обчислювальні ресурси, усуває затримки, уникає непотрібних оновлень і максимізує інвестиції в технології.

Ultimate Multisite включає потужний додаток Cloudflare, який дозволяє мережевим адміністраторам розміщувати свої установки за Cloudflare і використовувати не лише його можливості кешування, але й DNS-хостинг, SSL-сертифікати та механізми безпеки.

Резервне копіювання

Можна запитати 50 людей про поради щодо резервного копіювання й отримати 50 різних думок про стратегії резервного копіювання. Відповідь — залежить.

Що не оспорюється — це те, що резервні копії необхідні й майже немислимо, щоб ними не керував провайдер, особливо той, що пропонує керовану послугу. Відповідно, клієнти очікуватимуть від мережевого адміністратора надання й управління цією послугою. До кого звернеться мережевий адміністратор — це вже інша проблема.

Для цілей цього розділу погодимось, що резервна копія — це копія стану системи на момент ініціювання резервного копіювання. Простіше кажучи, яким би не був стан системи на момент резервного копіювання, цей стан фіксується й зберігається в резервній копії.

З цим розумінням відповідь на питання, як здійснювати резервне копіювання й що найкраще для вашого середовища, значною мірою залежатиме від ваших вимог і здатності хостинг-провайдера задовольнити ці вимоги. Однак у порядку від найбільш до найменш суб'єктивного, наведені нижче варіанти мають надати певне керівництво.

Знімки (Snapshots)

Знімки — це срібні кулі резервного копіювання, тому що вони прості, нескладні (поки ви не захочете відновити) і «просто працюють». Однак це потребує певної допомоги від вашого провайдера й здебільшого застосовується лише якщо у вас є VPS (віртуальний приватний сервер) або подібне. Кілька провайдерів, перелічених у нашій документації «Сумісні провайдери», пропонують резервне копіювання, що не потребує подальшого втручання чи уваги з боку мережевого адміністратора.

Там, де традиційні резервні копії націлені на файли та бази даних, знімок націлений на весь диск. Це означає, що не лише дані сайту фіксуються в знімку, але й операційна система та конфігурація. Для багатьох це є суттєвою перевагою, оскільки нову систему можна майже миттєво створити зі знімка й ввести в експлуатацію для заміни несправного екземпляра. Аналогічно, процес відновлення для отримання файлів вимагає лише підключення образу знімка як диска до існуючого екземпляра, щоб отримати доступ до файлів і скопіювати їх.

Знімки можуть передбачати додаткову оплату у хостинг-провайдера, але це страховий поліс від нещасних випадків.

Зовнішні скрипти

Схоже, немає нестачі в зовнішніх скриптах і рішеннях для резервного копіювання ресурсів WordPress і MySQL, і вони добре працюватимуть для Ultimate Multisite, оскільки це плагін WordPress, що використовує файлову систему й базу даних WordPress. Таким чином, рішення, яке робить резервні копії WordPress-сайтів, адекватно покриє потреби Ultimate Multisite.

Ми не можемо рекомендувати один скрипт над іншим, але наша загальна порада — провести кілька тестів резервного копіювання й відновлення, щоб переконатися, що результати відповідають очікуванням, і «бути впевненим напевно», постійно оцінюючи скрипт і його функціональність, особливо там, де застосовується певна форма стратегії диференційного резервного копіювання.

Слід зазначити, що ці скрипти під час роботи збільшать навантаження на систему, що варто враховувати.

Плагіни

Майже немає проблеми в WordPress, яку не можна було б вирішити за допомогою плагіна, і якщо управління зовнішніми скриптами — це не ваша чашка кави, тоді, можливо, плагін — наступний найкращий варіант.

Хоча плагіни відрізняються за опціями та функціями, вони здебільшого виконують ту саму функцію — створюють копію файлів WordPress і вмісту бази даних. Після цього функціональність відрізняється: деякі плагіни можуть відправляти резервні копії на зовнішні сервіси, такі як Google Drive або Dropbox, або на якийсь сумісний сервіс об'єктного сховища, такий як S3, Wasabi чи інші. Більш комплексні плагіни забезпечують диференційне резервне копіювання або певну стратегію для резервного копіювання лише даних, що змінилися, щоб заощадити на витратах на зовнішнє сховище.

При виборі плагіна обов'язково перевірте, чи він підтримує роботу з multisite. Через особливості його роботи, поки резервне копіювання виконується, можна очікувати тимчасове навантаження на сервер до завершення процесу.

Домен і SSL

Багато вже обговорювалось щодо доменних імен у режимі multisite з піддоменами. Майже універсальним рішенням для мережевих адміністраторів є використання wildcard DNS-записів.

Цей тип DNS-запису успішно розв'язуватиме піддомени, такі як «site1.domain.com» і «site2.domain.com», на IP-адресу 1.2.3.4, таким чином підтримуючи Ultimate Multisite і, в ширшому сенсі, WordPress Multisite у режимі піддоменів.

Це може чудово працювати для HTTP, оскільки цільовий хост зчитується з HTTP-заголовків, але рідко коли веб настільки простий у наші дні, коли безпечні HTTPS-транзакції є майже обов'язковими.

На щастя, є прості варіанти для SSL-сертифікатів. У режимі підкаталогів можна використовувати звичайний доменний сертифікат. Вони легко й безкоштовно доступні у хостинг-провайдерів, які можуть використовувати безкоштовний сервіс LetsEncrypt або інше джерело. В іншому випадку вони комерційно доступні від центрів сертифікації, якщо ви можете згенерувати запит на підпис сертифіката.

Для режиму піддоменів використання wildcard SSL-сертифіката ідеально поєднується з wildcard доменом і дозволяє сертифікату бути авторитетним для кореневого домену та всіх піддоменів без зайвої конфігурації.

Однак слід зазначити, що wildcard SSL-сертифікати можуть не працювати з такими сервісами, як Cloudflare, якщо ви не на корпоративному плані або не встановите запис у режим «лише DNS», у якому випадку все кешування та оптимізація обходяться.

«З коробки» Ultimate Multisite надає рішення цієї проблеми, демонструючи наш великий досвід роботи з потребами WordPress Multisite. Активація цього простого додатка дозволить Ultimate Multisite використовувати ваші облікові дані Cloudflare для автоматичного додавання DNS-записів для мережевих сайтів у Cloudflare і встановлення їхнього режиму на «proxied». Таким чином кожен мережевий підсайт при створенні матиме повний захист і переваги Cloudflare, включаючи SSL.

Залежно від характеру та призначення вашої установки Ultimate Multisite може виникнути потреба для клієнтів використовувати власні домени. У цьому випадку мережевий адміністратор повинен вирішити дві проблеми. Перша — хостинг доменного імені, і друга — SSL-сертифікати для домену.

Для багатьох використання Cloudflare є простим варіантом. Клієнту потрібно лише розмістити свій домен на Cloudflare, вказати CNAME на кореневий домен Ultimate Multisite і прив'язати свій домен в Ultimate Multisite, щоб почати користуватися перевагами свого кастомного доменного імені.

Поза цим потрібно шукати альтернативні рішення, тому Ultimate Multisite рекомендує список «Сумісних провайдерів». Це тому, що процес налаштування DNS і SSL може бути нетривіальним. Однак завдяки інтеграції Ultimate Multisite з цими провайдерами складність значно зменшується, а процедура автоматизується.

Плагіни

Дуже ймовірно, що вам знадобляться додаткові плагіни для забезпечення функціональності вашим клієнтам або мережевим сайтам. Чи всі плагіни працюють з WordPress Multisite і Ultimate Multisite? Ну, це залежить.

Хоча більшість плагінів можна встановити в WordPress Multisite, їхня активація та ліцензування відрізняються від автора до автора.

Проблема полягає в тому, як застосовується ліцензування: деякі плагіни вимагають ліцензування на основі кожного домену. Це означає, що для деяких плагінів мережевому адміністратору потрібно вручну активувати ліцензію для кожного плагіна на кожному новому сайті.

Тому найкраще перевірити у автора плагіна, як їхній плагін працюватиме з WordPress Multisite і які спеціальні вимоги чи процедури потрібні для його ліцензування.