Headless WooCommerce z Astro

Headless WooCommerce to nie nowy sklep. Panel wp-admin, stany, zamówienia i bramki zostają. HTML, który pobiera klient, przestaje być motywem PHP. Astro 7 składa katalog. Kasa, jeśli sklep ma brać Blika i Paczkomaty, zostaje na WooCommerce.

Klasyczne żądanie WooCommerce odpala PHP, object cache, listę wtyczek i motyw, dla karty produktu, która nie zmieniła się od wtorku. Cache HTML przed originem załatwia sporo. Headless to kolejne cięcie: katalog jest drzewem plików, koszyk małą wyspą, pieniądze nadal trafiają w origin, który już masz w zakresie PCI.

Ten tekst jest o rozdziale. Warstwy cache, TTFB i LCP z pola zostawiamy w Headless WooCommerce z Astro, wydajność sklepu. Filar programisty WooCommerce i programisty Astro to oferty. Samą topologię, bez koszyka, opisuje przewodnik architektury headless WordPress.

Portent zmierzył spadek konwersji o około 4,42% na każdą dodatkową sekundę ładowania. To nachylenie, nie obietnica, że Astro drukuje utarg. Idziemy w headless, gdy motyw i lista wtyczek są sufitem, nie gdy briefem jest zrzut PageSpeed.

#Co zostaje w WooCommerce

Back office się nie rusza. Produkty, warianty, stany, kupony, zamówienia, zwroty, raporty. Przelewy24, PayU, Autopay, Stripe, PayPal. Table rate i Flexible Shipping. Wtyczki podatkowe. Złącza ERP, które zapisują zamówienia. To jest PHP i ma zostać PHP.

Z witryny znika motyw: header.php, szablon produktu, widżet mini-koszyka, Elementor na stronie głównej, wtyczka zoomu, karuzela „dobierz komplet”, która dokłada setki kilobajtów, żeby pokazać trzy SKU.

Redaktorzy zostają w tym samym wp-admin. Jeśli nie mogą, nie zrobiliście headless. Zrobiliście drugi PIM i w trzecim miesiącu będziecie tego żałować.

Katalog w PLN, stawki VAT, jednostki miary, atrybuty rozmiaru w siatce europejskiej: to dane produktu, nie szablon. Zostają w Woo. Cena na karcie katalogu jest ceną merchandisingową. Linia na kasie jest linią księgową. Tego nie odwracamy.

xmlrpc i publiczna trasa użytkowników REST nadal wymagają tego samego utwardzenia, co każdy origin WordPress. Headless nie chowa wp-admin. Postaw Access przed panelem. CDN katalogu nie jest firewallem.

BaseLinker, Allegro (wtyczka oficjalna), feed Ceneo, feed Google Merchant: czytają produkty i zamówienia z Woo, nie z motywu. Śmierć motywu ich nie rusza. Widżet gwiazdek Ceneo wpięty w woocommerce_single_product_summary rusza. To dwa różne byty, choć marketing nazywa oba „integracją Ceneo”.

#Wtyczka, która umiera z motywem

To inwentaryzacja, której nikt nie chce zrobić, i to jest całe ryzyko.

Umiera z motywem (odbuduj jako wyspę albo zdejmij):

• Swatche wariantów, które zamieniają select na kropki kolorów
• Szybki podgląd i ajaxowe dodanie do koszyka w pętli
• Zoom zdjęcia i przeglądarki 360
• Popup doklejki, belki fałszywego deficytu, widżety „inni kupili też” drukowane w woocommerce_after_shop_loop
• Page builder na stronie głównej i landingach SKU
• Wtyczki kasy jednostronicowej, które przejmują szablony checkout
• Estymator „dostawa do jutra” namalowany HTML-em na karcie produktu
• Gwiazdki Opineo albo Ceneo wpięte w motyw, nie w feed

Zostaje (API albo webhook, bez motywu):

• Bramki płatności
• Wysyłka i odbiór (stawki InPost, odbiór osobisty, table rate, Flexible Shipping)
• Podatek, w tym OSS
• Subskrypcje i członkostwa, o ile status jest odpytywany, a nie malowany CSS-em wtyczki
• MailerLite, Salesmanago, Edrone przez haki zamówienia
• ERP (zobacz filar integracji WooCommerce z ERP)
• BaseLinker, Allegro, Fakturownia, wFirma, Infakt, gdy słuchają zamówienia, nie szablonu

