Tak. Służą do tego dwa rozwiązania: sieć WordPress Multisite albo osobne instalacje rozróżniane prefiksami tabel. Różnią się jednak wszystkim poza tym, że dane leżą w jednym miejscu – modelem zarządzania, poziomem izolacji i tym, co się stanie, gdy trzeba będzie odtworzyć jedną stronę z kopii zapasowej.
Poniżej znajdziesz różnice między tymi podejściami, konsekwencje techniczne i warunki, przy których każde z nich ma sens.
Jak WordPress przechowuje dane
WordPress trzyma treści, ustawienia i dane użytkowników w bazie MySQL lub MariaDB, w tabelach o ustalonej strukturze. Nazwa każdej tabeli zaczyna się od prefiksu, domyślnie wp_. Stąd wp_posts, wp_users, wp_options. WooCommerce dokłada do tej samej struktury własne tabele — zobacz gdzie WooCommerce faktycznie przechowuje dane.
Ten prefiks jest jedynym mechanizmem, który pozwala kilku niezależnym instalacjom współistnieć w jednej bazie. Nie jest to mechanizm izolacji – to mechanizm unikania kolizji nazw. Różnica ma znaczenie i wrócimy do niej przy bezpieczeństwie.
WordPress Multisite a osobne instalacje
WordPress Multisite zamienia jedną instalację w sieć witryn. Część tabel jest wspólna dla całej sieci: konta użytkowników (wp_users, wp_usermeta) oraz tabele zarządzające samą siecią (wp_blogs, wp_site, wp_sitemeta). Każda kolejna witryna dostaje własny komplet tabel treściowych z numerem w nazwie: wp_2_posts, wp_2_options, wp_2_comments i tak dalej.
Osobne instalacje pozostają całkowicie niezależne. Każda ma własny panel, własnych użytkowników, własne wtyczki i motywy. Łączy je wyłącznie to, że zapisują dane do tej samej bazy, używając różnych prefiksów.
| Cecha | WordPress Multisite | Osobne instalacje |
|---|---|---|
| Użytkownicy | Wspólni dla całej sieci | Niezależni na każdej stronie |
| Wtyczki i motywy | Wspólne pliki, zarządzane sieciowo | Osobne dla każdej strony |
| Administracja | Jeden panel nadrzędny | Osobne panele |
| Swoboda konfiguracji | Ograniczona ustawieniami sieci | Pełna |
| Aktualizacja rdzenia | Jedna dla wszystkich witryn | Osobna dla każdej |
Różnica sprowadza się do filozofii zarządzania. Multisite pasuje do portfela powiązanych serwisów pod wspólnym nadzorem – sieci oddziałów, wersji regionalnych, marek jednego właściciela. Osobne instalacje sprawdzają się tam, gdzie strony mają pozostać niezależne.
Jak działają prefiksy tabel
Prefiks konfiguruje się w pliku wp-config.php:
php
$table_prefix = 'sklep1_';Instalator utworzy wtedy tabele sklep1_posts, sklep1_users i pozostałe. Druga instalacja z prefiksem blog2_ zbuduje własny, rozłączny komplet w tej samej bazie.
Podkreślnik na końcu jest obowiązkowy. WordPress dokleja nazwę tabeli bez separatora, więc sklep1 da sklep1posts.
Jedna uwaga praktyczna: zmiana prefiksu na działającej stronie to nie jest edycja jednej linii. Poza zmianą nazw tabel trzeba zaktualizować także wpisy, które zawierają prefiks w treści danych – między innymi klucz ról użytkowników w tabeli opcji oraz uprawnienia w metadanych użytkowników. Pominięcie tego kroku odcina dostęp do panelu administracyjnego.
Bezpieczeństwo: co realnie daje wspólna baza
Tu trzeba postawić sprawę jasno, bo w wielu poradnikach ten wątek jest osłabiony.
Jeżeli wszystkie instalacje łączą się z bazą tym samym użytkownikiem MySQL – a tak wygląda domyślna, najczęściej spotykana konfiguracja – to izolacja między stronami nie istnieje. Przejęcie jednej instalacji daje atakującemu pełny odczyt i zapis na tabelach wszystkich pozostałych. Prefiks nie stanowi tu żadnej bariery, bo służy wyłącznie rozróżnianiu nazw.
Ograniczenie tego ryzyka wymaga osobnego użytkownika MySQL dla każdej instalacji, z uprawnieniami przypisanymi wyłącznie do jej tabel. Jest to wykonalne, ale kłopotliwe w utrzymaniu: uprawnienia trzeba wyliczyć tabela po tabeli, a każda wtyczka tworząca własną tabelę wymaga ręcznego nadania uprawnień. Zaniedbanie tego kroku objawia się błędem dopiero w momencie, gdy wtyczka próbuje zapisać dane.
Pozostałe zasady są standardowe i nadal obowiązują: osobne, silne hasła, bieżące aktualizacje rdzenia i wtyczek, monitoring dostępu do bazy, kontrola uprawnień plików.
Kopie zapasowe: najczęściej pomijana konsekwencja
Wspólna baza upraszcza tworzenie kopii – jeden zrzut obejmuje wszystkie strony. Problem pojawia się przy odtwarzaniu.
Przywrócenie zrzutu cofa stan wszystkich instalacji w bazie, nie tylko tej, która wymagała naprawy. Jeśli jedna strona padła ofiarą włamania w środę, a pozostałe normalnie przyjmowały zamówienia, odtworzenie wtorkowej kopii oznacza utratę dwóch dni pracy pozostałych serwisów.
Obejściem jest odtwarzanie selektywne, czyli wyciąganie ze zrzutu wyłącznie tabel o właściwym prefiksie. Da się to zrobić, ale wymaga procedury opisanej wcześniej, a nie improwizacji pod presją awarii. To ten sam problem w Multisite, gdzie dodatkowo część danych jest wspólna dla całej sieci.
Zalety i wady w skrócie
Za wspólną bazą:
- prostsza konfiguracja hostingu przy ograniczonej liczbie dostępnych baz
- jedna procedura tworzenia kopii zapasowych
- mniej miejsc do monitorowania
Przeciw:
- brak realnej izolacji przy wspólnym użytkowniku bazy
- odtwarzanie kopii dotyka wszystkich stron naraz
- obciążenie generowane przez jedną stronę wpływa na pozostałe
- trudniejsza diagnostyka, bo zapytania z różnych serwisów mieszają się w logach
- wydzielenie strony na osobną infrastrukturę wymaga późniejszej migracji
Kiedy które rozwiązanie ma sens
Multisite wybieraj, gdy serwisy należą do jednego właściciela, mają wspólnych redaktorów i zbliżoną funkcjonalność. Typowy przypadek to sieć wersji regionalnych albo portfel marek zarządzany przez jeden zespół. Warto pamiętać, że wtyczki i motywy są wspólne dla całej sieci, więc awaria aktualizacji dotyka wszystkich witryn jednocześnie.
Osobne instalacje we wspólnej bazie to rozwiązanie sytuacyjne. Ma sens, gdy hosting limituje liczbę baz, a strony są niekrytyczne – serwisy wewnętrzne, środowiska testowe, projekty o niskim ruchu. Nie jest to architektura, którą warto wybierać dla serwisów przyjmujących płatności albo przetwarzających dane osobowe.
Osobne bazy pozostają domyślnym wyborem wszędzie tam, gdzie liczy się izolacja, przewidywalność odtwarzania i możliwość niezależnego skalowania. Koszt osobnej bazy jest dziś marginalny wobec kosztu jednego incydentu obejmującego kilka serwisów naraz.
O czym pamiętać przy planowaniu
Decyzja o współdzieleniu bazy jest łatwa do podjęcia i trudna do cofnięcia. Rozdzielenie instalacji po latach oznacza migrację danych, przepięcie konfiguracji i okno serwisowe dla wszystkich stron w zestawie. Sama migracja jest tematem tekstu czy można skopiować serwis WordPress na inną domenę.
Jeżeli planujesz architekturę dla portfela serwisów, warto rozstrzygnąć trzy rzeczy na starcie: czy strony będą kiedykolwiek sprzedawane lub wydzielane osobno, jaki jest akceptowalny czas odtworzenia po awarii i kto odpowiada za aktualizacje. Odpowiedzi na te pytania zwykle rozstrzygają wybór szybciej niż porównanie samych możliwości technicznych.
W WLC projektujemy i przebudowujemy takie architektury, w tym rozdzielanie sieci, które przestały odpowiadać skali projektu.
