WordPress i niemal wszystkie pluginy przechowują swoje ustawienia w unikalnym miejscu na serwerze nazywanym „bazą danych”. Dane przechowywane w bazie są zorganizowane w tzw. „tabelach”. Ten artykuł szczegółowo wyjaśnia znaczenie wszystkich dostępnych pól domyślnej struktury bazy danych WordPress.
TL;DR: WordPress przechowuje większość danych witryny w bazie MySQL lub MariaDB. Standardowa jednowitrynowa instalacja WordPress używa obecnie 12 domyślnych tabel z konfigurowalnym prefiksem, najczęściej
wp_. Tabele te przechowują wpisy, strony, użytkowników, ustawienia, komentarze, terminy taksonomii i metadane, a pluginy, motywy, WooCommerce oraz instalacje multisite mogą dodawać kolejne tabele.
Uwaga: Aby bezpiecznie sprawdzić bazę danych WordPress, wykonaj Backup witryny lub utwórz środowisko staging przy pomocy WP STAGING. Następnie użyj narzędzia zarządzania bazą danych, np. phpMyAdmin lub Adminer, aby uzyskać dostęp i zmodyfikować bazę bez wpływu na żywą witrynę.
Contents
- Tabele bazy danych WordPress w skrócie
- Jak wyglądają tabele bazy danych?
- Lista tabel rdzenia WordPress
- wp_options
- wp_users,wp_usermeta
- wp_posts,wp_postmeta
- wp_terms,wp_term_relationships,wp_term_taxonomy, wp_termmeta
- wp_comments,wp_commentmeta
- wp_links
- Nadchodząca tabela WordPress 7.0: wp_collaboration
- Graficzna struktura bazy danych WordPress
- Częste problemy z bazą danych WordPress i tabele za nimi stojące
- Powiązane artykuły
Tabele bazy danych WordPress w skrócie
Standardowa jednowitrynowa instalacja WordPress używa obecnie 12 domyślnych tabel bazy danych. Poniższa tabela podsumowuje, co każda tabela przechowuje, gdzie WordPress jej używa i co może się zepsuć, jeśli tabela jest brakująca lub uszkodzona.
| Tabela | Przechowuje | Wykorzystywana do | Co się psuje, jeśli brakuje lub jest uszkodzona |
|---|---|---|---|
wp_options | URL witryny, aktywne pluginy, ustawienia motywu, transients, reguły rewrite, dane cron | Bootstrap WordPress, ustawienia pluginów, konfiguracja witryny | Złe przekierowania URL, brakujące ustawienia, błędy pluginów, zepsuty cron, wolne autoloadowane opcje |
wp_posts | Wpisy, strony, załączniki, rewizje, menu, niestandardowe typy wpisów | Treść, biblioteka mediów, menu nawigacji, dane wielu pluginów | Brakujące strony/wpisy/media, zepsute menu, brakujące wpisy niestandardowych typów |
wp_postmeta | Metadane dla wpisów, stron, załączników, produktów, page builderów, pluginów SEO | Obrazy wyróżnione, dane produktów, pola SEO, układy page builderów | Brakujące obrazy, zepsute układy, brakujące dane produktów, niekompletne metadane SEO |
wp_users | Konta użytkowników, loginy, hashe haseł, emaile, nazwy wyświetlane | Uwierzytelnianie i autorstwo | Użytkownicy nie mogą się zalogować, autorzy znikają |
wp_usermeta | Role użytkowników, uprawnienia, pola profilu, ustawienia użytkowników pluginów | Uprawnienia i ustawienia specyficzne dla użytkownika | Admin traci uprawnienia, role znikają, ustawienia użytkowników się psują |
wp_comments | Komentarze, pingbacki, trackbacki, recenzje | Komentarze i systemy recenzji | Komentarze lub recenzje znikają |
wp_commentmeta | Metadane dla komentarzy i recenzji | Status spamu, oceny, dane komentarzy pluginów | Metadane recenzji, dane spamu lub dane komentarzy pluginów są tracone |
wp_terms | Nazwy i slugi terminów | Kategorie, tagi, kategorie linków, terminy niestandardowych taksonomii | Nazwy kategorii i tagów znikają |
wp_termmeta | Metadane dla terminów taksonomii | Obrazy terminów, metadane SEO, niestandardowe pola terminów | Metadane kategorii/tagów znikają |
wp_term_taxonomy | Typ taksonomii, relacja rodzica, liczniki terminów | Rozróżnia kategorię od tagu i taksonomii niestandardowej | Kategorie/tagi zostają nieprawidłowo zmapowane lub tracą hierarchię |
wp_term_relationships | Relacje między treścią a terminami taksonomii | Przypisuje wpisy/produkty/strony do kategorii i tagów | Wpisy tracą kategorie/tagi, menu i relacje taksonomii się psują |
wp_links | Dziedziczone dane menedżera linków / blogroll | Wycofana funkcja Links Manager i stare pluginy | Zwykle nic na nowoczesnych witrynach, chyba że stary plugin nadal jej używa |
Jak wyglądają tabele bazy danych?
Wyobraź sobie arkusz Excel z jednym wierszem nagłówka i wartościami w kolejnych wierszach.
Na przykład tutaj widzisz niewielki fragment tabeli wp_options:
Porozmawiajmy o tych tabelach głębiej, by zrozumieć, dlaczego warto wiedzieć, która tabela odpowiada za zawartość witryny WordPress.
Zrozumienie struktury tabel pomoże ci zorientować się, którą tabelę uwzględnić lub wykluczyć, jeśli planujesz synchronizować lub przenosić dane z witryny staging na żywą lub odwrotnie z WP STAGING. Jest też pomocne, jeśli planujesz aktualizację witryny staging.
Staje się to jeszcze ważniejsze przy WordPress 7.0 i nowszych. Planowana tabela wp_collaboration przechowuje dane współpracy edytora w czasie rzeczywistym, które są zwykle tymczasowe i specyficzne dla środowiska. Przy push witryny staging na żywą unikaj nadpisywania aktywnego stanu współpracy żywej witryny, chyba że celowo chcesz zastąpić całą bazę danych.
Lista tabel rdzenia WordPress
Powyższa tabela daje szybki przegląd. Poniższa sekcja wyjaśnia tabele rdzenia WordPress bardziej szczegółowo – dla deweloperów, właścicieli witryn i każdego, kto debuguje migracje, Backupy lub problemy z bazą danych.
- wp_options
- wp_users,
- wp_usermeta
- wp_posts
- wp_postmeta
- wp_terms
- wp_term_relationships
- wp_term_taxonomy
- wp_termmeta
- wp_comments
- wp_commentmeta
- wp_links
WordPress może dodawać nowe tabele rdzenia w głównych wydaniach. Na przykład WordPress 7.0 planuje wprowadzić `wp_collaboration` dla danych współpracy edytora w czasie rzeczywistym.
Inne tabele w twojej bazie danych są tworzone przez pluginy lub motywy i nie zawsze są niezbędne do działania witryny.
wp_options
Tabela wp_options to jedna z najważniejszych tabel bazy danych WordPress, przechowująca wszystkie ustawienia witryny WordPress, takie jak URL, tytuł, zainstalowane pluginy itd. Większość pluginów również przechowuje tu swoje ustawienia.
Wszystkie ustawienia z panelu WordPress są przechowywane w tej tabeli.
wp_users,
wp_usermeta
wp_users przechowuje wszystkich zarejestrowanych użytkowników witryny WordPress. Zawiera podstawowe informacje o użytkowniku, takie jak nazwa użytkownika i zaszyfrowane hasło, email, czas rejestracji, nazwa wyświetlana, status i kilka innych pól.
wp_usermeta przechowuje metadane („dodatkowe dane”) użytkowników. Rozszerza tabelę wp_users o więcej danych. Na przykład imię użytkownika jest przechowywane w tabeli wp_usermeta zamiast w tabeli wp_users.
W tej tabeli są dwa niezbędne pola. Pluginy mogą przechowywać własne dane w wp_usermeta, dodając nową wartość w polu meta_key.
wp_posts,
wp_postmeta
Tabela wp_posts przechowuje wszystkie dane związane z treścią witryny WordPress. Wszystkie wpisy, strony i ich rewizje są dostępne w tabeli wp_posts. Może to być niejasne, ale WordPress przechowuje w tej tabeli znacznie więcej.
Ta tabela zawiera również pozycje menu nawigacji, pliki mediów i załączniki, np. obrazy, oraz dane treści używane przez pluginy.
W wp_posts jest kolumna post_type, która segmentuje różnego rodzaju dane, tak by zapytanie do bazy mogło prosić o konkretne typy danych. post_type jest najważniejszą kolumną w tej tabeli.
Na obrazach poniżej widzisz dwa różne post_types: revision i attachment, które są przechowywane w tej samej tabeli wp_posts:
Tabela wp_postmeta, podobnie jak wp_usermeta, rozszerza tabelę wp_posts o więcej danych, których mogą używać również inne pluginy.
Na przykład popularny plugin Yoast SEO przechowuje w tej tabeli niestandardowe tagi open graph, wpisy i dane URL.
wp_terms,
wp_term_relationships,
wp_term_taxonomy,
wp_termmeta
Tabela wp_terms przechowuje Kategorie i tagi dla wpisów, stron i linków.
Jedna z kolumn tej tabeli to „slug”. Slug to termin odzwierciedlający tag konkretnego wpisu. W WordPress możesz używać tagów do łączenia wpisów, stron i linków.
wp_term_relationships jest spoiwem łączącym te tagi z wpisami, stronami i linkami. To jak mapa między obiektami terminów a samymi terminami.
wp_term_taxonomy rozszerza tabelę wp_terms o więcej danych. To jak metadane dla tabeli wp_terms, z tą różnicą, że pluginy nie mogą dodawać tu własnych danych. Ta tabela zawiera również relację między menu a pozycjami menu.
Tabela wp_termmeta przechowuje metadane dla terminów taksonomii. Działa podobnie do wp_postmeta, wp_usermeta i wp_commentmeta, ale dla kategorii, tagów i terminów niestandardowych taksonomii.
Pluginy i motywy mogą używać tej tabeli do przechowywania dodatkowych danych terminów, takich jak obrazy kategorii, metadane SEO, niestandardowe kolory, ustawienia wyświetlania czy inne pola specyficzne dla taksonomii.
Jeśli ta tabela jest brakująca lub niekompletna po migracji, kategorie i tagi mogą nadal istnieć, ale ich dodatkowe metadane mogą zostać utracone.
wp_comments,
wp_commentmeta
wp_comments przechowuje komentarze do wpisów i stron. Ta tabela zawiera też niezatwierdzone komentarze i informacje o autorze, wraz z hierarchią komentarzy. Tabela wp_commentmeta zawiera dalsze metadane o komentarzach.
wp_links
Ta tabela zawiera informacje o niestandardowych linkach dodanych do witryny. Została wycofana i nie jest już używana. Jest kilka starszych pluginów, które wciąż z niej korzystają, ale zwykle jest to pusta tabela.
Nadchodząca tabela WordPress 7.0: wp_collaboration
`wp_collaboration` to nowa tabela bazy danych rdzenia WordPress planowana na WordPress 7.0. Jest częścią funkcji współpracy w czasie rzeczywistym w edytorze blokowym, pozwalającej wielu użytkownikom edytować ten sam wpis lub stronę jednocześnie.
Wcześniejsze wersje beta WordPress 7.0 przechowywały dane synchronizacji związanej ze współpracą w magazynie wpisów i postmeta. Powodowało to problemy z wydajnością, bo aktywność edytora w czasie rzeczywistym może bardzo często zapisywać dane. Każda aktualizacja postmeta może unieważniać cache obiektów związanych z wpisem, co może zmniejszyć skuteczność trwałego cachowania obiektów, gdy sesja edytora jest otwarta.
Nowa tabela `wp_collaboration` oddziela dane współpracy o wysokiej częstotliwości od zwykłych tabel treści, takich jak `wp_posts` i `wp_postmeta`. Jej celem jest przechowywanie tymczasowych danych synchronizacji używanych przez edytor, np. aktualizacji edycji współpracy, identyfikatorów klienta/sesji, informacji o pokoju i znaczników czasu używanych do czyszczenia.
Ta tabela **nie** zastępuje `wp_posts`, `wp_postmeta` ani systemu rewizji WordPress. Wpisy, strony, załączniki, niestandardowe typy wpisów i rewizje nadal są przechowywane w `wp_posts`; metadane specyficzne dla wpisów pozostają w `wp_postmeta`.
Dla Backupów i migracji traktuj `wp_collaboration` inaczej niż stałe tabele treści. Pełny Backup bazy powinien ją obejmować, ale przy push witryny staging na produkcję ta tabela zwykle nie musi nadpisywać żywej witryny, ponieważ przechowuje krótkotrwałe dane współpracy/sesji, a nie kanoniczną treść witryny. WordPress może odtworzyć stan współpracy, gdy użytkownicy edytują treść.
Ważne: choć dane są tymczasowe, mogą nadal zawierać payloady synchronizacji edytora związane z treścią w trakcie tworzenia. Nie traktuj ich jako publicznych lub jednorazowych z perspektywy prywatności i bezpieczeństwa.
Uwaga: Ostateczny schemat może się jeszcze zmienić przed wydaniem WordPress 7.0. W trakcie rozwoju publiczne propozycje dla `wp_collaboration` zawierały pola takie jak auto-inkrementujące się ID, identyfikator pokoju, identyfikatory klienta/użytkownika, payload danych i znacznik czasu GMT. Niedawne testy badają też przechowywanie danych obecności/awareness w osobnej tabeli `wp_presence`. Sprawdź ostateczny schemat bazy danych WordPress 7.0 przed publikacją dokładnej listy kolumn.
Graficzna struktura bazy danych WordPress
Ten diagram pokazuje, jak tabele WordPress są ze sobą połączone:
Otwórz obraz w pełnej rozdzielczości: kliknij prawym przyciskiem -> Otwórz obraz w nowej karcie
Częste problemy z bazą danych WordPress i tabele za nimi stojące
| Problem | Najbardziej istotna tabela(e) | Co sprawdzić |
|---|---|---|
| Witryna przekierowuje na złą domenę po migracji | wp_options | Sprawdź siteurl, home i zserializowane opcje pluginów |
| Użytkownik admin istnieje, ale nie ma uprawnień admina | wp_usermeta | Sprawdź klucz capabilities, zwłaszcza po zmianie prefiksu tabel |
| Wpisy istnieją, ale brakuje kategorii lub tagów | wp_terms, wp_term_taxonomy, wp_term_relationships | Sprawdź, czy wszystkie tabele taksonomii zostały razem zmigrowane |
| Wpisy biblioteki mediów istnieją, ale obrazy są zepsute | wp_posts, wp_postmeta, folder uploads | Załączniki są przechowywane w wp_posts; ścieżki plików są często przechowywane w _wp_attached_file w wp_postmeta |
| Menu znikają po migracji | wp_posts, wp_terms, wp_term_relationships, wp_postmeta | Menu nawigacji są przechowywane w kilku tabelach |
| Ustawienia pluginów znikają | wp_options, czasem tabele specyficzne dla pluginu | Sprawdź, czy plugin przechowuje ustawienia w wp_options czy w niestandardowych tabelach |
| Witryna staje się wolna po migracji | wp_options, wp_postmeta | Sprawdź autoloadowane opcje i duże tabele metadanych |
| Komentarze lub recenzje znikają | wp_comments, wp_commentmeta | Migruj obie tabele razem |
| WordPress mówi, że tabela nie istnieje | wp-config.php, wszystkie tabele z prefiksem | Sprawdź $table_prefix i czy wszystkie tabele używają tego samego prefiksu |
Powiązane artykuły
- Zserializowane dane – co to oznacza i dlaczego są tak ważne?
- Jak scalić witrynę staging z produkcyjną zachowując wpisy i treści użytkowników
- Actions i Filters
- Jak bezpiecznie zrobić Backup motywu WordPress
- Gdzie produkty WooCommerce są przechowywane w bazie danych?
- Zwiększ rozmiar max allowed packet