Jeśli sztuczki konwersji sklepu żyją na pierwszej liście, headless jest przebudową witryny, nie projektem prędkości. Wyceniaj to jako przebudowę. Zakres programisty WooCommerce ten podział nazywa wprost. Widzieliśmy sklep, który „poszedł w headless”, a potem wgrał stary motyw z powrotem na kasę, bo wtyczka kasy jednostronicowej była właściwym produktem. To dwie witryny. Nie rób tego.

Przydatny test: na stagingu wyłącz motyw i otwórz URL produktu na pustym motywie albo ?theme=noop. Co zostaje (cena, stan, dodanie do koszyka przez Store API) zostaje w architekturze. Co zniknęło (swatche, znaczki, HTML estymatora dostawy) jest pracą. Jeśli zniknięta lista jest powodem zakupu, budżetuj wyspy. Jeśli to dekoracja, zdejmij.

Produkty złożone, bundle i dodatki do produktu są szarą strefą. Część wystawia REST, część tylko filtruje woocommerce_add_to_cart. Jeśli dodanie bundla 404 na Store API, ten SKU nie jest katalogiem statycznym, dopóki ktoś nie napisze mapowania. Nie odkrywaj tego rano w dniu przełączenia.

W polskich sklepach szara strefa ma jeszcze dwa nazwiska. Flexible Product Fields i TM Extra Product Options często trzymają grawer, długość firany albo wybór opakowania prezentowego. Pola zapisują się jako meta pozycji. Store API część z nich widzi, część milczy. Na stagingu dodaj do koszyka SKU z polem obowiązkowym, potem otwórz kasę Woo i sprawdź, czy meta doszła. Jeśli nie, ten SKU zostaje na PHP albo dostaje ręczny mapper.

Druga dziura: wtyczki „dostawa przed 16:00, jutro w Paczkomacie”, które malują obietnicę z kodu pocztowego gościa. To nie jest stawka Flexible Shipping. To HTML motywu plus czasem hit do API InPost. Na statycznej karcie produktu nie masz kodu pocztowego. Albo zdejmujesz obietnicę, albo liczysz ją w wyspie przy buy boxie, albo zostawiasz na kasie, gdzie kod pocztowy i tak padnie.

#Astro 7 dla katalogu

Domyślny kontrakt Astro 7 to HTML i CSS. JavaScript tylko tam, gdzie oznaczysz wyspę.

Katalog, który ma być statyczny:

• Strona główna, kategoria, produkt, treści, regulaminy
• getStaticPaths z listy produktów w buildzie
• AVIF z biblioteki mediów, sizes dopasowane do siatki, nie 100vw na miniaturze szerokości 320 px

Wyspy:

• Dodaj do koszyka, ilość, wybór wariantu
• Mini-koszyk
• Szukajka, która bije w indeks, nie w PHP ?s=
• Może Stripe Elements na własnym kroku płatności, jeśli naprawdę nie możesz przekierować (w sklepie z Blikiem prawie nigdy nie możesz)

client:visible na dodaniu do koszyka. client:idle na szukajce. Karta produktu, która wciąga cały pakiet ikon do wyspy, już zgubiła punkt. Ta sama reguła co na każdym innym froncie Astro 7: wyspa to komponent, nie pretekst, żeby zhydratować stronę.

Przebudowy: webhook updated produktu przebudowuje tę ścieżkę albo mały zbiór ścieżek (produkt, jego kategorie, home jeśli merchandisinguje). Pełna przebudowa katalogu co dziesięć minut to sposób, w jaki ludzie odkrywają, że mają czterdzieści tysięcy SKU. Przyrostowo albo na żądanie. Cloudflare albo host, którego naprawdę używacie. Nie „Vercel, bo tak było w tutoriale”, jeśli reszta stosu już stoi na Cloudflare.

Szukajka: PHP ?s= to hit PHP. Na statycznym katalogu szukajka to albo indeks w przeglądarce (małe katalogi), albo indeks zewnętrzny (Meilisearch, Typesense, Algolia) zasilany z tego samego payloadu co SSG, albo zapytanie Store API / REST przez wyspę. Nie wysyłaj pola szukajki do WordPressa, jeśli reszta sklepu tego nie robi. Facety, które potrzebują żywego stanu, należą obok buy boxu, nie w HTML-u SSG.

Produkty powiązane: jeśli są merchandisingowane w wp-admin, są danymi. Pobierz je w buildzie. Jeśli to woocommerce_output_related_products z motywu, nigdy nie były danymi, były szablonem. Złóż statyczny pasek z tej samej kategorii albo zdejmij.

