Ultimate Multisite 101

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

The WordPress Multisite

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

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

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

В ядре WordPress есть функция, просто названная «Multisite», которая восходит к 2010 году, когда был запущен WordPress 3.0. С тех пор она получила ряд ревизий, направленных на добавление новых функций и усиление безопасности.

В сущности, WordPress multisite можно представить так: университет поддерживает одну установку WordPress, но каждый факультет управляет своим собственным сайтом.

Чтобы разложить это утверждение, давайте рассмотрим некоторые основные термины, которые присутствуют не только в документации Ultimate Multisite, но и в сообществе WordPress.

The Network

В терминах WordPress, сеть multisite — это место, где несколько подсайтов можно управлять с одной панели управления. Хотя создание сети multisite отличается у разных хостинг‑провайдеров, конечный результат обычно состоит из нескольких дополнительных директив в файле wp-config.php, чтобы WordPress знал, что он работает в этом конкретном режиме.

Существует ряд отличительных различий между сетью multisite и автономной установкой WordPress, которые мы кратко обсудим.

Subdomain vs. Subdirectory

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

В конфигурации подкаталогов сетевые сайты наследуют путь, основанный на основном доменном имени. Например, сетевой сайт с названием «site1» будет иметь полный URL https://domain.com/site1. В конфигурации поддоменов сетевой сайт будет иметь свой собственный поддомен, выведенный из основного доменного имени. Таким образом, сайт с названием «site1» будет иметь полный URL https://site1.domain.com/.

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

В терминах DNS использование подкаталогов представляет относительно простую задачу. Поскольку сетевые сайты являются просто дочерними элементами родительского пути, для основного доменного имени необходимо только одно доменное имя. Для поддоменов задача несколько сложнее, требуя либо отдельную запись CNAME для каждого сетевого сайта, либо запись wildcard (*) в DNS‑записях.

Еще один аспект, который стоит учитывать, — это SSL и выдача и использование сертификатов SSL. В конфигурации подкаталогов можно использовать один сертификат домена, поскольку сетевые сайты являются просто путями основного доменного имени. Таким образом, сертификат для domain.com будет адекватно обеспечивать SSL для https://domain.com/site1, https://domain.com/site2 и так далее.

В конфигурации поддоменов использование wildcard SSL‑сертификата является одним из самых распространенных вариантов. Такой тип сертификата обеспечивает шифрование для домена и его поддоменов. Поэтому wildcard SSL‑сертификат обеспечит шифрование для https://site1.domain.com, https://site2.domain.com и самого https://domain.com.

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

Plugins and Themes

То, что WordPress даёт, оно также отнимает, по крайней мере, с точки зрения клиента. В автономной установке WordPress, если администратор сайта устанавливает плохой плагин или не обновляет свою установку, единственной жертвой и потерей этого действия является он сам. Однако, если администратор сайта устанавливает плохой плагин в установку multisite, он создает жертву для каждого сайта, установленного в сети.

По этой причине, когда WordPress настроен как multisite, он убирает у администраторов сайтов возможность устанавливать плагины и темы и вместо этого передаёт эту возможность новому сетевому администратору или роли «супер‑админ». Эта привилегированная роль затем может решить, разрешать ли администраторам сетевых сайтов видеть или получать доступ к меню плагинов в их панели управления, и, если да, распространяются ли такие разрешения на активацию или деактивацию плагинов.

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

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

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

Media

Когда сетевые сайты используют одну базу данных в WordPress Multisite, они сохраняют отдельные пути в файловой системе для медиа‑файлов.

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

Permalinks

Мы упоминали ранее, что есть отличительные преимущества поддоменов над подкаталогами, и здесь они: пути.

В конфигурации подкаталогов основной сайт (первый сайт, созданный при создании сети) и сетевые подсайты должны делить один и тот же путь, ведущий от доменного имени. Это может привести к множеству конфликтов.

Для записей к главному сайту добавляется обязательный путь /blog/, чтобы предотвратить конфликты с сетевыми сайтами. Это означает, что красивые постоянные ссылки, такие как «Post name», будут представлены как domain.name/blog/post-name/.

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

Static Pages

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

Чтобы предотвратить это, WordPress предоставляет способ добавить в черный список определённые имена сайтов, чтобы они не конфликтовали с именами первого сайта. Обычно сетевой администратор вводит корневые пути страниц основного сайта.

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

Registration

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

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

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

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

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

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

Domain and 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 является окончательным арсеналом для предоставления Сайтов как услуги.

Introduction

Ultimate Multisite — ваш швейцарский нож, когда речь идёт о создании Сайтов как услуги (WaaS). Подумайте о Wix.com, Squarespace, WordPress.com, а затем подумайте о владении собственным сервисом.

Под капотом Ultimate Multisite использует WordPress Multisite, но делает это таким образом, который не только решает множество проблем, с которыми сталкиваются сетевые администраторы при установках multisite, но и повышает возможности, позволяя поддерживать широкий спектр вариантов использования.

