WooCommerce przechowuje dane w bazie WordPressa, łącząc standardowe tabele WordPressa z własnymi tabelami dodawanymi przez wtyczkę. Produkty zapisywane są jako niestandardowy typ treści w tabeli wp_posts, a ich parametry w wp_postmeta. Zamówienia w nowoczesnych instalacjach trafiają do osobnych tabel wp_wc_orders i powiązanych, a nie do wp_posts, jak działo się to w starszych sklepach. Dane klientów zarejestrowanych leżą w tabeli użytkowników WordPressa, dane kupujących bez konta zapisywane są razem z zamówieniem. Pliki, w tym zdjęcia produktów, nie trafiają do bazy, tylko do katalogu na serwerze.
Szybka odpowiedź Dane WooCommerce znajdziesz w: wp_posts i wp_postmeta (produkty), wp_wc_orders i tabele powiązane (zamówienia w modelu HPOS) lub wp_posts (zamówienia w modelu starszym), wp_users i wp_usermeta (klienci z kontem), wp_options (konfiguracja sklepu), /wp-content/uploads/ (pliki).
Jak zbudowana jest struktura danych WooCommerce?
WooCommerce działa na bazie WordPressa, więc korzysta z jego struktury i dokłada do niej własne tabele. Baza WordPressa to dwanaście tabel podstawowych. Instalacja WooCommerce dodaje kilkadziesiąt kolejnych, obsługujących pozycje zamówień, stawki podatkowe, strefy wysyłki, uprawnienia do plików do pobrania i tabele pomocnicze przyspieszające raportowanie.
Model podstawowy wygląda następująco:
| Typ danych | Miejsce przechowywania | Zawartość |
|---|---|---|
| Produkty | wp_posts + wp_postmeta | Nazwa, opis, cena, stan magazynowy, SKU |
| Zamówienia (HPOS) | wp_wc_orders + tabele powiązane | Status, kwoty, adresy, metadane |
| Zamówienia (model starszy) | wp_posts + wp_postmeta | To samo, w strukturze klucz-wartość |
| Pozycje zamówień | wp_woocommerce_order_items + _itemmeta | Produkty w zamówieniu, ilości, ceny |
| Klienci z kontem | wp_users + wp_usermeta | Dane konta, adresy, preferencje |
| Klienci bez konta | Razem z zamówieniem | Adres, e-mail, dane do wysyłki |
| Konfiguracja | wp_options | Ustawienia sklepu |
| Pliki | /wp-content/uploads/ | Zdjęcia, pliki do pobrania |
Ta konstrukcja ma zaletę i wadę, i obie warto rozumieć przed podjęciem decyzji o rozbudowie sklepu.
Zaletą jest zgodność z ekosystemem. Skoro produkt jest wpisem, działają na nim standardowe mechanizmy WordPressa: taksonomie, wyszukiwanie, uprawnienia, obsługa wersji. Tysiące wtyczek działa z WooCommerce bez żadnej dodatkowej pracy.
Wadą jest struktura klucz-wartość w wp_postmeta. Tabela zaprojektowana dla bloga obsługuje w sklepie ceny, stany magazynowe i atrybuty. Przy dużym katalogu i wysokim wolumenie zamówień rośnie ona do rozmiarów, przy których zapytania przestają być efektywne. To znany limit tej architektury i punkt wyjścia dla większości optymalizacji w większych wdrożeniach.
Gdzie WooCommerce przechowuje dane produktów?
Dane produktów rozłożone są między kilka tabel, a produkt jest w bazie niestandardowym typem wpisu.
wp_postsprzechowuje nazwę produktu, opis, skrócony opis, status publikacji i identyfikator. Typ wpisu toproduct, a dla wariantówproduct_variation.wp_postmetaprzechowuje parametry produktu w formie par klucz-wartość: ceny, stan magazynowy, SKU, wymiary, ustawienia widoczności.wp_terms,wp_term_taxonomyiwp_term_relationshipsobsługują kategorie, tagi i atrybuty produktowe.wp_wc_product_meta_lookupto tabela pomocnicza, która duplikuje najczęściej używane parametry produktu w formie kolumnowej, żeby przyspieszyć filtrowanie i sortowanie.
Produkty z wariantami działają na zasadzie relacji rodzic-dziecko. Koszulka dostępna w trzech rozmiarach i dwóch kolorach to jeden wpis nadrzędny i sześć wpisów typu product_variation, powiązanych przez kolumnę post_parent. Każdy wariant ma własny komplet metadanych.
Ten mechanizm tłumaczy, dlaczego katalogi z rozbudowaną wariantowością obciążają bazę nieproporcjonalnie do liczby produktów widocznych dla klienta. Tysiąc produktów z ośmioma wariantami każdy to dziewięć tysięcy wpisów i kilkadziesiąt tysięcy rekordów metadanych.
Jak WooCommerce przechowuje zamówienia?
Tu potrzebne jest rozróżnienie, bo odpowiedź zależy od tego, kiedy powstał sklep i czy ktoś zmieniał jego konfigurację.
Model współczesny (HPOS). High-Performance Order Storage jest domyślny dla nowych instalacji od wersji 8.2, wydanej w październiku 2023 roku. Zamówienia trafiają do osobnych, znormalizowanych tabel:
wp_wc_orders– główne dane zamówienia: status, waluta, kwoty, identyfikator klientawp_wc_order_addresses– adresy rozliczeniowy i do wysyłkiwp_wc_order_operational_data– dane operacyjne: metoda płatności, informacje o wysyłce, znaczniki czasuwp_wc_orders_meta– metadane zamówienia, w tym pola dodawane przez wtyczki
Model starszy. Zamówienie jest wpisem w wp_posts o typie shop_order, a wszystkie szczegóły trafiają do wp_postmeta. Ten model nadal działa w sklepach uruchomionych przed 2023 rokiem, które nie przeszły migracji.
Wspólne dla obu modeli. Pozycje zamówienia, czyli konkretne produkty z ilościami i cenami, zawsze leżą w wp_woocommerce_order_items i wp_woocommerce_order_itemmeta. Te tabele istnieją od dawna i HPOS ich nie zmienił.
Jak sprawdzić, który model działa w Twoim sklepie
Wejdź w panelu do WooCommerce → Ustawienia → Zaawansowane → Funkcje. Zobaczysz tam wybór między przechowywaniem zamówień w tabelach WooCommerce a przechowywaniem w tabelach wpisów WordPressa. Zaznaczona opcja jest tą obowiązującą.
Drugi sposób, szybszy dla osoby technicznej: sprawdź, czy w bazie istnieje tabela wp_wc_orders i czy zawiera rekordy. Sama obecność tabeli nie przesądza, bo mogła powstać przy synchronizacji.
Jeżeli sklep nadal działa na modelu starszym i przetwarza znaczące wolumeny, migracja do HPOS jest jedną z najlepiej zwracających się optymalizacji. Wymaga jednak sprawdzenia zgodności wszystkich wtyczek i integracji, bo część rozwiązań zapisuje dane zamówień bezpośrednio do wp_postmeta, z pominięciem warstwy WooCommerce. Taka integracja przestanie działać poprawnie po przełączeniu.
Gdzie zapisywane są dane klientów?
Odpowiedź zależy od tego, czy klient założył konto.
Klient z kontem. Dane podstawowe, czyli login, adres e-mail i data rejestracji, trafiają do wp_users. Dane rozszerzone, czyli adresy rozliczeniowy i wysyłkowy oraz preferencje, do wp_usermeta.
Klient bez konta. Dane zapisywane są razem z zamówieniem, czyli w wp_wc_orders i wp_wc_order_addresses przy HPOS albo w wp_postmeta przy modelu starszym. Adres e-mail pozwala klientowi śledzić zamówienie i odbierać powiadomienia.
Niezależnie od modelu WooCommerce prowadzi tabelę wp_wc_customer_lookup, która agreguje dane klientów na potrzeby raportów i analiz. Nie jest źródłem prawdy, tylko warstwą przyspieszającą zapytania.
Ta dwutorowość ma konsekwencje przy obsłudze RODO. Realizacja żądania usunięcia danych albo przygotowanie eksportu wymaga przejścia przez oba miejsca. Wtyczki obsługujące żądania podmiotów danych zwykle to uwzględniają, ale warto to zweryfikować, zwłaszcza jeśli sklep ma własne rozszerzenia dopisujące dane klienta w niestandardowych polach.
Czy WooCommerce przechowuje dane poza bazą?
Tak. Część danych leży w systemie plików na serwerze, nie w bazie.
- Zdjęcia produktów trafiają do katalogu
/wp-content/uploads/, uporządkowane według roku i miesiąca - Pliki produktów cyfrowych trafiają do chronionego katalogu
/wp-content/uploads/woocommerce_uploads/, zabezpieczonego przed bezpośrednim dostępem - Eksporty i raporty generowane są jako pliki tymczasowe
- Pliki wtyczek i motywu to osobna warstwa, obejmująca również własne modyfikacje
Rozdzielenie bazy i plików ma praktyczne zalety: baza pozostaje mniejsza, kopie zapasowe można różnicować, a pliki statyczne da się serwować z sieci CDN.
Ma też jedną konsekwencję, o której łatwo zapomnieć. Kopia samej bazy danych nie odtworzy sklepu. Odzyskacie strukturę i treści, ale bez zdjęć produktów i bez plików, które klienci kupili.
Jak uzyskać dostęp do tabel WooCommerce?
Metod jest kilka i różnią się poziomem ryzyka.
| Metoda | Zastosowanie | Ryzyko | Wymagane kompetencje |
|---|---|---|---|
| API WooCommerce i funkcje WordPressa | Rozwój funkcji, integracje | Niskie | PHP, znajomość WordPressa |
| WP-CLI | Operacje masowe, automatyzacja | Średnie | Wiersz poleceń, WP-CLI |
| phpMyAdmin lub Adminer | Diagnostyka, podgląd danych | Średnie | SQL |
| Bezpośrednie zapytania SQL | Operacje masowe na dużych zbiorach | Wysokie | Zaawansowany SQL, architektura baz |
Jedna zasada obowiązuje niezależnie od metody i warto ją przekazać każdemu, kto ma dostęp do bazy produkcyjnej: przed każdą zmianą wykonaj kopię zapasową i sprawdź ją na środowisku testowym.
Druga zasada dotyczy wyłącznie zamówień i wynika bezpośrednio z HPOS. Nie odwołujcie się do danych zamówień przez funkcje operujące na wpisach i metadanych wpisów. Kod korzystający z get_post_meta() dla zamówień może działać w trybie zgodności i przestać działać po jego wyłączeniu. Właściwa droga to metody obiektu WC_Order. To najczęstsza przyczyna awarii integracji po migracji do HPOS.
Jak struktura danych wpływa na integracje?
Sposób przechowywania zamówień ma bezpośrednie przełożenie na integracje z systemami zewnętrznymi, a w polskim e-commerce to zwykle najbardziej newralgiczny obszar całego wdrożenia.
Typowy sklep wymienia dane zamówień z kilkoma systemami naraz: platformą do zarządzania sprzedażą wielokanałową, systemem magazynowym, ERP, systemem księgowym, operatorami logistycznymi. Każda z tych integracji czyta lub zapisuje dane zamówień, a część robi to przez API WooCommerce, część przez własne zapytania do bazy.
Rozróżnienie ma znaczenie praktyczne. Integracja korzystająca z REST API WooCommerce albo z warstwy WC_Order działa niezależnie od tego, gdzie fizycznie leżą dane. Integracja sięgająca bezpośrednio do wp_postmeta działa tylko w modelu starszym albo w trybie zgodności, a po jego wyłączeniu zaczyna zwracać dane niekompletne, często bez żadnego komunikatu o błędzie.
Przy podłączaniu platformy pokroju BaseLinkera warto zweryfikować trzy rzeczy przed uruchomieniem, a nie po pierwszym rozjeździe stanów magazynowych:
- Czy integracja deklaruje zgodność z HPOS. Producenci zwykle podają to wprost w dokumentacji. WooCommerce sygnalizuje też niezgodne wtyczki w panelu ustawień.
- Jak obsługiwana jest synchronizacja zamówień historycznych. Import archiwum bywa operacją na dziesiątkach tysięcy rekordów i potrafi obciążyć bazę na godziny. Warto zaplanować go poza godzinami szczytu i wykonać na środowisku testowym.
- Gdzie zapisywane są pola dodatkowe. Numery przesyłek, identyfikatory z systemów zewnętrznych i statusy dodatkowe trafiają zwykle do metadanych zamówienia. W modelu HPOS to
wp_wc_orders_meta, niewp_postmeta. Raporty i eksporty odwołujące się do starej lokalizacji przestaną działać.
Co uwzględnić w kopii zapasowej sklepu?
Kompletna kopia zapasowa WooCommerce obejmuje bazę danych i pliki. Pominięcie jednego z tych elementów oznacza, że odtworzenie sklepu nie będzie możliwe.
Tabele bazy danych:
- Tabele WordPressa:
wp_posts,wp_postmeta,wp_users,wp_usermeta,wp_options,wp_terms,wp_term_taxonomy,wp_term_relationships - Tabele zamówień HPOS:
wp_wc_orders,wp_wc_order_addresses,wp_wc_order_operational_data,wp_wc_orders_meta - Pozycje zamówień:
wp_woocommerce_order_items,wp_woocommerce_order_itemmeta - Tabele pomocnicze i konfiguracyjne:
wp_wc_customer_lookup,wp_wc_product_meta_lookup,wp_wc_order_stats,wp_wc_download_log,wp_wc_webhooks,wp_woocommerce_tax_rates,wp_woocommerce_shipping_zones
Najprostsza i najbezpieczniejsza zasada brzmi: kopiuj całą bazę. Selektywne listy tabel mają tę wadę, że nie uwzględniają tabel dodawanych przez wtyczki, a to właśnie one przechowują dane integracji.
Katalogi na serwerze:
/wp-content/uploads/– zdjęcia produktów i wszystkie media/wp-content/uploads/woocommerce_uploads/– pliki produktów cyfrowych/wp-content/plugins/i/wp-content/themes/– wtyczki, motyw i własne modyfikacjewp-config.php– konfiguracja połączenia z bazą i klucze bezpieczeństwa
Częstotliwość. Struktura danych podpowiada, jak ją różnicować. Zamówienia i dane klientów zmieniają się codziennie, więc baza wymaga kopii dziennej, a przy wysokich wolumenach częstszej. Zdjęcia produktów zmieniają się rzadko, więc pełna kopia plików raz w tygodniu zwykle wystarcza. To rozwiązanie tańsze i szybsze niż codzienna kopia całego serwisu.
Test odtworzenia. Kopia zapasowa, której nigdy nie odtwarzaliście, jest założeniem, nie zabezpieczeniem. Warto raz na kwartał odtworzyć sklep na środowisku testowym i sprawdzić, czy produkty się wyświetlają, zamówienia są kompletne, a klienci mogą się zalogować.
Gdzie ta architektura przestaje wystarczać?
Domyślna struktura danych WooCommerce dobrze obsługuje większość sklepów. Powyżej pewnej skali zaczyna jednak ograniczać, i warto rozpoznać moment, w którym to następuje.
Sygnały, które widzimy w audytach:
- Panel zamówień ładuje się kilkanaście sekund, a filtrowanie po statusie zajmuje więcej
- Tabela
wp_postmetaprzekracza kilka gigabajtów - Import lub aktualizacja katalogu blokuje sklep na czas trwania operacji
- Raporty sprzedażowe przestają się generować albo przekraczają limity czasu wykonania
- Wzrost ruchu w kampanii kończy się błędami bazy danych
Kierunki, którymi się to rozwiązuje:
- Migracja do HPOS, jeżeli sklep nadal działa na modelu starszym. To zwykle pierwszy krok i często wystarczający.
- Własne tabele dla danych o wysokiej częstotliwości zapisu, na przykład stanów magazynowych synchronizowanych z systemem zewnętrznym co kilka minut.
- Cache obiektowy na Redisie zdejmujący z bazy powtarzalne zapytania.
- Indeksy dopasowane do rzeczywistych zapytań sklepu, a nie do konfiguracji domyślnej.
- Architektura headless lub hybrydowa przy katalogach powyżej stu tysięcy pozycji, gdzie warstwa prezentacji przestaje być wąskim gardłem, a staje się nim samo odpytywanie bazy.
Żadne z tych rozwiązań nie jest uniwersalne. Wybór zależy od tego, co konkretnie stanowi wąskie gardło, a to da się ustalić wyłącznie pomiarem, nie założeniem.
Najważniejsze wnioski
- WooCommerce łączy tabele WordPressa z własnymi. Produkty są typem wpisu, zamówienia w nowoczesnych instalacjach mają dedykowane tabele.
- HPOS jest domyślny od października 2023 roku. Zanim zaczniecie pracować z danymi zamówień, sprawdźcie, który model działa w Waszym sklepie.
- Odwołujcie się do zamówień przez warstwę
WC_Order, nie przez funkcje operujące na metadanych wpisów. To najczęstsza przyczyna awarii integracji. - Pliki leżą poza bazą. Kopia samej bazy nie odtworzy sklepu.
- Struktura domyślna wystarcza do pewnej skali. Powyżej niej potrzebne są decyzje architektoniczne, a nie kolejne wtyczki optymalizacyjne.
FAQ
Czy WooCommerce przechowuje dane w MySQL?
Tak. WooCommerce korzysta z tej samej bazy MySQL lub MariaDB co WordPress, używając zarówno tabel WordPressa, jak i własnych tabel dodawanych przez wtyczkę.
Gdzie dokładnie leżą zamówienia WooCommerce?
W instalacjach z włączonym HPOS w tabelach wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data i wp_wc_orders_meta. W sklepach na starszym modelu w wp_posts jako typ wpisu shop_order oraz w wp_postmeta. Pozycje zamówień w obu przypadkach leżą w wp_woocommerce_order_items i wp_woocommerce_order_itemmeta.
Czy muszę migrować sklep do HPOS?
Nie ma takiego obowiązku, ale kierunek rozwoju WooCommerce jest jednoznaczny. Migracja ma największy sens przy wysokich wolumenach zamówień i przy odczuwalnie wolnym panelu administracyjnym. Wymaga wcześniejszego sprawdzenia zgodności wszystkich wtyczek i integracji.
Czy WooCommerce obsłuży dużą bazę danych?
Tak, przy odpowiednim przygotowaniu. Sklepy z setkami tysięcy produktów i dużym wolumenem zamówień działają na tej platformie, ale wymagają optymalizacji: HPOS, cache obiektowego, właściwych indeksów, a czasem własnych tabel dla wybranych typów danych.
Gdzie WooCommerce trzyma zdjęcia produktów?
W katalogu /wp-content/uploads/ na serwerze, uporządkowane według roku i miesiąca. W bazie danych zapisany jest wyłącznie odnośnik do pliku i jego metadane.
Jak sprawdzić rozmiar tabel WooCommerce?
Przez phpMyAdmin, w widoku listy tabel z kolumną rozmiaru, albo poleceniem WP-CLI wp db size --tables. Tabele, którym warto się przyjrzeć w pierwszej kolejności, to wp_postmeta, wp_options oraz wp_actionscheduler_actions i wp_actionscheduler_logs, które w sklepach o dużym ruchu potrafią rosnąć bez kontroli.
Panel zamówień działa coraz wolniej, a integracje rozjeżdżają dane? Zaczniemy od audytu bazy i warstwy integracyjnej. → Zamów audyt