Obrazy zostają w bibliotece mediów WordPressa. Astro czyta URL-e albo krok buildu kopiuje AVIF. Nie wymyślaj drugiego DAM, chyba że już go macie. Obraz LCP nadal jest bohaterem karty produktu. Headless nie wybiera formatu za ciebie. Liczby cache i wagi payloadu Store API są w przewodniku wydajności.

Podgląd: redakcja musi zobaczyć szkic produktu na hoście Astro. Webhook albo token podglądu, który ciągnie jeden produkt z originu, wystarcza. Jeśli podgląd znaczy „zaloguj się do wp-admin i użyj customizera motywu”, rozdział nie jest skończony i będą prosić o stary motyw.

#Store API kontra GraphQL

Dwie rury. Mieszanie ich to zwykle rana zadana sobie samemu.

Build katalogu: WPGraphQL plus WooGraphQL albo endpoint REST produktów, w czasie buildu. Jedno zapytanie na kartę produktu. Chcesz nazwę, ceny, status stanu, zdjęcia, kategorie, atrybuty. Nie chcesz koszyka.

Koszyk i sesja: WooCommerce Store API (/wp-json/wc/store/v1/cart). On ma ciasteczko koszyka, nonce, kupony, wyliczenie wysyłki. To ciasteczko musi być na originie, który później przyjmie kasę. Jeśli Astro stoi na sklep.example.pl, a Woo na cms.example.pl, masz problem ciasteczka, zanim masz problem Reacta. Ta sama witryna albo udokumentowany proxy.

Widzimy zespoły, które dodają do koszyka mutacją WooGraphQL, bo katalog już mówi GraphQL. Potem strona kasy WooCommerce pokazuje pusty koszyk, a Przelewy24 nie ma czego opłacić. Sesja się nie przeniosła. Store API do koszyka. GraphQL do payloadu SSG. To zdanie warto mieć na tablicy w sprintcie, nie w retrospektywie po starcie.

Ciasteczka same-site: jeśli Astro jest na apeksie, a WordPress na wp., ustaw domenę ciasteczka koszyka wprost i proxy /wp-json/wc/store/ na origin. CORS na Store API nie zastępuje ciasteczka. SameSite=Lax przy przekierowaniu kasy między dwoma hostami wygląda jak „Blik działa na stagingu” (ten sam host) i „pusty koszyk na produkcji” (dwa hosty). Jeden hostname dla kupującego, wewnętrzny hostname dla wp-admin.

Wygaśnięcie nonce na statycznej stronie to prawdziwy błąd, nie anegdota. Wyspa koszyka musi pobrać świeży nonce ze Store API przy hydracji, nie wkleić go w HTML SSG z porannego buildu. Nonce wszyte w poranny HTML po kilku godzinach oddają 403 i przycisk „Dodaj do koszyka” „nic nie robi”. Ticket, który dostajemy najczęściej po starcie, brzmi dokładnie tak.

Stan w buildzie jest migawką. Wyczerpany rozmiar nadal w HTML to zwrot. Webhook woocommerce_product_set_stock (albo odpowiednik wariantu) musi unieważnić tę ścieżkę. Jeśli nie umiecie, nie róbcie SSG buy boxu. Renderuj buy box ze Store API w żądaniu, nadal jako małą wyspę. HTML katalogu może zostać statyczny.

Kupon w wyspie: Store API liczy go na originie. Nie licz rabatu w Astro „żeby było szybciej”. Kupon kwotowy, procentowy, darmowa dostawa od progu, kupon na kategorię: to reguły Woo. Wyspa wysyła kod, origin zwraca linie. Jeśli pokażesz na froncie inną kwotę niż kasa, klient napisze na infolinię zrzut z dwóch ekranów.

#InPost, Przelewy24 i kasa, której nie odpinasz

Tutorial ze Stripe Elements milczy o Paczkomatach i Bliku. Konwersja polskiego sklepu siedzi na kasie, a kasa to stos wtyczek, które drukują HTML w szablony Woo.

