Ultimate Multisite 101

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

WordPress Multisite

Повече от нас е запознати с стандартната инсталация на WordPress. Вие я създавате чрез административния панел на доставчика си хостинг или, за по-смелите, настройвате нов уеб сървър и база данни, сваляте основните файлове и започвате процеса на инсталация.

Това работи за милиони WordPress сайтове в света, но от гледна точка на агенция или хостинг доставчик нека поговорим за обем.

Въпреки че създаването на един WordPress сайт или дори стотин сайтове чрез автоматизиран административен панел е синхронизирано, скоро проблем ще започне да се появява, когато дойде управлението на тези сайтове. Ако не управлявате, вие сте основна цел за вредоносни софтуери (malware). Управление означава усилие и ресурси, и въпреки че има външни инструменти и плагини, които могат да помогнат при олесняване на управлението и администрирането на WordPress сайтове, фактот, че клиентите поддържат административен достъп, означава, че тези усилия лесно могат да бъдатdefeти.

В ядрото на WordPress има функция, наречена просто „Multisite“ (Мултисайт), която се проследява до 2010 г., когато беше пусна WordPress 3.0. Оттогава тя е преминала през няколко версии с цел въвеждане на нови функции и засилено подобрение на сигурността.

В основата си, WordPress multisite може да се представи по следното: Университетът поддържа една инсталация от WordPress, но всеки факулт има своя собствена WordPress страница.

За да разберем това по-добре, нека разгледаме някои от основните термини, които са налични не само в документацията на Ultimate Multisite, но и в цялото WordPress съобщество.

Мрежата (The Network)

В терминологията на WordPress, multisite мрежа е мястото, където можеш да управляваш множество подсайтове от един единен dashboard. Въпреки че създаването на multisite мрежа се различа между хостинг доставчиците, крайният резултат обикновено е няколко допълнителни инструкции в файла wp-config.php, които да кажат на WordPress, че работи в този специфичен режим.

Има няколко различни разлика между multisite мрежата и самостоятелна инсталация на WordPress, които ще обсъдим кратко.

Поддомен срещу поддиректория (Subdomain vs. Subdirectory)

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

В конфигурацията за subdirectory (поддиректории) мрежовите сайтове наследяват път въз основа на основното доменско име. Например, мрежовият сайт с име 'site1' ще има пълния си URL като https://domain.com/site1. В конфигурацията за subdomain (поддомени), мрежовият сайт ще има собствен subdomain, deriving от основното доменско име. Така сайтът с име 'site1' ще има пълния си URL като https://site1.domain.com/.

Въпреки че и двете опции са абсолютно валидни избори, използването на subdomains предлага определени предимства, но също така изисква повече мислене и планиране в архитектурата му.

По отношение на DNS, използването на subdirectories (поддиректории) представлява относително лесен проблем. Тъй като мрежовите сайтове са просто деца на основния път, трябва да съществува само една запис за доменско име за основното доменско име. За subdomains предизвикателството е малко по-сложно и изисква отделна CNAME запис за всеки мрежов сайт или wildcard (*) запис в DNS записи.

Друго поле за разглеждане е свързано със SSL и издаването и използването на SSL сертификати. В конфигурацията за subdirectory може да се използва един сертификат за домен, тъй като мрежовите сайтове са просто поддирекции на основното доменско име. Така сертификатът за domain.com ще осигури адекватно SSL за https://domain.com/site1, https://domain.com/site2 и така нататък.

В конфигурацията с поддомен (subdomain) използването на дигитална сертификат SSL с вайлдкард (wildcard) е един от най-честите варианти. Този тип SSL сертификат осигурява криптиране за основния домен и неговите поддомени. Следователно, вайлдкард SSL сертификат ще осигури криптиране за https://site1.domain.com, https://site2.domain.com и дори за самото https://domain.com.

Макар че съществуват други опции, те често са ограничени по обхват и приложение и изискват допълнителна конфигурация и разглеждане на подходящо дали са подходящи.

