Kiedyś opcji wielu stron w ramach jednej instalacji WordPressa (WordPress MU – Multi User) raczej unikałem – był to oddzielny projekt, często aktualizowany/rozwijany z opóźnieniem względem głównej gałęzi, a i nie wszystkie wtyczki sobie radziły prawidłowo z nim…
Zmieniło się to jakiś czas temu, przy okazji premiery WordPressa z numerkiem 3 – wtedy obsługa wielu stron w ramach jednej instalacji WordPressa trafiła do głównego projektu. Przy okazji zmieniając nazwę na WordPress Multisite.
I o tym dziś będzie…
WordPress Multisite w praktyce
Obecnie opcja „sieci stron” (multisite) jest częścią WordPressa, i choć jest domyślnie wyłączona – to w kilku prostych krokach można ją aktywować na naszej stronie.
Ale co to jest ten cały Multisite?
Ogólnie i w pewnym uproszczeniu aktywacja opcji Multisite w WordPressie pozwala nam postawić kilak stron korzystając z jednej instalacji WordPressa, i z jednej bazy danych.
Można dzięki temu obejść ograniczenia nakładane przez niektóre hostingi (nie polecam takich hostingów ;-)) co do ilości baz danych… Można też postawić kilka stron tematycznych w ramach jednej sieci – korzystając z faktu, że mimo iż jest to jeden WordPress i jedna baza danych, to każda strona w ramach sieci może mieć inny wygląd, korzystać z innych wtyczek i oczywiście posiadać różną treść… ;-)
Wprawdzie da się zmusić tak skonfigurowanego WordPressa (a konkretnie to i serwer) do tego, by każda strona naszej sieci działała pod inną domeną, to w tym poradniku skupię się na 2 klasycznych typach adresowania kolejnych stron:
- Subdomena (witryna1.domena, witryna2.domena)
- Podkatalog (domena/witryna1, domena/witryna2)
Dla 2 chyba najpopularniejszych webserwerów, czyli:
Aktywacja opcji WordPress Multisite
Ale zanim przejdziemy do konfiguracji poszczególnych opcji, najpierw musimy aktywować obsługę „sieci stron” w naszym WordPressie. W tym celu edytujemy plik „wp-config.php” i prawie na samym końcu, tuż przed:
if ( !defined(’ABSPATH') )
dodajemy:
define('WP_ALLOW_MULTISITE', true);
Po ponownym zalogowaniu się do panelu zarządzania WordPressem przechodzimy kolejno:
- WP-Admin: Narzędzia > Uruchamianie sieci
Gdzie musimy m.in. zdecydować o tym czy kolejne strony będą w subdomenach, czy podkatalogach:
Proszę zadecydować, czy witryny tej sieci mają mieć adresy w postaci subdomen czy podkatalogów. To ustawienie nie może zostać później zmienione.
W celu używania funkcjonalności wirtualnych hostów, konieczne jest posiadanie rekordu DNS z wieloznacznikiem.
- Subdomeny – przykłady: witryna1.[DOMENA] i witryna2.[DOMENA]
- Podkatalogi – przykłady: [DOMENA]/witryna1 i [DOMENA]/witryna2
Zacznę od wariantu z podkatalogami, bo mimo trochę trudniejszej konfiguracji (dotyczy serwera opartego o Nginx [LINK], bo dla Apache2 jest to właściwie bez różnicy) sam najczęściej wybieram ten wariant ;-)
WordPress Multisite i podkatalogi
Jest to wariant w którym każda kolejna strona naszej sieci będzie miała swój własny adres na zasadzie podkatalogu głównej domeny, czyli:
- [DOMENA]/witryna1
- [DOMENA]/witryna2
WordPress Multisite: podkatalogi i Apache2
W przypadku webserwera Apache2 niezbędna będzie obsługa mod_rewrite, który prawdopodobnie jest na Waszym serwerze aktywny – jeśli nie, to pomoże polecenie:
sudo a2enmod rewrite
Lub kontakt z administratorem serwera ;-)
W przypadku aktywacji WordPress Multisite na webserwerze opartym na Apache2 jest o tyle łatwiej, że wszystkie niezbędne czynności jak i wymagany kod zostanie Wam podany przez WordPressa, ale na wszelki wypadek również to opisze.
Po aktywacji WordPress Multisite w panelu (wp-admin) przechodzimy ponownie do edycji pliku „wp-config.php” i tuż nad linijką:
/* To wszystko, zakończ edycję w tym miejscu! Miłego blogowania! */
dodajemy kod podany przez WordPressa, np.:
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', '[DOMENA]');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
Edytujemy też plik .htaccess i zmieniamy w nim „standardowy WordPressowy kod” na coś w tym stylu:
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
I to tyle… ;-)
WordPress Multisite: podkatalogi i Nginx
Tutaj czeka nas wprawdzie trochę więcej zabawy, ale nie będzie to dużo trudniejsze niż powyżej ;-)
Nginx Map i Nginx Helper
Wprawdzie można wygenerować samemu plik mapy na zasadzie:
/adres-witryny/ ID_witryny;
/witryna1/ 2;
/witryna2/ 3;
To – zwłaszcza przy większych sieciach, czy tych bardziej „dynamicznych” – można sobie ułatwić zadanie instalując (i aktywując ;-)) wtyczkę Nginx Helper, która po małej konfiguracji zrobi wszystko za Was.
W tym celu przechodzimy do ustawień wtyczki:
- WP-Admin: Ustawienia > Nginx Helper
i w zakładce „General” zaznaczamy „Enable Nginx Map”, w tym momencie wyświetli się nam link do pliku map.conf:
/ścieżka/do/naszego/wordpressa/wp-content/uploads/nginx-helper/map.conf
który kopiujemy „na później”.
Nginx i konfiguracja vHosta
Teraz możemy przejść do pliku w którym znajduje się konfiguracja naszej strony (domeny/vHosta), czyli coś w stylu:
sudo nano /etc/nginx/sites-enabled/[DOMENA/nazwa pliku]
I dodajemy na samej górze, przed „server {„:
# ----- WordPress Multisite part 1 -----
map $uri $wpmsname{
~^(?/[^/]+/)files/(.*) $wpmspath;
}
map $wpmsname $wpmsid{
default -999;
include /ścieżka/do/pliku/map.conf;
}
# ----- /WordPress Multisite part 1 -----
Oraz w dalszej części, zamiast:
location / {
try_files $uri $uri/ /index.php?$args;
}
Wpisujemy:
# ----- WordPress Multisite part 2 -----
location ~ ^(/[^/]+/)?files/(?.+) {
try_files /wp-content/blogs.dir/$wpmsid/files/$rt_file /wp-includes/ms-files.php?file=$rt_file;
}
location / {
if (-f $request_filename/index.html){ rewrite (.*) $1/index.html break; }
if (-f $request_filename/index.php){ rewrite (.*) $1/index.php; }
if (!-f $request_filename){ rewrite (.*) /index.php;}
}
rewrite /files/$ /index.php last;
if ($uri !~ wp-content/plugins) { rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last; }
if (!-e $request_filename) {
rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;
rewrite ^/[_0-9a-zA-Z-]+.(/wp-admin/.\.php)$ $1 last;
rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;
}
# ----- /WordPress Multisite part 2 -----
Zapisujemy zmiany, szybki test konfiguracji i restart serwera:
sudo /etc/init.d/nginx configtest
sudo /etc/init.d/nginx reload
Jeśli wszystko poszło OK, WordPress Multisite powinien już działać…
WordPress Multisite i subdomeny
Jest to wariant w którym każda kolejna strona naszej sieci będzie miała swój własny adres na zasadzie subdomeny, czyli:
- witryna1.[DOMENA]
- witryna2.[DOMENA]
WordPress Multisite: subdomeny i Apache2
W przypadku webserwera Apache2 niezbędna będzie obsługa mod_rewrite, który prawdopodobnie jest na Waszym serwerze aktywny – jeśli nie, to pomoże polecenie:
sudo a2enmod rewrite
Lub kontakt z administratorem serwera ;-)
W przypadku aktywacji WordPress Multisite na webserwerze opartym na Apache2 jest o tyle łatwiej, że wszystkie niezbędne czynności jak i wymagany kod zostanie Wam podany przez WordPressa, ale na wszelki wypadek również to opisze.
Po aktywacji WordPress Multisite w panelu (wp-admin) przechodzimy ponownie do edycji pliku „wp-config.php” i tuż nad linijką:
/* To wszystko, zakończ edycję w tym miejscu! Miłego blogowania! */
dodajemy kod podany przez WordPressa, np.:
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', '[DOMENA]');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
Edytujemy też plik .htaccess i zmieniamy w nim „standardowy WordPressowy kod” na coś w tym stylu:
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
Dodatkowo – jeśli nie ustawiliście tak wcześniej – musimy przejść do edycji pliku w którym znajduje się konfiguracja naszej strony (domeny/vHosta), np.:
sudo nano /etc/apache2/sites-enabled/[DOMENA/nazwa pliku]
i zaraz pod wpisem określającym domenę dla serwera dodajemy:
ServerAlias *.[DOMENA]
I tyle, choć trzeba jeszcze zrestartować serwer Apache2:
sudo service apache2 restart
WordPress Multisite: subdomeny i Nginx
Tu mam dla Was chyba dobrą wiadomość – tym razem będzie mniej „roboty” niż w przypadku subdomen i Apache2.
Zaczynamy – i w sumie na tym też kończymy – od edycji pliku w którym znajduje się konfiguracja naszej strony (domeny/vHosta), czyli coś w stylu:
sudo nano /etc/nginx/sites-enabled/[DOMENA/nazwa pliku]
i w sekcji „server” dodajmy/modyfikujemy linijkę:
server_name [DOMENA] *.[DOMENA];
Konkretnie chodzi o „*.[DOMENA]”.
Od razu zalecam, by zaraz poniżej dodać jeszcze jedną linijkę:
server_name_in_redirect off;
Zapisujemy zmiany, szybki test konfiguracji i restart serwera:
sudo /etc/init.d/nginx configtest
sudo /etc/init.d/nginx reload
I to tyle… :-)
Ustawienia w DNSach
Oczywiście jest jeszcze jasna ważna rzecz, bez której subdomeny nie zadziałają – czyli odpowiednie ustawienie wpisów w DNSach dla domeny.
Wprawdzie można bawić się w ręczne dodawanie rekordu A dla każdej subdomeny, to ja zalecam skorzystać z „wildcarda” dla rekordu A:
A *.[nazwadomeny] IP_SERWERA
Zarządzanie stronami w ramach WordPress Multisite
Samo zarządzanie stronami w ramach sieci jest proste, choć może wymagać chwili by się przestawić do tego, że wszystkie wtyczki i motywy instalujemy i ustawiamy na aktywne w ramach konta nadrzędnego, bez tego nie będą dostępne dla poszczególnych stron.
- WP-Admin: Moje witryny > Administracja siecią: Motywy
- WP-Admin: Moje witryny > Administracja siecią: Wtyczki
Zarządzanie stronami w ramach sieci odbywa się z menu:
- WP-Admin: Moje witryny > Administracja siecią: Witryny
PS. W przykładach został użyty „zwrot”: [DOMENA] – pamiętajcie by zamienić go na nazwę Waszej domeny… :-)
- Dzięki wtyczce ShopMagic wdrożysz przypomnienie o płatności w WooCommerce, ale w wersji darmowej sensu ma to niewiele - 1970-01-01
- Microsoft Azure Speech CLI (SPX), czyli relatywnie tani i prosty sposób na transkrypcję (zamiana mowy na tekst) - 1970-01-01
- PayPal i TransferWise w kooperacji, czyli sposób na wypłatę dolarów z konta PayPal bez przewalutowania, ale z prowizją - 1970-01-01
wszystko pięknie, i działa(ło), ale co zrobić gdy wszystko jest ustawione (i działa) a po aktualizacji WP najpierw znika możliwość wyświetlania subdoment (edycja jest możliwa) a po wczytania backupu plików i baz danych (z dnia w którym wszystko działało) przestaje być możliwa nawet edycja?
Ponowna aktualizacja nie daje efektów!
Wiesz co…. za bardzo to ogólne bym mógł coś podpowiedzieć. Trochę dziwne, że po awarii przywrócenie z kopii naprawia problem, ale zarazem generuje inny. Albo coś w procesie tworzenia kopii i/lub przywracania jest nie tak, albo coś się rozjechało w systemie. Jeśli to VPS, to może warto skorygować uprawnienia? Bo brak możliwości edycji plików w WP (z poziomu WP) może na to wskazywać.
Cofnąłem się jeszcze o dwa dni i subdomena jest!
Tylko nie wiem co się mogło poprzestawiać w WordPressie (aż boję się uaktualniać do nowszej wersji)
A problem jest dziwny – na serwerze mam w katalogu subdomeny index.html który normalnie jest 'nieczytany' cała obróbka idzie przez domenę główną WordPressa (www.eryniawtrasie.eu)
Przejawem problemów jest wyświetlanie treści z //domains/eryniawtrasie.eu/public_html/przydasie/index.html
Nie wiem czy nie jest to przypadkiem kwestia szybkiej obróbki aktualizacji. W trakcie aktualizacji pojawia się napis „Aktualizuję bazę danych”… i trwa to i trwa, a nie wiadomo kiedy się kończy więc naciskam „Aktualizuj sieć witryn”
Skąd wiadomo kiedy aktualizacja (WordPressa czy wtyczek) się kończy – nie doczekałem się żadnego o tym komunikaatu
Może to jest źródło problemów?
Tak naprawdę obecnie możemy tylko zgadywać co było przyczyną, może ewentualnie logi serwera (lub WordPressa, jeśli aktywne) mogłyby coś pomóc… Z tego co pamiętam, to nawet w przypadku WordPress MultiSite przebieg aktualizacji jest wyświetlany, w tym oczywiście również jej koniec.
Dziękuję
Daj znać jakby (odpukać) problem się powtórzył, a zwłaszcza, jakby udało się ustalić przyczynę (pamiętaj o kopiach zapasowych :-)). Niestety, ale w pewnych sytuacjach bez bezpośredniego wglądu w „system” można tylko zgadywać.
OK.
Mam nadzieję, ze się nie popsuje ale będę pamiętał.
Jeszcze raz dziękuję