Mapka Paczkomatów nie jest polem select z listą miast. Wtyczka InPost PL (często z rodziny WP Desk) albo oficjalna wtyczka InPost wpinają widżet w szablon kasy: geolokalizacja, lista punktów, zapis paczkomat_id w meta zamówienia, potem etykieta i tracking. Hook siedzi obok woocommerce_review_order_after_shipping albo w kroku dostawy. Na katalogu Astro ta mapa nie ma gdzie się wpiąć. Jeśli zrobisz własny select punktów w wyspie, i tak musisz zapisać tę samą meta, której oczekuje wtyczka etykiet. Magazyn o 16:00 klika „drukuj etykiety”. Puste meta to nie „drobny dług techniczny”. To paczki bez naklejek.

InPost Pay, Geowidget, odbiór w punkcie Orlen Paczka, DPD Pickup, Pocztex: ten sam wzorzec. Stawka Flexible Shipping zostaje, bo to PHP na originie. Wybór punktu jest sąsiadem motywu. Headless katalogu nie zabiera stawek. Zabiera widżet, jeśli odpinasz kasę.

Przelewy24, PayU, Blik, Autopay (dawniej Blue Media) to bramki Woo. Blik zwykle nie jest osobną wtyczką. Jest metodą wewnątrz P24 albo PayU. Zwrot z banku, powiadomienie i 3-D Secure muszą trafić w origin, nie w CDN Astro. Ścieżki w stylu /?wc-api=WC_Gateway_Przelewy24 i odpowiedniki PayU należą do listy pominięć cache, każda z nazwą. Kasa jako wyspa Astro znaczy, że te powroty musisz zreimplementować. Domyślnie tego nie robimy.

Widzieliśmy sklep z zabawkami, który po tutorialu ze Stripe Elements schował Blika, bo „karta jest nowocześniejsza”. Na telefonie polski checkout bez Blika to inny sklep. Po dwóch tygodniach wrócili do kasy Woo i zostawili Astro na katalogu. To była właściwa korekta, nie porażka headless. Porażką było odpięcie kasy.

Raty PayU albo P24, Płacę później, Apple Pay w bramce: JS dostawcy ładuje się na szablonie kasy. Na własnej kasie Astro ładujesz go sam i bierzesz na siebie zwroty, retry nieudanej płatności i link „opłać zamówienie” z maila. To produkt. To nie jest domyślny zakres rozdziału katalogu.

Faktura nadal powstaje na originie. Nie rozpisuję tu JPK ani KSeF. XML faktury, KSeF i JPK_V7M wychodzą z systemu, który usłyszał zamówienie Woo. Flexible Invoices, wFirma, Fakturownia, Infakt, Comarch, Subiekt nexo. Hak woocommerce_order_status_processing albo opłacone. Astro nie wystawia faktury. Jeśli własna kasa robi PaymentIntent w Stripe i dopiero później POSTuje zamówienie do Woo, wtyczka faktur albo milczy, albo dostaje dokument bez stawek VAT i bez NIP. Księgowość tego nie przełknie. Zostaw urodziny zamówienia tam, gdzie księgowość już słucha.

Pole NIP, checkbox „zakup na firmę”, podpowiedź GUS: to pola kasy z polskich wtyczek, nie z karty produktu. Na Astro ich nie odtwarzamy „dla spójności brandu”. Zostają na PHP. Za pobraniem też: to metoda płatności plus metoda wysyłki na originie.

Hybryda, którą stawiamy: statyczny katalog, koszyk jako wyspa Store API, odnośnik „Do kasy” na /kasa/ albo /checkout/ Woo, cache omija tę ścieżkę, ciasteczko koszyka już siedzi. Każda bramka, każdy podatek, każdy mail „zamówienie przyjęte”, każdy hak woocommerce_thankyou (ERP, faktura, BaseLinker) nadal strzela. Zakres PCI zostaje tam, gdzie był.

Strony zamówienie-przyjęte i moje-konto mogą zostać na WooCommerce. „Headless” nie znaczy „każdy URL jest Astro”. Znaczy: URL-e, w które leci reklama, są plikami. /moje-konto/ za Access albo za logowaniem jako PHP jest w porządku.

VAT i OSS nadal liczą się na originie. Statyczna cena w PLN na karcie produktu jest ceną merchandisingową. Linia kasy jest linią prawną. Nie rób SSG cen per kraj, chyba że robisz też SSG ścieżek per kraj i umiesz je unieważniać. Większość sklepów pokazuje cenę katalogową i pozwala Woo nałożyć podatek na kasie. To jest dozwolone. Pokazanie starej kwoty brutto gościowi z innego kraju VAT to mail z księgowości.