Плагинове и теми

WordPress отнема не само нещо от потребителя, поне от гледна точка на клиента. При самостоятелна инсталация на WordPress, ако администраторът на сайта инстали лош плагин или не поддържа своята инсталация актуална, единствената жертва и пострадал е той самият. Но когато администраторът на сайт инстали лош плагин в multisite инсталация, жертвата става всеки сайт, инсталиран в мрежата.

Поради това, когато е конфигурирано като multisite WordPress отстранява възможността за администраторите на сайтовете да инстали плагини и теми и вместо това пренасочва тази възможност към новосъздадена роля на администратор на мрежата или „супер админ“. Тази привилегирана роля след това решава дали да позволи на администраторите на мрежовите сайтове да виждат или достъпват менюто за плагини в своята dashboard и, ако да, дали тези разрешения се разпространяват върху активирането или деактивирането на плагините.

До този момент администратор на мрежата е отговорен за инсталиране на плагини и теми в мрежата и делегиране на права, за да се използват тези плагини и теми за сайтовете в мрежата. Администраторите на сайтовете не могат да инсталират плагини и теми или да имат достъп до плагини и теми, които не са им отменени за техния сайт.

Потребители и администратори

В WordPress Multisite всички сайтове в мрежата споделят една и съща база данни и следователно споделят и потребители, и роли, и възможности. Най-добрият начин да си представите това е че всички потребители са членове на мрежата, а не на конкретен сайт.

С тази идея може да бъде нежелано да се позволява създаването на потребители, заради което WordPress Multisite премахва тази възможност от администраторите на сайтовете и я премества към администратора на мрежата. В своя ред администраторът на мрежата може да делегира необходимите привилегии на администратора на сайта, за да му позволи да създава акаунти за потребители за собствения си сайт.

Повторяйки по-горе, въпреки че акаунтите на потребителите изглеждат свързани със сайта, те всъщност са отменени за мрежата и следователно трябва да бъдат уникални в цялата мрежа. Могат да има случаи, когато потребителските имена не могат да бъдат регистрирани поради тази причина.

Макар че това не е чуж концепция в корпоративните системи, тази единна източник за регистрация и автентикация на потребители често е трудно разбираема за хора, които са запознати с автономни инсталации на WordPress, където администрирането на потребителите е по-лесно.

Медии (Media)

В WordPress Multisite сайтове, които споделят една и съща база данни, поддържат отделни пътища в файловата система за медийни файлове.

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

Пермалинки (Permalinks)

По-рано споменахме, че конфигурацията с поддомен има специфични предимства пред конфигурацията с подката, и ето те: пътищата.

При конфигурация с подката, основният сайт (първият сайт, създаден при установяване на мрежата) и подсайтовете на мрежата трябва да имат един и същ път, водещ от името на домейна. Това има потенциал за много конфликти.

За публикации се добавя задължителен път /blog/ към основния сайт, за да се предотврати сблъсък с сайтовете в мрежата. Това означава, че красивите пермалинки като ‘Име на публикацията’ ще бъдат представени като domain.name/blog/post-name/.

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

Статични страници

При конфигурацията с subdirectory потенциалът за конфликти при имено се разширява до статичните страници, тъй като основният сайт и мрежовите страници споделят един и същ път.

За да предотвратим това, WordPress предоставя начин да блокира определени имена на сайтове, така че те не да конфликтират с имената на първия сайт. Обикновено администраторът на мрежата въвежда коренните пътища за страниците на основния сайт.

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

Регистрация

В настройките на мрежата на WordPress Multisite има няколко нови опции за регистрация на потребители, които позволяват на новите и съществуващите потребители да създават страници.

В противополози на самостоятелните инсталации на WordPress, мрежовите страници не поддържат обикновените опции за позволяване на регистрация на потребители или назначаване на тези регистрации на роли.

