WordPress Multisite: hosting, subdomény a podadresáře

WordPress Multisite umožňuje provozovat mnoho webů z jedné instalace WordPressu: jedna sada souborů jádra, jeden adresář pluginů a šablon, jedna databáze, jeden pool procesů PHP a nad tím vším obrazovka Network Admin. Hodí se, když weby patří jednomu vlastníkovi, vypadají podobně a spravují se společně - weby fakult univerzity, franšíza, jazykové mutace, obchod s regionálními výlohami. Nehodí se, když weby spolu nesouvisejí, patří různým klientům nebo potřebují jiné pluginy a jinou míru rizika. Rozhodnutí, které se draze vrací, je podadresář (example.com/shop/), nebo subdoména (shop.example.com). Dále rozebereme, jak to udělat, co Multisite žádá od hostingu a kde vám tiše zkomplikuje život oproti několika samostatným instalacím.

Co Multisite doopravdy je#

Běžná instalace WordPressu má v databázi jednu sadu tabulek: wp_posts, wp_options, wp_comments a tak dál. Multisite toto uspořádání ponechá pro první web a pro každý další přidá očíslovanou kopii tabulek jednotlivého webu: wp_2_posts, wp_2_options, wp_3_posts a tak dále. Každý web má zhruba tucet vlastních tabulek. Několik tabulek je společných pro celou síť:

• wp_users a wp_usermeta - jeden seznam účtů pro celou síť. Člověk má jedno přihlášení a roli na každém webu dostává zvlášť.
• wp_blogs a wp_site - registr webů a sítí.
• wp_sitemeta - nastavení celé sítě, včetně seznamu super adminů a toho, které pluginy jsou aktivované pro celou síť.
• wp_signups a wp_registration_log - používají se, když si lidé smějí zakládat weby sami.

Soubory se dělí stejně. Kód je sdílený: jeden wp-content/plugins, jeden wp-content/themes, jedna kopie jádra. Nahrané soubory jsou oddělené a každý web kromě prvního zapisuje do wp-content/uploads/sites/<id>/. Nastavení, obsah, menu, widgety a aktivní šablona jsou u každého webu vlastní. Které pluginy jsou nainstalované, je rozhodnutí sítě; které z nich jsou aktivní, je rozhodnutí webu, pokud je super admin neaktivoval pro celou síť.

Ve sdílení je celé kouzlo. WordPress aktualizujete jednou, oprava zranitelnosti v pluginu dorazí na všechny weby ve stejnou chvíli a nový web je formulář, ne nový server. Je v tom ale i celé riziko, o kterém je řeč níže.

Terminologie matou. Síť (network) je celá instalace. Web (site) je jeden její člen. Super admin je role na úrovni sítě: instaluje pluginy a šablony, zakládá a maže weby a upravuje libovolné uživatele. Běžný administrátor webu v síti Multisite nemůže instalovat pluginy ani šablony vůbec, jen zapnout ty, které super admin zpřístupnil. Klienti, kteří čekají, že si budou instalovat vlastní pluginy, bývají nespokojení.

Subdomény, nebo podadresáře#

Tohle se volí jednou, při nastavení sítě, a WordPress pak už nedovolí volbu z rozhraní změnit. Pozdější přechod znamená upravit wp-config.php, přepisovací pravidla a adresy v tabulkách každého webu a hodně testovat, takže se rozhodněte hned.

Praktické rozdíly jsou tyto.

DNS a certifikáty. Síť na podadresářích nepotřebuje nic víc než DNS záznam, který pro hlavní doménu už máte, a jeden certifikát pokryje všechny weby. Síť na subdoménách potřebuje, aby se jméno každého webu překládalo na server a aby každé jméno pokrýval certifikát. Obvyklé řešení je wildcard záznam DNS *.example.com na stejnou adresu jako hlavní doména a wildcard certifikát, nebo certifikát na každé jméno. Wildcard certifikáty se běžně vystavují přes ověření v DNS, což vyžaduje, aby měl váš poskytovatel DNS API, které umí váš nástroj zavolat. O tom, co wildcard záznam pokryje a co ne, se dočtete v článku DNS záznamy srozumitelně, o obecné myšlence „jedno jméno na službu“ v článku subdomény pro servery.