Webhooki bramek (/?wc-api=, Przelewy24, PayU, Stripe) muszą trafić w origin, nie w CDN Astro. Pomijaj te ścieżki w cache. Ta sama dyscyplina co na WAF: każde pominięcie ma nazwę.

Nie „dokańczaj headless” przepisaniem jedynego szablonu, który już bierze Blika. Argument konwersji na polskich sklepach, które rozdzielaliśmy, brzmiał: karta produktu jest miejscem odbicia, kasa nie. Zostaw kasę. Zdejmij PHP z URL-a produktu.

#Stan magazynowy i cache

Pliki statyczne na CDN skalują się. Stan magazynowy nie. Dwóch klientów kupujących ostatni SKU to problem sklepu, nie zrzutu PageSpeed.

Wzorzec, który się trzyma:

1. HTML katalogu jest statyczny, w tym cena, aż webhook powie inaczej.
2. Buy box pyta Store API o stock_status przy hydracji wyspy, albo akceptujesz krótkie okno nieświeżości i uzgodnienie na kasie (WooCommerce i tak odmawia nadprzedaży, jeśli tak skonfigurowałeś).
3. Utworzenie zamówienia jest originem. ERP, mail i faktura strzelają tam.

„Dowolna liczba jednoczesnych użytkowników” jest prawdą dla HTML. Jest fałszem dla kasy, dla stanu, dla bazy. Wymiaruj PHP na szczyt kasy, który naprawdę macie (drop, newsletter, Black Friday, wyprzedaż sezonowa). CDN nie bierze karty i nie bierze Blika.

Dwa ostatnie komplety tego samego rozmiaru 42 to klasyczny polski ticket na dropie odzieżowym. Statyczny HTML mówi „jest”. Wyspa po hydracji mówi „brak”. Kasa Woo odmawia. Klient widzi trzy prawdy w dziewięćdziesięciu sekund. Albo webhook stanu unieważnia kartę zanim drop się rozleje, albo buy box jest żywy, albo świadomie sprzedajesz nad stan i uzgadniasz go na kasie. Wybierz jedną i zapisz w runbooku. Nie zostawiaj tego jako „CDN wszystko uniesie”.

Cache HTML przed klasycznym motywem nadal jest pierwszą dźwignią. Jeśli TTFB już jest niski, a LCP to zdjęcie bohatera, idź do tekstu o wydajności. Headless nie odczaruje PNG na trzy megabajty.

Stany w BaseLinkerze albo w Subiekcie są źródłem, jeśli tak ustawiliście. Woo wtedy jest lustrem. Webhook, który czyści kartę Astro, musi słuchać tego samego zdarzenia, które zmienia Woo, nie tylko ręcznego zapisu w wp-admin. W przeciwnym razie magazyn w ERP zejdzie do zera, a karta na CDN będzie sprzedawać do jutra.

#Kiedy nie headless

• Katalog kilkudziesięciu SKU, brak problemu z ruchem, poprawki w customizerze co tydzień
• Witryna jest listą wtyczek (page builder, kasa jednostronicowa, czat wklejony w motyw, mapka Paczkomatu na karcie produktu)
• Nikt w zespole nie weźmie repozytorium Astro po starcie
• Brief to „PageSpeed 100”, a karta produktu już ma cache HTML i AVIF

Wtedy: dieta wtyczek, cache HTML, potok obrazów, slot zgody. Taniej, odwracalnie. Headless to rozdział systemów. Macie dwa deploje, dwa podglądy, dwa tryby awarii. Opłaca się, gdy motyw jest wąskim gardłem, a katalog jest głównie czytany.

Subskrypcje i członkostwa: uprawnienie żyje w Woo. Strona Astro może pokazać „masz dostęp”, jeśli umie zapytać. Jeśli wtyczka członkostwa maluje treść, owijając the_content w PHP, tej treści nie ma w SSG. Albo ją wystaw, albo zostaw te URL-e na WordPressie.

Sklep, którego przewagą jest konfigurator (meble na wymiar, soczewki, grawer z podglądem) i którego konfigurator nie ma API, nie jest kandydatem. Najpierw API, potem katalog statyczny. Odwrotna kolejność kończy się iframe’em starego motywu w środku Astro. To nie jest rozdział. To ramka.

Jeśli redakcja codziennie składa landingi w Elementorze pod kampanię Meta Ads, headless zabiera im ten rytm. Albo mapujesz bloki na komponenty i dajesz podgląd, albo zostawiasz te landingi na PHP i rozdzielasz tylko katalog. Hybryda URL-i jest legalna. Hybryda „czasem ten motyw, czasem tamten, na tym samym SKU” nie.