Когато се създават потребителски акаунти, тези акаунти се генерират на ниско ниво (network level). Така вместо да принадлежат някой конкретен сайт, те принадлежат на цялата мрежа. Това има някои отличителни предимства и недостатъци.

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

До тази степен, когато потребителя влиза, той влиза в мрежата и в крайна сметка е логван във всеки сетев сайт също, за да осигури безпроблемно преживяване. Ако вашият нов сайт беше базиран на абонамент, това би било идеалното решение и резултат.

Въпреки това, ако предполаганото предназначение и целта на multisite е да предлага различни сетеви сайтове, които няма връзка помежду си, почти винаги се изискват външни или допълнителни плагини за манипулиране на роли на потребителите.

Домейн и SSL

Нека поговорим за инсталация на WordPress Multisite, която почти ни избяга – Wordpress.com. Това е най-обширният пример за WordPress multisite и демонстрира неговите огромни възможности за персонализиране и приспособяване към конкретна цел.

Днес в модерния интернет използването на SSL е почти задължително, а администраторите на мрежови WordPress Multisite скоро ще се сблъскат с тези предизвикателства.

При конфигурацията с subdomain (поддомен), сайтовете се създават въз основа на основното доменни име. Така сайтът, наречен „site1“, се създава като „site1.domain.com“. Използвайки wildcard SSL сертификат, мрежовият администратор може успешно да реши тази проблема и да предостави възможности за SSL криптиране за цялата мрежа.

WordPress Multisite съдържа функция за картиране на домени (domain mapping), която позволява свързване на сайтовете в мрежа с кастомни доменни имена или доменни имена, различни от основното домен名 на мрежата.

За администраторите на мрежи това представлява допълнителен слой сложност както при конфигурацията на доменните имена, така и при издаването и поддържането на SSL сертификати.

До тази степен, въпреки че WordPress Multisite предоставя начин да се свърже www.anotherdomain.com с „site1“, мрежовият администратор остава с предизвикателството да управлява външно DNS записи и да им прилага SSL сертификати.

Ultimate Multisite

С разлика между самостоятелна инсталация на WordPress и Multisite инсталация разбираме, нека видим как Ultimate Multisite е终ната арсенал за предоставяне на Websites as a Service (WaaS).

Въведение

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 прави настройката изключително лесна за осигуряване на мапиране на домените (domain mapping) и SSL сертификати с помощта на интеграциите си с множество популярни хостинг провайдори, както и услуги като Cloudflare и cPanel.

Така че, използвайки един от тези провайдори или като поставите Ultimate Multisite зад Cloudflare, аспекти като управление на домените и SSL сертификатите стават почти несложни.

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

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

Темите предлагат подобна функционалност, позволявайки да се активират или скриват определени теми по време на създаването на сайта.

Агенции ще имат спокойствие с Ultimate Multisite, което им позволява да правят това, в което са най-добри – да डिजाइन сайтове от изключение.

Случай 2: Нишовия доставчик

Има стара поговорка, която гласи: „прави едно нещо и го прави добре“. За много специалисти това означава създаването на продукт или услуга около една основна идея.

Може би ви е зафан тиър голфър, който промотира сайтове към клубове, или може да сте зафан в киберспортивни игри, предлагайки сайтове на кланови. Индивидуално лице, което промотира услуга за резервации към ресторанти, например?

По много причини бихте искали да предоставяте услуги, базирани на общ фреймуърк и платформа. Може да е така, че сте проектирали или инвестирали в персонализирани плагини за предоставяне на необходимата функционалност, или може да е случаят, че най-добрите практики в индустрията изискват някакъв стандартизиран подход към дизайна.

Една от иновативните функции на Ultimate Multisite е използването на шаблонни сайтове (template sites). Шаблонният сайт е един, където тема е инсталирана и активирана, необходимите плагини са инсталирани и активирани, а са създадени примери за публикации или страници. Когато клиент създаде нов сайт въз основа на шаблона, съдържанието и настройките на шаблона се копират към новосъздадения сайта.