В следующих разделах мы рассмотрим некоторые распространённые варианты использования и необходимые соображения для их поддержки.

Use Cases

Case 1: An Agency

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

Для агентств Ultimate Multisite представляет невероятную ценность благодаря своим возможностям хостинга и управления несколькими сайтами на одной платформе. Особенно это актуально для агентств, которые стандартизируют свои дизайны на определённых темах, таких как GeneratePress, Astra, OceanWP или другие, которые могут использовать возможности Ultimate Multisite для автоматической активации этих тем для каждого нового сайта.

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

Скорее всего, будет желательным использовать конфигурацию, и, к счастью, Ultimate Multisite делает это невероятно простым, облегчая сопоставление доменов и сертификаты SSL с помощью своих интеграций с рядом популярных хостинг‑провайдеров, а также сервисов, таких как Cloudflare и cPanel.

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

Агентства, которые предпочитают строгий контроль над созданием сайтов, оценят простоту, с которой они могут создавать сайты и связывать их с клиентами и планами через упрощённый интерфейс Ultimate Multisite.

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

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

Агентства найдут спокойствие с Ultimate Multisite, позволяющим им делать то, что они делают лучше всего — создавать исключительные веб‑сайты.

Case 2: Niche Provider

Существует старая поговорка: «делай одну вещь и делай её хорошо». Для многих специалистов это означает создание продукта или услуги вокруг одной основной идеи.

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

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

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

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

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

Case 3: WordPress Web Hosting

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

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

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

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

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

Architecture Considerations

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

Shared vs. Dedicated Hosting

К сожалению, не все хостинг‑провайдеры равны, и некоторые практикуют экстремальную плотность серверов. Низкобюджетные провайдеры обычно генерируют доход, максимизируя плотность серверов. Поэтому ваша установка Ultimate Multisite может быть лишь одним из нескольких сотен сайтов на одном сервере.

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

Будучи собственным провайдером веб‑хостинга, вы столкнетесь с тем, что ваши клиенты будут испытывать низкую скорость, низкий рейтинг страниц и высокий показатель отказов, что часто приводит к оттоку клиентов, которые ищут услуги в другом месте.

Вкратце, дешёвый не означает хороший.

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

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

Performance Considerations

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

Рассмотрим это: вы являетесь сетевым администратором установки Ultimate Multisite с 100 сайтами. Некоторые из этих сайтов работают хорошо и привлекают определённое количество посетителей каждый день.

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

Если оставить без внимания, один сайт Ultimate Multisite будет отвечать за выполнение запросов всех посетителей сайтов. Эти запросы могут быть для динамических PHP‑страниц или статических ресурсов, таких как таблицы стилей, javascript или медиа‑файлы. Независимо от того, один или сто сайтов, эти задачи становятся повторяющимися, монотонными и бесполезными. Нет необходимости использовать мощность процессора и память для обработки PHP‑файла, когда вывод одинаковый статический для каждого запроса.

Аналогично, один запрос к PHP или HTML‑странице генерирует несколько последующих запросов к скриптам, таблицам стилей и изображениям. Эти запросы направлены напрямую на ваш сервер Ultimate Multisite.

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

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

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

Backups

Можно спросить 50 человек совета по резервным копиям и получить 50 разных мнений о стратегиях резервного копирования. Ответ — это зависит.

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

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

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

Snapshots

Снимки — это серебряные пули для резервного копирования, потому что они просты, несложны (пока вы не захотите восстановить) и «просто работают». Однако это требует некоторой помощи от вашего провайдера и в основном применимо только в случае, если у вас есть VPS (виртуальный частный сервер) или аналогичный. Несколько провайдеров, перечисленных в нашей документации «Compatible Providers», предлагают резервное копирование, не требующее дальнейшего вмешательства или рассмотрения со стороны сетевого администратора.

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

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

External Scripts

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

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

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

Plugins

Скорее всего, вам понадобится дополнительные плагины для предоставления функциональности вашим клиентам или сетевым сайтам. Работают ли все плагины с WordPress Multisite и Ultimate Multisite? Ну, это зависит.

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

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

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

Domain and 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 multisites. Активация этого простого дополнения заставит Ultimate Multisite использовать ваши учетные данные Cloudflare для автоматического добавления DNS‑записей для сетевых сайтов в Cloudflare и установки их режима в «проксируемый». Таким образом, каждый сетевой подсайт, при создании, будет иметь полную защиту и преимущества Cloudflare, включая SSL.

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

Для многих использование Cloudflare — это простой вариант. Клиенту нужно только разместить свой домен в Cloudflare, указать CNAME на корневой домен Ultimate Multisite и сопоставить свой домен в Ultimate Multisite, чтобы начать пользоваться своим пользовательским доменным именем.

Вне этого альтернативные решения необходимо искать, поэтому Ultimate Multisite рекомендует список Compatible Providers. Это потому, что процесс настройки DNS и SSL может быть не тривиальным. Однако благодаря интеграции Ultimate Multisite с этими провайдерами сложность значительно снижается, а процедура автоматизирована.