#Kolejność migracji

1. Inwentaryzacja. Lista wtyczek podzielona na zostaje / umiera / nie wiadomo. Nie wiadomo staje się spike’em, nie niespodzianką w dniu startu. Osobna kolumna: InPost, P24/PayU/Blik, faktury, ERP.
2. API na żywym sklepie. Store API na współczesnym WooCommerce już jest. GraphQL, jeśli build katalogu tego chce. Klienci nic nie widzą.
3. Katalog Astro na stagingu, prawdziwe dane produktów, jeszcze bez kasy. Porównaj permalinki. Tu wyłażą wojny o ukośnik na końcu i bazę kategorii, nie w tygodniu ósmym.
4. Wyspa koszyka plus ciasteczko przeciw originowi stagingu. Dodaj do koszyka, kupon, opróżnij koszyk. Dopiero potem podłącz kasę.
5. Kasa nadal na Woo. Pomiń cache. Bramki na prawdziwym sandboxie P24 i PayU, nie tylko Stripe. Maile zamówienia. Ścieżka zwrotu. Wydruk etykiety InPost z zamówienia testowego.
6. SEO. Mapa 301, kanoniczne, JSON-LD produktu z tych samych pól co strona, sitemap URL-i Astro. Inspekcja URL-a produktu przed przełączeniem. Nie wymyślaj lastmod na dziesięciu tysiącach SKU.
7. Przełącz DNS katalogu. Zostaw wp-admin i kasę na originie. Tydzień patrz na webhooki stanu.

Blue-green katalogu jest łatwy (to pliki). Blue-green kasy jest taki sam jak dziś: już jedną macie. Nie wymyślaj drugiej.

Tydzień przełączenia to głównie DNS i 301, nie React. Zostaw krótkie okno, w którym stary motyw nadal odpowiada na nagłówek bypass, żeby porównać SKU. W chwili, gdy obie witryny dodają do koszyka przeciw temu samemu Store API, podwójnie dodasz ze starych kart. Opróżnij stary motyw: 301, potem 410 na assetach motywu, potem kasacja. Dual-run „na wszelki wypadek” to sposób, w jaki wraca customizer.

Na polskich sklepach w tym tygodniu sprawdzamy jeszcze trzy rzeczy, których tutorial SSG nie ma na liście: powrót z Blika na zamówienie-przyjęte, etykieta InPost z meta punktu, faktura z NIP w wFirma albo Fakturowni. Jeśli te trzy przejdą, kasa jest sklepem. Jeśli nie, DNS katalogu może poczekać.

#Audyt i lektura

LCP z pola, warstwy cache i waga payloadu Store API: przewodnik wydajności. Rozdział systemów: ta strona. Filar programisty WooCommerce to oferta na katalog. Programista Astro to front. Integracja ERP to to, co nie może paść, gdy umiera motyw. Architektura headless to ten sam rozdział bez koszyka.

Poufną realizację (Cloudflare, Store API, kasa zostawiona na Woo) opisuje studium przypadku headless WooCommerce. Liczb, których nie ma w tym zapisie, nie mamy.

Audyt przed decyzją mieści się na jednej tablicy: lista wtyczek, czy kasa może zostać na Woo, czy Geowidget InPost jest na karcie produktu czy na kasie, czy Blik jest metodą P24 czy osobnym eksperymentem, czy faktura słucha haka zamówienia. Z tą tablicą da się wycenić rozdział. Bez niej wyceniasz zrzut PageSpeed.

#Podsumowanie

WooCommerce jako sklep. Astro 7 jako katalog. Koszyk jako wyspa na Store API. Kasa na PHP. Wtyczki, które malowały motyw, zostają odbudowane albo zdjęte. Wtyczki, które prowadziły biznes, zostają. GraphQL buduje strony. GraphQL nie trzyma koszyka. Paczkomat, Blik i faktura rodzą się na originie.

Pisz z listą wtyczek i z odpowiedzią, czy kasa może zostać na WooCommerce. Jeśli odpowiedź brzmi „musi wyglądać identycznie jak kasa jednostronicowa z motywu, plus mapa Paczkomatów w tym samym kroku co karta”, kupujesz przebudowę, nie rozdział. Powierzchnia programisty WooCommerce jest miejscem, od którego ten zakres się zaczyna. Front katalogu domyka programista Astro.