За доставчик на нишови сайтове и услуги това предлага безпрецедентна предимство в способността бързо да създаваш готов сайт с персонализирани плагини и дизайн. Клиентът трябва само да предостави най-минималния вход за завършване на услугата.

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

Случай 3: WordPress Web Hosting

Има множество начини за хостинг на WordPress сайтове, но рядко е толкова просто като предоставяне на уеб пространство на клиента с предварително инсталирана версия на WordPress. Това е така, защото трябва да се съберат няколко решения и разгледания, за да се предостави смислена услуга.

Ultimate Multisite блести в тази област, предлагайки цялостно решение под ключ за хостинг на WordPress сайтове. Решението включва основните механизми за предоставяне на абонаментни услуги, събиране на плащания, форми за покупка (checkout forms), купоните за отстъпка и комуникация с клиентите.

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

За разработчиците, които искат да интегрират с Ultimate Multisite, решението също предлага всеобхватния RESTful API и Webhooks за уведомяване на събития.

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

Съображения за архитектурата

Макар че това не е пътеводител, следните точки могат да помагат при правилното избор на технологии за поддържане на инсталация на Ultimate Multisite.

Споделено срещу отделно хостинг (Shared vs. Dedicated Hosting)

За съжаление не всички доставчици на хостинг са равни, и някои практикуват екстремна плътност на сървъра. Ниските ценови предложения обикновено генерират приходи чрез максимизиране на плътността на сървъра. Като така, инсталацията на Ultimate Multisite може да бъде само един от стотици сайтове на един и същ сървър.

Без подходящи защити от доставчика, сайтовете на споделен сървър усещат проблема с „шумен съсед“ (noisy neighbour). Това означава, че сайтът на същия сървър, който консумира толкова много ресурси, като другите сайтове трябва да се конкурират за останалите ресурси. Често това се проявява в неудобни скорости или неспособност да отговорят своевременно.

Като доставчик на уеб хостинг самият си, потокът от ефекти ще означава, че вашите клиенти усещат лоши скорости, ниско рангиране и високи проценти от отказване (bounce rates), което често води до загуба на клиенти, които търсят услуги другаде.

В кратките думи, евтино не означава добро.

Ultimate Multisite е известен с това, че работи с няколко добри хостинг доставчици и се интегрира добре в техния дигитал среда, предоставя функции като картиране на домените (domain mapping) и автоматично SSL. Тези доставчици ценят производителността и предлагат по-висок клас услуга от общия хостинг.

За списък с съвместими доставчици и пълни инструкции за настройка за всеки от тях, моля, проверете документацията за Съвместими доставчици (Compatible Providers).

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

Ultimate Multisite не е бавно приложение, напротив, е изключително бързо. Въпреки това, той работи само толкова добре, колкото основното приложение и инфраструктура му позволяват, като използва само това, което има достъп.

Замислете следното: Вие сте администратор на мрежата на инсталация с Ultimate Multisite, която има 100 сайта. Някои от тези сайтове работят добре и привличат голям брой посетители всеки ден.

Това сценарий би бил различен в по-малък мащаб, например един до пет сайта, но скоро ще се появят проблеми с мащабируемостта (scale).

Ако не бъде наблюдавани, един самото Ultimate Multisite сайт ще е отговорен за изпълнение на заявките на всички посетители на сайтовете. Тези заявки могат да бъдат за динамични PHP страници или статични активи като стилове (stylesheets), JavaScript или медийни файлове. Независимо дали имате един или сто сайта, тези задачи стават повтарящи се, монотонни и безсмислени. Не е необходимо да използвате процесорната мощност и памет за обработка на PHP файл, когато изходът е същата статична информация за всяка заявка.

Аналогично един заявка за PHP или HTML страница генерира множество следващи заявки за скриптове, стилове и изображения. Тези заявки са насочени директно към вашия сървър на Ultimate Multisite.

