Ultimate Multisite 101

Ultimate Multisite — это WordPress Multisite plugin, который позволяет вам предлагать клиентам 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, которые мы кратко обсудим.

Поддомен против подкаталога

Одно из самых первых решений, которое вам нужно будет принять, — будет ли 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-сертификата является одним из самых распространённых вариантов. Этот тип SSL-сертификата обеспечивает шифрование для домена и его поддоменов. Следовательно, wildcard SSL-сертификат обеспечит шифрование для https://site1.domain.com, https://site2.domain.com и самого https://domain.com.

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

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

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

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

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

Пользователи и администраторы

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

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

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

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

Медиафайлы

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

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

Постоянные ссылки

Ранее мы упоминали, что конфигурация subdomain имеет явные преимущества перед конфигурацией subdirectory, и вот одно из них: пути.

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

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

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

Статические страницы

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

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

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

Регистрация

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

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

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

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

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

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

Домен и SSL

Давайте поговорим об установке WordPress Multisite, которая почти ускользает от нашего внимания, — Wordpress.com. Это, безусловно, самый обширный пример Wordpress multisite, демонстрирующий его широкие возможности настройки и адаптации для выполнения определенной цели.

В наши дни в современном интернете использование SSL почти обязательно, и администраторы сетей WordPress multisite вскоре сталкиваются с этими вызовами.

В конфигурации subdomain сайты создаются на основе корневого доменного имени. Таким образом, сайт с меткой «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 — это ваш швейцарский нож, когда речь идет о создании Website as a Service (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 является использование сайтов-шаблонов. Сайт-шаблон — это сайт, где тема установлена и активирована, необходимые плагины установлены и активированы, а также созданы примерные записи или страницы. Когда клиент создает новый сайт на основе шаблона, содержимое и настройки шаблона копируются на вновь созданный сайт.

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

В зависимости от требований могут подойти конфигурации как subdirectory, так и subdomain; в этом случае архитектурный выбор будет между простым SSL-сертификатом для subdirectories или wildcard SSL-сертификатом для subdomains.

Сценарий 3: веб-хостинг WordPress

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

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

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

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

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

Архитектурные соображения

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

Общий и выделенный хостинг

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

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

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

Коротко говоря, дешево не значит хорошо.

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

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

Соображения производительности

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

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

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

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

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

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

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

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

Резервные копии

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

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

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

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

Снимки

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

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

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

Внешние скрипты

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

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

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

Плагины

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

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

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

Домен и SSL

Многое уже обсуждалось относительно доменных имён в режиме multisite subdomain. Почти универсальное решение для сетевых администраторов — использовать wildcard DNS-записи.

Такой тип DNS-записи успешно сопоставит subdomains, такие как ‘site1.domain.com’ и ‘site2.domain.com’, с IP-адресом 1.2.3.4, тем самым поддерживая Ultimate Multisite и, в более широком смысле, WordPress Multisite с использованием режима subdomain.

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

К счастью, для SSL-сертификатов есть простые варианты. В режиме subdirectory можно использовать обычный доменный сертификат. Они легко и бесплатно доступны у хостинг-провайдеров, которые могут использовать бесплатный сервис LetsEncrypt или другой источник. В противном случае их можно приобрести у центров сертификации, если вы можете сгенерировать запрос на подпись сертификата.

Для режима subdomain использование wildcard SSL-сертификата идеально сочетается с wildcard-доменом и позволяет сертификату быть действительным для корневого домена и всех subdomains без лишней настройки.

Однако следует отметить, что wildcard SSL-сертификаты могут не работать с такими сервисами, как Cloudflare, если вы не на корпоративном плане или не установите запись в режим только DNS; в этом случае всё кэширование и оптимизация обходятся стороной.

Ultimate Multisite из коробки предоставляет решение этой проблемы, демонстрируя наш большой опыт в потребностях WordPress multisites. Активация этого простого дополнения позволит 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 и какие особые требования или процедуры необходимы для его лицензирования.