Vyhledávače a identita. Vyhledávače do určité míry berou subdomény jako samostatné weby a podadresáře jako součást nadřazeného. Pokud jsou weby rubrikami jedné značky a chcete, aby sdílely pozice ve vyhledávání, hodí se lépe podadresáře. Pokud jde o samostatné projekty, které mají jen společné nadřazené jméno, je poctivější subdoména.

Kolize cest. V síti na podadresářích patří první segment cesty Multisite. Web s názvem blog zabere /blog/, takže stránka, kategorie nebo vlastní typ příspěvku na hlavním webu se stejným slugem blog s ním zkolidují. WordPress při zakládání webu odmítne část rezervovaných jmen (wp-admin, files, page, feed a podobně), ale nemůže znát všechny slugy, které jste použili v obsahu hlavního webu. Subdomény se tomuto problému úplně vyhnou.

Stáří instalace. Volbu podadresářů WordPress nabízí jen u čerstvé instalace nebo takové, která je mladší než měsíc, protože u zavedeného webu by se stávající trvalé odkazy mohly srazit s cestami nových webů. U sítí na subdoménách takové omezení není. Pokud převádíte dlouho žijící web a chcete podadresáře, nejdřív zkontrolujte všechny slugy nejvyšší úrovně.

Porty a netypické adresy. Multisite nepracuje spolehlivě, když adresa webu obsahuje nestandardní port, a obrazovka nastavení sítě na to upozorní. Provozujte ho na standardních portech za proxy.

Pravidlo, které se osvědčilo: pokud zvládnete wildcard záznam a certifikát pro něj a weby jsou v očích návštěvníka samostatné, použijte subdomény; pokud jsou weby rubrikami jednoho celku, nebo jste omezeni jedním DNS záznamem, použijte podadresáře. A ať zvolíte cokoli, každý web může později dostat vlastní doménu, jak popisuje část o domain mapping.

Zapnutí Multisite#

Začněte z fungujícího jednoduchého webu a čerstvé zálohy. Jak se k tomu dostat od nuly, popisuje článek ruční instalace WordPressu.

1. Přidejte do wp-config.php jeden řádek, nad komentář, který říká, že úpravy mají skončit:

define( 'WP_ALLOW_MULTISITE', true );

1. V administraci deaktivujte všechny pluginy (pluginy zasahující do přepisování adres nebo přesměrování další krok ruší; poté je znovu zapněte).
2. Otevřete Tools, poté Network Setup. WordPress nabídne volbu subdomén nebo podadresářů, název sítě a e-mail super admina.
3. Klikněte na Install. WordPress změny sám nezapíše. Zobrazí dva bloky kódu k vložení: konstanty pro wp-config.php a přepisovací pravidla pro .htaccess nebo webový server.

U sítě na subdoménách vypadá blok pro wp-config.php takto a vkládá se hned za řádek WP_ALLOW_MULTISITE:

define( 'MULTISITE', true );define( 'SUBDOMAIN_INSTALL', true );define( 'DOMAIN_CURRENT_SITE', 'example.com' );define( 'PATH_CURRENT_SITE', '/' );define( 'SITE_ID_CURRENT_SITE', 1 );define( 'BLOG_ID_CURRENT_SITE', 1 );

U sítě na podadresářích je jediný rozdíl v SUBDOMAIN_INSTALL, kde je false. Tato jediná konstanta je v kódu celým rozhodnutím mezi subdoménami a podadresáři, a proto jde později změnit, ale nikdy ne jedním řádkem: každá adresa v databázi byla zapsána pro původní uspořádání.

Pak nahraďte výchozí přepisovací pravidla WordPressu. Na Apache se v .htaccess pro síť na podadresářích použije:

RewriteEngine OnRewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]RewriteBase /RewriteRule ^index\.php$ - [L]# add a trailing slash to /wp-adminRewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]RewriteCond %{REQUEST_FILENAME} -f [OR]RewriteCond %{REQUEST_FILENAME} -dRewriteRule ^ - [L]RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]RewriteRule . index.php [L]

Síť na subdoménách z těchto pravidel vypustí volitelnou předponu s názvem webu:

RewriteEngine OnRewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]RewriteBase /RewriteRule ^index\.php$ - [L]RewriteCond %{REQUEST_FILENAME} -f [OR]RewriteCond %{REQUEST_FILENAME} -dRewriteRule ^ - [L]RewriteRule ^(wp-(content|admin|includes).*) $1 [L]RewriteRule ^(.*\.php)$ $1 [L]RewriteRule . index.php [L]

Na nginx žádný .htaccess není. Síť na subdoménách nepotřebuje nic zvláštního kromě try_files $uri $uri/ /index.php?$args; a server_name, který odpovídá wildcardu, zatímco síť na podadresářích přidává blok, který z cest administrace a PHP odstraní předponu webu:

if (!-e $request_filename) {    rewrite /wp-admin$ $scheme://$host$uri/ permanent;    rewrite ^(/[^/]+)?(/wp-.*) $2 last;    rewrite ^(/[^/]+)?(/.*\.php) $2 last;}

Jaký webový server váš hosting používá a jestli vůbec čte .htaccess, je první věc, kterou musíte zjistit, než začnete. Právě na kroku s přepisovacími pravidly ztroskotá většina nepovedených nastavení Multisite: všechny podweby vracejí 404 hlavního webu nebo se administrace zacyklí v přesměrování.

1. Po uložení obou souborů se přihlaste znovu (změní se cookies) a pak zapněte pluginy z Network Admin.

Pokud rozhraní nechcete, WP-CLI provede celý převod jedním příkazem, spuštěným z adresáře webu:

$ wp core multisite-convert --title="Example Network" --subdomains$ wp site list

Pro síť na podadresářích vynechte --subdomains. Příkaz zapíše konstanty a vytvoří síťové tabulky; přepisovací pravidla musí být na místě i tak.

Wildcard DNS pro sítě na subdoménách#

Aby se shop.example.com načetlo, musí se jméno překládat na server. Máte dvě možnosti: ručně vytvářet záznam A pro každý nový web, nebo jednou vytvořit wildcard záznam:

example.com.      3600  IN  A  203.0.113.10*.example.com.    3600  IN  A  203.0.113.10

Wildcard odpovídá každému jménu hlubokému jednu úroveň, které nemá vlastní záznam, takže shop.example.com i anything.example.com se přeloží, ale a.b.example.com ne. Výslovný záznam pro mail.example.com nebo www.example.com má vždy přednost před wildcardem, takže e-mail a další služby můžete nechat na vlastních adresách.

Na tato jména musí odpovídat i server. WordPress směruje podle hlavičky Host: když přijde požadavek na shop.example.com, vyhledá jméno hostitele v wp_blogs a načte ten web. Webový server proto musí všechna tato jména posílat do téhož adresáře WordPressu - výchozím virtuálním hostitelem nebo záznamem server_name *.example.com. Vyzkoušejte to dřív, než založíte skutečné weby:

$ dig +short shop.example.com203.0.113.10$ curl -sI https://shop.example.com/ | head -n 1

Pokud první příkaz nic nevypíše, wildcard záznam chybí nebo se ještě nerozšířil. Pokud vypíše adresu, ale druhý příkaz ukáže varování o certifikátu, DNS je v pořádku a jméno certifikát nepokrývá.

Na RE:NODE tarify aplikací a webhostingu obsahují slot reverzní proxy: nasměrujete záznam A na zobrazenou adresu a certifikát se vystaví a obnovuje automaticky. To se týká certifikátu pro jména, která tam připojíte. Netvrdíme, že wildcard jména nebo wildcard certifikáty jsou podporované, a nezveřejňujeme, kolik slotů proxy má který tarif, takže pokud plánujete síť na subdoménách s mnoha jmény, zeptejte se před stavbou podpory. Síť na podadresářích se otázce vyhne, protože jde jen o jedno jméno. Jak funguje část s certifikátem, vysvětluje článek vaše doména a její certifikát.

Zakládání webů, uživatelé a domain mapping#

Když síť běží, nové weby vznikají v Network Admin přes Sites a Add New, nebo přes WP-CLI:

$ wp site create --slug=shop --title="Shop" --email=admin@example.com$ wp site list --fields=blog_id,url,registered$ wp super-admin add alice$ wp plugin activate wordpress-seo --network$ wp theme enable twentytwentyfive --network

--slug se stane subdoménou nebo podadresářem podle typu sítě. wp theme enable --network zpřístupní šablonu všem webům, zatímco obyčejné wp theme enable <theme> --url=shop.example.com jen jednomu.

V Network Admin, v části Settings, jsou volby, na kterých nejvíc záleží:

• Registration: vypnuto, jen uživatelské účty, přihlášení uživatelé smějí zakládat weby, nebo obojí. Nechte vypnuto, pokud nepořádáte veřejnou službu, protože otevřená registrace webů rychle přitahuje spamové weby.
• Upload file types and size: síťový Max upload file size se nastavuje zde (pole fileupload_maxk, výchozí hodnota je malá, 1500 KB), odděleně od upload_max_filesize v PHP. Platí oba limity a vyhrává nižší. Viz nastavení php.ini, na kterých záleží.
• Menu settings: zda administrátoři webů vůbec uvidí nabídku Plugins.

Jedna konstanta, kterou stojí za to nastavit brzy, určuje, kam se dostane návštěvník, který požádá o neexistující web:

define( 'NOBLOGREDIRECT', 'https://example.com' );

Bez ní zobrazí překlep v subdoméně obecnou stránku „tento web neexistuje“.

Domain mapping znamená přidělit webu vlastní doménu, www.shop-example.net, místo jména pod doménou sítě. Od WordPressu 4.5 je to součástí systému a plugin není potřeba: v Network Admin upravte web a změňte jeho Site Address (URL) na novou doménu. Zbytek se děje mimo WordPress:

1. Nasměrujte záznam A nové domény na stejný server.
2. Ujistěte se, že webový server na toto jméno odpovídá a certifikát ho pokrývá.
3. Změňte Site Address v části Sites, Edit v Network Admin.
4. Proveďte hledání a nahrazení v tabulkách samotného webu, protože obsah stále obsahuje staré adresy:

$ wp search-replace 'shop.example.com' 'www.shop-example.net' \    --url=shop.example.com --network --dry-run

Nejdřív spusťte s --dry-run, přečtěte si počty a pak spusťte znovu bez něj. V síti na subdoménách znamená přemapovaná doména také samostatné přihlašovací cookie, takže uživatelé přihlášení na doméně sítě tam přihlášení nejsou. Některá nastavení také přidávají define( 'COOKIE_DOMAIN', '' );, aby WordPress nevnucoval cookie nadřazené doméně.

Co Multisite stojí na zdrojích#

Multisite výrazně nesnižuje spotřebu zdrojů na jeden web. Ušetří duplicitní místo na disku pro jádro, pluginy a šablony a práci s údržbou mnoha instalací. Všechno ostatní sdílí a sdílené znamená sporné.

Procesy PHP a paměť. Jeden web nebo sto, WordPress se při každém požadavku načte s aktivními pluginy a šablonou obsluhovaného webu. Paměť na požadavek závisí na tom, co je zapnuté na daném webu, ne na velikosti sítě. Všechny weby ale čerpají ze stejného poolu workerů PHP a stejného limitu paměti. Jeden vytížený web nebo pomalý plugin na jednom webu může zabrat workery, které potřebují ostatní. Článek kolik RAM potřebuje WordPress uvádí čísla na jeden web; pro síť sčítejte vytížené weby, ne všechny, a nechte rezervu na špičku toho nejvytíženějšího.

Databáze. Každý web přidává kolem tuctu tabulek, takže síť o 200 webech obsahuje hodně přes dva tisíce tabulek. Pro MySQL to není problém, ale nástroje a pluginy, které procházejí všechny tabulky - zálohovací pluginy, hledání a nahrazení napříč sítí, některé migrační skripty - zpomalují. WordPress sám má pojistku pro velké sítě: jakmile síť překročí 10 000 webů nebo uživatelů (práh wp_is_large_network, lze ho měnit filtrem), přeskakuje některé síťové počítací dotazy, které by jinak byly příliš pomalé. Na malém tarifu na tento limit sotva narazíte, ale efekt deseti tisíc autoloadovaných řádků v wp_options pocítíte mnohem dřív. Každý web při každém požadavku načítá své autoloadované volby, takže plugin, který nafoukne wp_options na jednom webu, zpomalí jen ten web, kdežto sdílené tabulky wp_users a wp_usermeta rostou s celou sítí a při každém přihlášení se na ně sahá.

Objektová cache. Trvalá objektová cache pomáhá Multisite víc než jednoduchému webu, protože každý požadavek provede alespoň pár dotazů do sdílených síťových tabulek. Klíče cache zahrnují ID webu, takže dobrý plugin objektové cache weby udrží oddělené. Nastavení popisuje článek objektová cache Valkey pro WordPress a rychlost WordPressu a cache pokrývá cache stránek, která musí v síti počítat se sítí, jinak podle jména hostitele vrací stránky jednoho webu místo druhého.

WP-Cron. Každý web má vlastní plán úloh uložený ve vlastní tabulce wp_<id>_options a WP-Cron se spouští ze zobrazení stránek každého webu zvlášť. Klidný web v síti o padesáti webech může dny nepublikovat naplánované příspěvky. Oprava přes skutečný cron z článku WP-Cron a skutečný cron platí dál, s jednou změnou: musíte spouštět splatné úlohy pro každý web, ne jen pro jeden. Při nastaveném DISABLE_WP_CRON to zvládne jediný řádek v cronu:

$ wp site list --field=url | xargs -I % wp --url=% cron event run --due-now

Spouštějte to každých pět minut. Každý web je nové nastartování WordPressu, takže u sítě o padesáti webech to chvíli trvá a po tu dobu to zatěžuje CPU. Pokud je podíl CPU ve vašem tarifu malý, spouštění rozložte v čase nebo rozdělte seznam. Karta Schedules v panelu RE:NODE je místo, kde se nastavuje úloha ve stylu cronu u tarifů, které ji mají.

Disk a nahrané soubory. Složky s nahranými soubory rostou po webech a nejsou sdílené, takže jeden web s velkou mediální knihovnou může zaplnit disk všem. V Network Admin lze nastavit kvótu místa pro nahrané soubory na web (blog_upload_space, výchozí 100 MB), což se vyplatí zapnout, pokud weby předáváte jiným lidem.

Pro orientaci: malá síť z několika lehkých webů poběží na tarifu, který by uživil jeden středně náročný samostatný web. Síť z desítek vytížených webů, stejně jako jakýkoli web s WooCommerce, patří na větší tarify, nebo na dedikovaný server, pokud to zátěž ospravedlňuje.

Kdy Multisite nepoužívat#

Multisite láká, protože vypadá jako zkratka ke správě mnoha webů. Je to kompromis a pro řadu případů špatný.

Weby patří různým lidem. Sdílený adresář pluginů, sdílená tabulka uživatelů a sdílená role super admina znamenají, že kdo řídí síť, řídí každý web. Klient, který si potřebuje nainstalovat vlastní plugin, nemůže. Klient, který potřebuje testovací kopii, jinou verzi PHP nebo obnovu jen svého webu, zjistí, že nic z toho není jednoduché.

Jeden web je mnohem rizikovější než ostatní. Zranitelný plugin nainstalovaný v síti je nainstalovaný všude, i když ho používá jediný web, a napadený účet super admina je napadená síť. Jeden infikovaný web se může dostat ke sdílené databázi i ke sdílenému adresáři s kódem. Zabezpečení je tu důležitější; začněte článkem zabezpečení WordPressu.

Potřebujete obnovu jednoho webu. Záloha sítě Multisite je záloha jedné databáze a jednoho stromu souborů. Vrátit jeden web na včerejšek znamená ručně exportovat jeho tabulky a složku uploads/sites/<id>/. WP-CLI tento export zvládnutelným způsobem usnadní:

$ wp db export shop-site.sql --tables=$(wp db tables --scope=blog --url=shop.example.com --format=csv)

Import takového souboru do živé sítě je místo, kde se dělají chyby. Pokud musí jít weby obnovovat nezávisle, samostatné instalace z toho udělají tlačítko místo zákroku.

Weby potřebují různý software. Stejná verze WordPressu, stejné verze pluginů, stejná verze PHP pro všechny. Pokud jeden web potřebuje starý plugin, který se na současném PHP rozbije, zdržuje ostatní. Pokud jeden potřebuje plugin nekompatibilní s Multisite - takových je mnoho, zejména těch, které zapisují vlastní tabulky nebo počítají s jedinou wp_options - nelze ho použít vůbec. Před závazkem si v dokumentaci každého pluginu ověřte podporu Multisite.

Weby mají nerovnoměrný provoz. Jedno spuštění, jeden virální příspěvek nebo jeden bot procházející archivy štítků jednoho webu zpomalí všechny, protože sdílejí workery, spojení s databází i paměť. Pokud byste museli jeden web omezit kvůli ostatním, neměly by ty weby sdílet pool procesů.

Chtěli jste jen přehlednou administraci. Pokud je skutečným cílem aktualizovat mnoho webů na jednom místě, dá se to udělat přes WP-CLI po SSH nebo správcovským panelem, aniž by se cokoli sdílelo. Samostatné instalace aktualizované skriptem jsou méně elegantní než Multisite a daleko snáz se izolují.

Multisite sedí, když jsou weby sourozenci: stejný vlastník, stejná rodina šablon, stejná sada pluginů, srovnatelný provoz a jeden člověk odpovědný za všechny. Mimo to jsou bezpečnějším výchozím řešením samostatné instalace.

Na RE:NODE je cesta se samostatnými instalacemi levná na vyzkoušení. Řada WordPress nainstaluje WordPress s wp-config.php už nastaveným na vlastní databázi MySQL a začíná od $5 měsíčně, přičemž každý tarif má vlastní sloty záloh a vlastní panel. Několik malých tarifů vám dá obnovu po webech, vlastní limity CPU a paměti pro každý a žádný společný dopad havárie, za cenu toho, že každý budete aktualizovat zvlášť. Přenos webu mezi instalacemi popisuje článek přesun WordPressu na nový hosting, který se hodí i tehdy, když později síť rozdělíte.

Přesun webu do sítě a ze sítě#

Přesun webů je okamžik, kdy Multisite přestává být úhledné. Existující samostatný web lze importovat vestavěnými Tools, Export a Import, které přenesou příspěvky, stránky a odkazy na média, nebo pluginem, který přenáší tabulky. Protože se předpona tabulek mění na wp_<id>_, prosté zkopírování databáze nefunguje: tabulky je třeba přejmenovat, upravit řádek wp_<id>_options, který ukládá role uživatelů (wp_<id>_user_roles), a opravit adresy.

Opačným směrem web ze sítě odchází takto: exportují se jeho tabulky, přejmenují se zpět na výchozí předponu, složka uploads/sites/<id>/ se zkopíruje do wp-content/uploads/ a pak se provede hledání a nahrazení cest a adres. Uživatele je nutné založit znovu, protože žijí ve sdílené tabulce wp_users. Naplánujte to dřív, než to budete potřebovat: je to skutečná cena za volbu Multisite pro weby, které se později mohou osamostatnit.

Řešení potíží#

Každý podweb ukazuje hlavní web nebo 404. Přepisovací pravidla jsou stará pravidla jednoduchého webu, nebo webový server neposílá jméno hostitele do tohoto adresáře WordPressu. Znovu použijte blok z Network Setup pro váš typ sítě a ověřte, že virtuální hostitel odpovídá na wildcard.

Smyčka přesměrování na `/wp-admin/`. Obvykle cookies. Ověřte, že DOMAIN_CURRENT_SITE přesně odpovídá hostiteli v adresním řádku (s www, nebo bez), smažte cookies domény a zkontrolujte, že define( 'COOKIE_DOMAIN', '' ); není nastaveno na hodnotu, která neodpovídá.

„Error establishing a database connection“ jen na jednom podwebu. Tabulky webu chybí nebo je špatná předpona - obvykle po ručním obnovení. Zkontrolujte, že wp db tables --url=shop.example.com vypisuje tabulky wp_<id>_. Pokud nefunguje celá síť, začněte článkem bílá obrazovka a chyby 500 ve WordPressu.

Po nastavení sítě zmizely pluginy. Pluginy byly pro krok nastavení deaktivované, jak má být. Znovu je zapněte v Network Admin, v části Plugins, a u každého rozhodněte, zda se má aktivovat pro celou síť.

Nové weby na subdoménách hlásí problém s certifikátem. DNS funguje, ale certifikát pokrývá jen hlavní doménu. Buď certifikát rozšiřte na wildcard, nebo do něj každé jméno přidejte před založením webu.

FAQ#

Dá se samostatný web WordPress později převést na Multisite?

Ano. Přidejte WP_ALLOW_MULTISITE, spusťte Tools, Network Setup (nebo wp core multisite-convert) a vložte vygenerované konstanty a přepisovací pravidla. Nejdřív udělejte zálohu. Sítě na podadresářích se nabízejí jen u instalací mladších než měsíc, takže starší web se převede na síť na subdoménách, pokud to ručně neobejdete.

Dá se potom přepnout mezi subdoménami a podadresáři?

Ne z rozhraní. Znamená to změnit SUBDOMAIN_INSTALL, přepisovací pravidla a každou uloženou adresu na každém webu. U sítě se skutečným obsahem je to projekt, takže volbu berte jako trvalou.

Zrychluje Multisite WordPress?

Ne. Požadavek na jeden web stojí zhruba tolik jako na samostatné instalaci plus pár dotazů do síťových tabulek. Zlepšuje se pracnost údržby, ne rychlost, a velká zátěž jednoho webu zpomaluje ostatní.

Může mít každý web své vlastní doménové jméno?

Ano, díky vestavěnému domain mappingu od WordPressu 4.5. Nasměrujte novou doménu na server, ujistěte se, že ji pokrývá webový server i certifikát, pak změňte Site Address v části Sites v Network Admin a spusťte hledání a nahrazení.

Kolik webů může síť obsáhnout?

Samotný software pevný limit nemá. V praxi limity určuje databáze (kolem tuctu tabulek na web), sdílené workery PHP a paměť a doba, kterou trvají síťové úlohy jako zálohování a cron. Při několika stovkách aktivních webů se zeptejte, jestli nepotřebujete vlastní databázový server a vyladěnou cache.

Fungují pluginy v Multisite?

Většina ano, ale pluginy, které vytvářejí vlastní tabulky, ukládají nastavení do wp_options pod pevně danými jmény nebo počítají s jednou sadou nahraných souborů, se mohou chovat špatně. Hledejte výslovnou podporu Multisite v dokumentaci pluginu a nejdřív ho vyzkoušejte na testovací síti.