Лесно може да решите тази проблема чрез ъпгрейд на сървъра, но това не решава втори проблем – географските закъснения (latencies). Само множество сървъри в различни локации могат правилно да адресират този проблем.

Затова повечето мрежови администратори използват решения за фронтенд кеширане и разпределени мрежи за съдържание (CDN), за да изпълнят заявките за статични страници. Удовлетворяването на тези заявки и предоставянето на активите преди заявката да достигне сървъра спестява процесорните ресурси, елиминира забавяния, предотвратява ненужни ъпгрейди и максимизира инвестициите в технологии.

Ultimate Multisite включва сложен Cloudflare add-on, който позволява на мрежовите администратори да поставят своите инсталации зад Cloudflare и да използват не само неговите възможности за кеширане, а и DNS хостинг, SSL сертификати и механизми за сигурност.

Резервни копия (Backups)

Можеш да попиташ 50 души за съвети относно резервните копия и да получиш 50 различни мнения за стратегии на резервиране. Отговорът е: зависи от ситуацията.

Неспоржено е, че се изискват резервни копия и че почти не е възможно тези резервни копия да не бъдат управлявани от доставчика, особено ако предлагат услуга с управление (managed service). Следователно клиентите ще се обърнат към администратора на мрежата за предоставяне и управление на тази услуга. Който администратор на мрежата се търси е напълно друг проблем.

За целите на този раздел нека се съгласим, че резервната копия са снимка на състоянието на системата в конкретен момент, когато запращането на резервната копия е започнало. Прости като дума: каквото и да е състояние на системата в момента на резервното копиране, това състояние се улавя и запазва в резервната kopiya.

С този разбиране отговорът относно как да постигнете резервни копия и което е най-добро за вашата среда ще зависи в голяма степен от вашите изисквания и способността на хостинг доставчика да ги отговори. Въпреки това, подреждането на опциите по степени на мнение – от най-мнението до най-малко мнения – следва насоки за вас.

Снимки (Snapshots)

Снимките са "сиверите пули" за резервните копия, защото са лесни, несложни (докато не искате да възстановите) и просто работят. Въпреки това те изискват помощ от доставчика ви и в основно се прилагат само ако имате VPS (Виртуална частна сървър) или подобен продукт. Няколко доставчици, посочени в документацията ни за „Съвместими доставчици“, предлагат резервни копия, които не изискват допълнително намеса или разглеждане от администратора на мрежата.

Въвместо традиционните резервни копия, които целят файлове и бази данни, снимката (snapshot) цели цялата диска. Това означава, че не само данните на сайта се запазват в снимката, но и операционната система и конфигурацията. За много хора това е значително предимство, тъй като нов софтуерен инстанс може почти незабавно да бъде създаден от снимка и задействан за заместване на неработещ инстанс. Подобно, процесът на възстановяване за извличане на файлове просто изисква да прикрепите изображението на снимката като диск към съществуващ инстанс, за да могат файловете да бъдат достъпни и копирани.

Снимките може да имат допълнителна цена от доставчика на хостинг, но те са като застраховка срещу инциденти.

Външни скриптове (External Scripts)

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

Не можем да препоръчаме един скрипт пред друг, но общата ни съвет е да направите няколко теста за резервно копиране и възстановяване, за да се уверите, че резултатите са желаните, и да „бъдете сигурни“ чрез непрекъснато оценяване на скрипта и неговата функционалност, особено там, където се прилага някаква стратегия за диференциално резервно копиране (differential backup strategy).

Трябва да се отбележи, че тези скриптове, докато работят, увеличават натоварването на системата, което трябва да бъде взето предвид.

Плагини

В WordPress почти няма проблем, който не може да бъде решен с плагин, и ако управлението на външни скриптове не е вашата стил, то плагинът може да бъде следващата най-добра опция.

