Jeśli Twój sklep stoi na WooCommerce od kilku lat, prawdopodobnie nadal trzyma zamówienia w tym samym miejscu co wpisy na blogu - w ogólnych tabelach WordPressa. HPOS WooCommerce, czyli High-Performance Order Storage, to nowszy sposób przechowywania zamówień: sklep dostaje własne tabele w bazie, zaprojektowane pod handel, a nie pod treści. Sklepy zakładane dziś mają to włączone od pierwszego dnia. Starsze - nie, dopóki ktoś ręcznie nie przestawi ustawienia.
I to jest dokładnie ten rodzaj zmiany, który u jednego klienta zajmuje kwadrans, a u drugiego kończy się panelem zamówień, w którym połowa integracji przestaje widzieć nowe zakupy. Różnica nie leży w samym przełączniku, tylko w tym, co sklep ma wokół niego: wtyczki do faktur, kurierów, Baselinkera, własny kod motywu dopisany kiedyś przez kogoś innego.
Poniżej pokazuję po kolei: co ta zmiana naprawdę robi w bazie, co potrafi się przy niej wysypać, jak ją przeprowadzić tak, żeby dało się wrócić, i kiedy w ogóle warto ją ruszać. Bez wchodzenia w kod głębiej, niż to potrzebne właścicielowi sklepu.
HPOS w WooCommerce - co zmienia w bazie i dlaczego stare sklepy tego nie mają
WordPress od zawsze trzyma prawie wszystko w dwóch tabelach: jednej na wpisy i jednej na ich dodatkowe dane. Wpis na blogu, strona, produkt, a przez lata także zamówienie - wszystko lądowało w tym samym worku. Dla bloga to rozwiązanie wystarczające. Dla sklepu, który po kilku latach ma kilkanaście tysięcy zamówień, zaczyna być ciasne: każde pytanie w stylu „pokaż zamówienia tego klienta z ostatniego miesiąca” musi przekopać się przez tabelę, w której leży też cała reszta strony.
HPOS rozwiązuje to najprościej, jak się da: zamówienia dostają własne tabele. W bazie pojawiają się wc_orders, wc_order_addresses, wc_order_operational_data i wc_orders_meta - osobne miejsca na samo zamówienie, na adresy, na dane operacyjne i na metadane. Zapytania nie muszą już przebijać się przez wpisy, bo pytają wprost o zamówienia.
Dlaczego Twój sklep może tego nie mieć? Bo WooCommerce nie przestawił tego nikomu wstecz. Od wersji 8.2, wydanej w październiku 2023, HPOS jest domyślny dla nowych instalacji. Sklepy założone wcześniej zostały przy starym magazynie zamówień i tak zostanie, dopóki ktoś świadomie nie zmieni ustawienia. To rozsądna decyzja WooCommerce - automatyczna migracja danych w tysiącach sklepów z nieznanym zestawem wtyczek skończyłaby się falą awarii.
Sprawdzenie, co masz u siebie, zajmuje chwilę: w panelu wchodzisz w WooCommerce > Settings > Advanced > Features (w polskim tłumaczeniu nazwy menu mogą brzmieć nieco inaczej) i patrzysz na sekcję odpowiadającą za przechowywanie zamówień. Zobaczysz tam dwie opcje: WordPress posts storage (legacy) i High-performance order storage (recommended). Zaznaczona jest ta, na której sklep aktualnie pracuje.
Co pomaga: zanim zaczniesz cokolwiek przestawiać, zrób zrzut ekranu tego ustawienia razem z listą wtyczek. Gdy za tydzień coś zacznie się dziwnie zachowywać, będziesz wiedzieć, od jakiego stanu wyszedłeś.
Co może się zepsuć - wtyczki, integracje i własny kod
Sama zmiana miejsca przechowywania zamówień jest bezpieczna. Niebezpieczne jest to, że spora część kodu wokół sklepu została napisana przy założeniu, że zamówienie to wpis WordPressa.
Najczęstsze źródła kłopotów, w kolejności, w jakiej je spotykam:
- Wtyczki, które zapisują dane wprost do tabeli wpisów. Dopisek do zamówienia, numer listu przewozowego, status wysyłki - jeśli wtyczka wkłada to starą metodą, przy HPOS trafia w puste miejsce. Zamówienie działa, ale konkretne pole znika.
- Własny kod w motywie. Klasyka to funkcje
update_post_meta()iget_post_meta()użyte do zamówień. Działają, dopóki sklep siedzi na starych tabelach, i cicho przestają po przełączeniu. Poprawny sposób to metody obiektu zamówienia:$order->update_meta_data()i$order->get_meta(). Pisałem o tym szerzej przy okazji własnych pól w checkoucie. - Integracje zewnętrzne. Baselinker, systemy fakturowe, wtyczki kurierskie i eksporty do księgowości - większość znanych rozwiązań jest dziś zgodna, ale wersja sprzed dwóch lat, której nikt nie aktualizował, już niekoniecznie. Jeśli po zmianie Baselinker przestanie pobierać zamówienia, pierwszym podejrzanym jest właśnie przestarzała wtyczka łącząca.
- Stare raporty i skrypty jednorazowe. Wszystko, co ktoś kiedyś napisał, żeby raz w miesiącu wyciągnąć dane zapytaniem do bazy, trzeba przejrzeć osobno. Panel tego nie zgłosi.
Dobra wiadomość: WooCommerce nie pozwoli Ci wejść na minę z zamkniętymi oczami. Na ekranie ustawień sprawdza zainstalowane rozszerzenia pod kątem zgodności i jeśli któreś nie deklaruje wsparcia dla nowego magazynu zamówień, opcja przełączenia jest zablokowana, a obok pojawia się odnośnik View and manage z listą problematycznych wtyczek. To jest Twój pierwszy konkretny materiał do pracy: albo aktualizujesz je do nowszych wersji, albo szukasz zamienników, albo zostajesz przy starym magazynie.
Warto wiedzieć, że brak na liście nie jest pełną gwarancją. Lista pokazuje wtyczki, które oficjalnie zadeklarowały zgodność albo jej brak. Kod dopisany bezpośrednio w motywie ani prywatna wtyczka napisana na zamówienie nie deklarują niczego i nikt ich nie sprawdzi za Ciebie.
Jak włączyć bezpiecznie krok po kroku (staging, synchronizacja, cofnięcie)
Kolejność ma tu większe znaczenie niż sama operacja. Tak to prowadzę:
- Pełna kopia zapasowa - pliki i baza. Nie sama baza. Kopia musi być na tyle świeża, żeby powrót z niej oznaczał utratę minut, nie dni.
- Kopia sklepu na środowisku testowym. Przełączenie testuje się na kopii, nie na sklepie, który przyjmuje zamówienia. Na stagingu przechodzisz całą ścieżkę: złóż zamówienie testowe, wystaw fakturę, nadaj paczkę, sprawdź eksport do księgowości i integracje, które masz podpięte.
- Aktualizacja wtyczek przed zmianą, nie w trakcie. Zgodność z nowym magazynem zamówień przyszła wraz z nowszymi wersjami. Aktualizacje robisz według tej samej checklisty bezpiecznych aktualizacji WooCommerce, osobnym ruchem, żeby przy ewentualnej awarii wiedzieć, co ją wywołało.
- Włączenie trybu zgodności. W tych samych ustawieniach jest pole Enable compatibility mode (synchronizes orders to the posts table). Tryb zgodności utrzymuje dane zamówień jednocześnie w nowych tabelach i w starych tabelach wpisów. Jest wolniejszy, bo sklep zapisuje wszystko dwa razy, ale to on daje Ci drogę powrotu.
- Przełączenie na nowy magazyn i odczekanie na przepisanie danych. WooCommerce nie kopiuje wszystkiego w jednej chwili - planuje zadania w tle, które stopniowo przenoszą zamówienia. Sklepu nie trzeba na ten czas wyłączać ani zamykać na klucz. Trzeba natomiast poczekać, aż zadania się skończą, zanim uznasz operację za zakończoną.
- Dzień obserwacji. Przez pierwszą dobę sprawdzasz to, co dotyka zamówień: czy nowe zamówienia wpadają na listę, czy maile wychodzą, czy faktury się wystawiają, czy integracja z magazynem widzi świeże pozycje.
Cofnięcie wygląda tak samo, tylko w drugą stronę: upewniasz się, że tryb zgodności jest włączony i że synchronizacja doszła do końca, a dopiero potem wybierasz WordPress posts storage (legacy). Dlatego trybu zgodności nie wyłącza się od razu po udanej migracji - dopóki jest włączony, masz wyjście awaryjne. To ta sama logika, którą stosuję przy każdej przebudowie i optymalizacji istniejącego sklepu: zmiana wchodzi dopiero wtedy, gdy wcześniej wiem, jak z niej wyjść.
Co pomaga: ustal z góry, po czym poznasz, że coś poszło źle. Najlepiej po czymś mierzalnym, co i tak sprawdzasz codziennie - liczbie zamówień, które dotarły do systemu magazynowego. Jeśli rano zgadza się z liczbą z panelu sklepu, migracja się udała.
Kiedy to ma sens i co robię inaczej
Zacznę od rzeczy, której nie obiecam: konkretnego przyspieszenia. Ile zyskasz, zależy od liczby zamówień, hostingu, wtyczek i tego, jak rozrośnięta jest baza. Sklep z kilkuset zamówieniami na starym, ciasnym hostingu nie poczuje różnicy, bo jego problemem nie są tabele zamówień, tylko wszystko inne - o czym piszę w tekście o tym, dlaczego sklep WooCommerce działa wolno. Sklep z kilkudziesięcioma tysiącami zamówień i wolno otwierającą się listą zamówień w panelu to zupełnie inna rozmowa i tam zmiana potrafi być odczuwalna od razu.
Moja kolejność jest taka: najpierw ustalam, czy sklep faktycznie zwalnia na zamówieniach, czy gdzie indziej. Jeśli klienta boli strona produktu, a nie panel, przestawianie magazynu zamówień niczego nie naprawi i tylko dołoży ryzyko. Jeśli boli panel i wolno działająca baza zamówień - wtedy HPOS jest właściwym narzędziem.
Druga rzecz, którą traktuję inaczej niż większość poradników: nie zostawiam trybu zgodności włączonego na zawsze. Bywa, że po migracji zostaje on „na wszelki wypadek” i sklep latami zapisuje wszystko podwójnie, tracąc dokładnie to, po co przechodził na nowe tabele. Tryb zgodności to szalupa ratunkowa, a nie stan docelowy. Zdejmuję go po okresie obserwacji, kiedy wiem, że nic nie wraca do starych tabel.
Trzecia rzecz jest nowa i warto ją znać, jeśli ruszasz ten temat teraz. Do niedawna istniał mechanizm synchronizacji działający także w drugą stronę: gdy jakiś kod zapisywał dane wprost do starych tabel z pominięciem WooCommerce, sklep potrafił to dociągnąć. W wersji 10.7, wydanej 14 kwietnia 2026, WooCommerce wyłączył tę synchronizację przy odczycie domyślnie i zapowiedział, że w przyszłości zniknie całkiem. Praktyczny skutek: kod, który jeszcze rok temu jakoś się bronił, dziś po cichu przestaje działać. Jeśli w Twoim sklepie siedzi taka wtyczka albo taki fragment motywu, kończy się czas na odkładanie poprawki - i dotyczy to tak samo sklepów, które na HPOS przeszły dawno temu.
Podsumowanie
HPOS przenosi zamówienia z ogólnych tabel WordPressa do własnych tabel sklepu. Nowe sklepy mają to od początku, starsze siedzą na starym magazynie, dopóki ktoś świadomie nie przełączy ustawienia. Sama zmiana to jeden przełącznik, ale wartość całej operacji leży w tym, co robisz wokół niego: kopia, test na kopii sklepu, aktualizacja wtyczek osobnym ruchem, tryb zgodności jako droga powrotu i doba obserwacji.
Jeśli nie wiesz, czy Twój sklep już na tym stoi, ani które z Twoich wtyczek to przeżyją - podeślij mi adres sklepu i listę integracji. Sprawdzę, na jakim magazynie zamówień pracujesz, co blokuje zmianę i czy w Twoim przypadku w ogóle jest o co walczyć.
Najczęstsze pytania
Skąd mam wiedzieć, czy mój sklep już używa HPOS? W panelu WooCommerce, w ustawieniach zaawansowanych, w sekcji funkcji, znajdziesz wybór między starym magazynem opartym o wpisy WordPressa a nowym, wydajnym magazynem zamówień. Zaznaczona opcja mówi wszystko. Jeśli sklep powstał po październiku 2023 i nikt tego nie ruszał, najprawdopodobniej pracuje już na nowych tabelach.
Czy przy migracji stracę stare zamówienia? Nie, przepisanie danych do nowych tabel jest kopiowaniem, a nie przenoszeniem z kasowaniem - stare tabele zostają na miejscu. Właśnie dlatego powrót do starego magazynu jest możliwy. To nie zwalnia z robienia kopii zapasowej przed operacją, bo kopia chroni przed wszystkim innym, co może pójść nie tak przy okazji.
Czy sklep musi być zamknięty na czas migracji? Nie musi. WooCommerce planuje przepisanie zamówień jako zadania działające w tle, więc sklep przez ten czas normalnie sprzedaje. Sam moment przełączenia i tak lepiej wybrać na godziny o najmniejszym ruchu - nie dlatego, że coś tego wymaga, tylko dlatego, że jeśli coś pójdzie nie tak, dotknie mniej klientów.
Wtyczka, której używam, jest na liście niezgodnych. Co teraz? Po kolei: sprawdź, czy istnieje jej nowsza wersja, bo zgodność najczęściej dochodziła wraz z aktualizacjami. Jeśli wtyczka nie jest rozwijana, szukaj zamiennika albo zamów poprawkę u programisty - w większości przypadków to kwestia zmiany sposobu zapisu danych zamówienia, a nie przepisywania całej wtyczki. Do czasu rozwiązania sprawy zostań przy starym magazynie; przełączenie na siłę z niezgodną wtyczką to najprostsza droga do utraty danych zamówień.
Masz to u siebie i nie wiesz, od czego zacząć? Przyspieszam i naprawiam istniejące strony i sklepy - Core Web Vitals, awarie, rozbudowa o funkcje, których brakuje. Porozmawiajmy o projekcie.