Докато плагините варират по опции и функции, те повечето изпълняват една и съща функция – като копират файловете и данните от базата данни на WordPress. След това функционалността се различава: някои плагини могат да изпраща резервните копия към външни услуги като Google Drive или Dropbox, или към някакъв съвместим сървър за обекти (object storage service) като S3, Wasabi и други. По-обхватните плагини предлагат диференцирани резервни копия или някаква стратегия за резервиране само на променените данни, за да се спестят разходите за външно съхранение.

При избора на плагина внимавайте да проверите дали той е съвместим с multisite (мултисайт). поради начина му на работа, докато процесите на резервиране работят, можете да очаквате временно натоварване на сървъра до момента завършване на процеса.

Домейн и SSL

Много е обсъдено вече относно доменните имена в режим с поддомени (subdomain) за multisite. Почти универсално решение за администраторите на мрежи е да се използват wildcard DNS записи.

Тази ви добавена DNS запис ще разреши поддомени като ‘site1.domain.com’ и ‘site2.domain.com’ към IP адрес 1.2.3.4, което поддържа Ultimate Multisite и по-широко WordPress Multisite с режим на поддомени (subdomain) mode.

Това може да работи перфектно за HTTP, защото целевият хост се чете от HTTP заглавия, но рядко е уебсайтото толкова просто тези дни, когато сигурните HTTPS транзакции са почти задължителни.

Въпреки това има лесни опции за SSL сертификати. В режим на subdirectory може да се използва обикновен домейн сертификат. Те са лесно и безплатно достъпни от хостинг доставчици, които могат да използват безплатния сервис LetsEncrypt или друг източник. В противен случай те са търговски налични от властите, ако можете да генерирате заявката за подписване на сертификата (CSR).

За режим на subdomain използването на wildcard SSL сертификат ще се съчетае перфектно с wildcard домейн и ще позволи на сертификата да бъде авторитетен за основния домен и всички subdomains без допълнителна конфигурация.

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

Ultimate Multisite излизат от кутия предоставя решение за тази проблема, демонстрирайки нашият опит с нуждите на WordPress multisites. Активирането на този прост add-on ще позволи на Ultimate Multisite да използва вашите Cloudflare credentials за автоматично добавяне на DNS записи за мрежовите сайтове в Cloudflare и настройване на техния режим на „proxied“ (проксиран). По този начин всяко мрежово подсайт, когато бъде създаден, ще има пълната защита и ползите от Cloudflare, включително SSL.

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

За много хора използването на Cloudflare е лесен вариант. Клиентът просто трябва да постави дойнейната си в Cloudflare, да насочи CNAME към коренния домен на Ultimate Multisite и да свърже (map) домейната си в Ultimate Multisite, за да започне да използва собственото си име на домейн.

Вътре в това основите трябва да се търсят алтернативни решения, което е причина за Ultimate Multisite да препоръчва списък с Съвместими Провайдове (Compatible Providers). Това е така, защото процесите за настройка на DNS и SSL могат да бъдат недълги. Въпреки това, с интеграцията на Ultimate Multisite с тези провайдори сложността се намалява много, а процедурата става автоматизирана.

Плагини (Plugins)

Много е вероятно да имате нужда от допълнителни плагини за предоставяне на функционалност на вашите клиенти или мрежовите сайтове. Работят ли всички плагини с WordPress Multisite и Ultimate Multisite? Това зависи.

Въпреки че повечето плагини могат да се инсталират в WordPress Multisite, активирането и лицензирането варира от автор до автор.

Сложността е в начина, по който се прилагат лицензите при някои плагини, които изискват лиценз на база всяко домейн. Това означава, че за някои плагини администраторът на мрежата трябва ръчно да активира лиценза за всеки плагин на всеки нов сайт.

Затова може да е най-добре да се проверите с автора на плагината как точно ще работи той с WordPress Multisite и дали има никакви специални изисквания или процедури за лицензиране.