Headless WooCommerce med Astro

Headless WooCommerce er ikke en ny butikk. wp-admin, lager, ordrer og betalingsløsninger blir. HTML-en kunden laster, kommer ikke lenger fra et PHP-tema. Astro 7 skriver katalogen. Kassen, hvis butikken skal ta Vipps og Bring neste måned, blir på WooCommerce.

En klassisk WooCommerce-forespørsel kjører PHP, object cache, pluginlisten og temaet, for en produktside som ikke har endret seg siden tirsdag. HTML-cache foran originen tar mye av det. Headless er neste kutt: katalogen blir et statisk tre, handlekurven en liten øy, pengene treffer fortsatt originen du allerede har i PCI-omfanget.

Denne teksten er splittelsen. Cachelag, TTFB og felt-LCP ligger i Headless WooCommerce med Astro, ytelsesguide. De kommersielle flatene er WooCommerce-utvikler og Astro-utvikler. Samme systemsplit uten handlekurv står i arkitekturguiden for headless WordPress. WPPoland bygger den splittelsen. Vi selger ikke tema og ikke et NSM-stempel.

Portent målte konvertering som falt om lag 4,42 prosent per ekstra sekund lastetid. Det er en helning, ikke et løfte om at Astro trykker omsetning. Vi går headless når temaet og pluginlisten er taket, ikke når briefen er et laboratorieskjermbilde.

#Hva som faktisk blir i WooCommerce

Backoffice flytter ikke. Produkter, varianter, lager, kuponger, ordrer, refusjoner, rapporter. Vipps, Klarna, Stripe, PayPal, Nets Easy der det fortsatt kjører. Tabellsatser for frakt. Merverdiavgift. ERP-koblinger som skriver til ordrer. Tripletex, Fiken, PowerOffice, visma.net: fakturaen fødes når ordren endrer status på originen. Det er PHP, og det skal bli PHP.

Det som går, er butikkfront-temaet: header.php, produktmalen, mini-cart-widgeten, Elementor på forsiden, zoom-pluginet, karusellen «fullfør looken» som laster et ikonsett for å vise tre SKU-er.

Redaktørene beholder samme wp-admin. Hvis de ikke gjør det, har du ikke gått headless. Du har bygget et andre PIM, og i tredje måned hater du det.

I en norsk butikk sitter det felt der som ingen Astro-build skal finne opp: organisasjonsnummer på bedriftskjøp, hentested-ID fra Bring, Vipps-transaksjonsreferanse, MVA-kode, GTIN, fraktklasse for Servicepakke mot Hjemlevering. Pluginene skriver det inn i produkt- og ordreobjekter. Katalogen kan trykke en merchandising-pris. Den bindende linjen oppstår i kassen.

xmlrpc og den offentlige REST-brukerruten trenger samme herding som enhver WordPress-origin. Headless gjemmer ikke wp-admin. Sett Access foran. Katalog-CDN-en er ikke en brannmur. Hvis du vil skille administrasjon fra det kundene treffer, er det en topologibeslutning (eget vertsnavn, Zero Trust, ingen cookie mot katalogdomenet). Det er i tråd med NSMs grunnprinsipper om å beskytte virksomhetens nettverk. WPPoland er ikke NSM-revisor. Vi tegner skillet. Revisjonen gjør den som allerede har det mandatet.

Ordremail, PDF-faktura, eksport til regnskap, kreditnota: alt origin. En Astro-vert som bygger «ordre mottatt» på nytt, har i uke to en avvikende MVA-linje. Da skriver økonomi saker, ikke redaksjonen.

Medlemskap og abonnement lever i WooCommerce. Astro kan vise «du har tilgang» bare hvis den kan spørre. Maler medlemskapspluginet innhold ved å pakke the_content i PHP, ligger de URL-ene ikke i SSG-en din. Enten eksponer, eller la URL-ene bli på WordPress.

#Pluginet som dør med temaet

Dette er inventaret ingen vil gjøre, og det er hele risikoen.

Dør med temaet (bygg som øy, eller ta bort):

• Variantswatches som bytter nedtrekksmeny med fargeprikker
• Hurtigvisning og ajax-legg-i-kurv i løkken
• Produktbilde-zoom og 360-visning
• Oppsalgs-popup, falske knapphetsfelt, «andre kjøpte også» som skriver i woocommerce_after_shop_loop
• Sidebyggere på forside og kampanje-SKU-er
• Ett-sides-kasse-plugin som tar over checkout-malene
• Tema-footer med tillitsmerke som bare limer HTML og ikke kjenner ordrenummer
• Samtykkebanner som bare sitter i temahodet og mangler på PHP-kassen
• «Leveres i morgen med Posten» under kjøpsknappen, skrevet som tematekst uten spor til fraktklassen

Blir (API eller webhook, ikke tema):

• Betalingsløsninger
• Frakt og henting (Bring, Posten, PostNord, Helthjem, Porterbuddy, hentested, tabellsatser)
• Merverdiavgift (inkludert OSS der det gjelder)
• Abonnement og medlemskap, så lenge status spørres og ikke males av pluginets CSS
• Klaviyo eller Mailchimp via ordrehooks
• ERP (se WooCommerce ERP-integrasjon)
• Vipps- og Klarna-data i ordren, Bring-etikett i admin, faktura i Tripletex

Hvis butikkens konverteringsgrep lever i den første listen, er headless en redesign, ikke et fartsprosjekt. Pris det som redesign. Omfanget hos WooCommerce-utvikler sier det skillet rett ut. Vi har sett en butikk «gå headless» og så slå på det gamle temaet igjen for kassen, fordi ett-sides-pluginet var det egentlige produktet. Det er to butikkfronter. Ikke gjør det.

Nyttig test: slå av temaet på staging og last en produkt-URL som ?theme=noop eller med et blankt tema. Det som fortsatt er der (pris, lager, legg i kurv via Store API) beholder du. Det som forsvant (swatches, merker, leveringsestimator-HTML) er arbeid. Er den forsvunne listen grunnen til at kundene kjøper, budsjetter øyer. Er det pynt, ta det bort.

Kompositter, bundler og produkt-tillegg er gråsonen. Noen eksponerer REST, noen filtrerer bare woocommerce_add_to_cart. Hvis legg-i-kurv for en bunt gir 404 på Store API, er den SKU-en ikke katalogstatisk før noen skriver mappingen. Oppdag ikke det lanseringsmorgenen.

En sportsbutikk vi lastet slik på staging, mistet med temaet fargeprikkene, hentested-hintet under knappen og linjen «klar til henting i posten i morgen». Pris og kurv-endepunkt ble. Tre uker øyarbeid, fordi prikkene var selve kjøpsgrunnen på mobil. Leveringslinjen var tema-HTML uten kobling til Bring-tjenesten. Den bygde vi ikke om. Fraktklassen er et kassefelt.

Cookie-banner og CMP som bare er en snippet i header.php, dør også. Kassen på Woo må ha samme samtykke som katalogen på Astro. To bannere, to avvik, én klage. Sett CMP på begge flater mot samme avtale, eller hold banneret på originen og last det som en tynn øy. Ikke la staging se ut som den er ferdig fordi katalog-HTML er ren.

#Bring, Vipps og frakten som blir i PHP

Norske butikker bygger ikke kassen ved siden av i Astro fordi et Stripe-innlegg sa det. Vipps Checkout, Vipps Login, Klarna, Bring Fraktguiden, Postens hentesteder, Helthjem og ofte Porterbuddy haker i Woo-malene. Hybrid er standard. Det er ikke juridisk råd. Det er et inventar av hooks.

Vipps Checkout er ikke en knapp du kopierer inn i en øy. Pluginet (oftest Krokedils Vipps for WooCommerce, eller Vipps Checkout-varianten som sitter på kassemalen) oppretter Woo-ordren, sender sesjonen til Vipps, tar imot retur og webhook, og setter status. Returen lander på origin, ikke på en Astro-sti gateway-dokumentasjonen aldri har sett. Express fra produktkortet er et temagrep. På en statisk katalog kan du vise «kjøp med Vipps» som lenke til kassen med kurven allerede satt via Store API. Du kan ikke late som øya eier transaksjonen. Da får du betaling uten fraktlinje, eller fraktlinje uten betaling.

Vi så en klesbutikk i Bergen lime Vipps Express inn i en Astro-øy etter et innlegg om «headless checkout». Vipps trakk. Woo fikk en ordre uten bring_pickup_point. Etikettkjøringen i Mybring klokken 16 sto uten hentested. En uke senere pekte «Til kassen» igjen på Woo. Katalogen ble på Astro. Det var ikke et nederlag for headless. Det var pluginlisten som allerede hadde tegnet skillet.

Vipps Login er en annen flate. Det er OIDC: autorisasjonskode, tokenendepunkt, kortlevd ID-token, ofte med BankID i bunnen. Det er innlogging til Min side, ikke kassen. Du limer ikke Vipps-tokenet inn i wordpress_logged_in_* og kaller det ferdig. Hvis katalogen er Astro og konto er Woo, autentiserer Vipps Login personen mot det domenet som eier sesjonen. Offentlig katalog-HTML forblir cachebar. Konto-URL-ene kan bli PHP bak innlogging. Blanding av Login og Checkout i samme øy er hvordan team mister både kurv-cookie og identitet i samme sprint.

Klarna (faktura, delbetaling, direkte) kjører som Woo-gateway. Sesjonen Klarna kjenner, er Woo-ordren, ikke et fetch i en øy. 3-D Secure-retur, avslag, «betal ordre»-lenke i e-post: origin. På norske mobiler ligger Klarna ved siden av Vipps, ikke i stedet. En kasse uten den metoden butikken allerede har avtale på, er en annen butikk.

Bring og Posten er fraktkalkyle, hentestedskart og etikett, ikke et select med bynavn. Bring Fraktguiden (og slekten rundt Mybring Checkout, pickup-widget, Cargonizer, Logistra, Profrakt) skriver inn i kassemalen: postnummer, tjeneste (Klimanøytral Servicepakke, Hjemlevering, Pickup Parcel), kart over hentested, lagring av hentested-ID i ordre-meta, deretter etikett og spor. Hooken sitter ved fraktsteget, ikke ved produktkortet. På en Astro-katalog har det kartet ingen mal å hekte seg i. Bygger du et eget hentestedskart i øya, må du likevel skrive samme meta etikettpluginet venter på. Lageret klokken 16 trykker «skriv ut etiketter». Tom meta er ikke «liten teknisk gjeld». Det er pakker uten klistremerke.

Postnummeret eier fraktprisen. Mini-kurven kan gjette. Kassen regner. En fast fraktlinje i SSG-HTML er merchandising, ofte feil for Pickup mot Hjemlevering, og alltid feil når postnummeret er 5003 i stedet for 0150. Ikke kall Bring synkront fra nettleseren. Ikke la GraphQL-skjemaet late som frakt er et felt på produktet. Kurv og kasse er skrivesti. De har egne feilbaner (nedetid hos Bring, ukjent postnummer, VOEC-beløp som endrer totalsum) og skal ikke dele cache-nøkkel med produktsiden.

Helthjem, Porterbuddy, PostNord MyPack: samme mønster. Satsen kan bli, fordi den er PHP på originen. Valg av punkt er naboen til temaet. Headless katalog tar ikke satsene. Den tar widgeten hvis du kopter kassen.

VOEC treffer hvis varene sendes til Norge fra utlandet. Vat On E-Commerce er Skatteetatens ordning for utenlandske tilbydere under beløpsgrensen for forenklet registrering. Dette er ikke juridisk råd og ikke en sjekkliste for deklarasjon. Arkitekturen må vite om ordren er VOEC-pliktig før kassen viser totalsum, ikke etter at Vipps har trukket. Det er data i ordren (selgers registrering, varens opprinnelse, mottakerland NO), ikke et CSS-problem i headless-kurven. En frontend som hardkoder norsk merverdiavgift på alt som ser norsk ut, lyver i kassen. Hold VOEC-regelen på originen eller i et eget prisingslag. La frontend bare vise det laget returnerer.

NSM igjen, kort: kassen og wp-admin er skrivesti mot kortdata-naboer og personopplysninger. Katalogen er lesesti. Å legge admin og MySQL i privat nett, med offentlig origin som serverer filer, reduserer angrepsflaten mot kjernen. Det er nettverksseparasjon, ikke et sertifikat vi utsteder. Vi hevder ikke at en slik topologi «er NSM-godkjent». Vi hevder at den er lettere å forsvare enn én PHP-tolk bak samme vertsnavn som forsiden.

Standard vi setter: statisk katalog, kurvøy mot Store API, lenke «Til kassen» mot WooCommerce /kasse/ eller /checkout/, HTML-cache i bypass på den stien, kurv-cookie allerede satt. Hver gateway, hver fraktwidget, hver «ordre mottatt»-mail, hver woocommerce_thankyou (ERP, Tripletex, Bring-etikett) fyrer som i går. PCI-omfanget blir der det var.

En butikk med Vipps, Klarna og Bring Fraktguiden, som vi tok i, ville «kassen også headless». Etter to sprinter lå hentested, Vipps-retur og takkesiden på Woo igjen. Katalogen ble på Astro. Det var ikke en retrett. Det var splittelsen pluginlisten allerede hadde gitt.

#Astro 7 for katalogen, ikke for butikken

Astro 7 leverer som standard HTML og CSS. JavaScript bare der du merker en øy.

Katalog som skal være statisk:

• Forside, kategori, produkt, innhold, vilkårssider
• getStaticPaths fra produktlisten i bygget
• AVIF fra mediebiblioteket, sizes som matcher rutenettet, ikke 100vw på et 320 px-miniatyrbilde

Øyer:

• Legg i kurv, antall, variantvelger
• Mini-kurv
• Søk som treffer en indeks, ikke PHP ?s=
• Kanskje en Vipps-lenke eller et Stripe-felt på et eget betalingssteg, hvis omdirigering virkelig ikke går. Det er unntaket. Det er ikke Bring-kartet.

client:visible på legg i kurv. client:idle på søk. En produktside som importerer en hel ikonpakke inn i øya, har allerede mistet poenget. Samme regel som enhver annen Astro 7-front: øya er en komponent, ikke et alibi for å hydrere siden.

Rebuilds: en produkt-updated-webhook bygger den stien på nytt, eller et lite sett stier (produkt, kategoriene dens, forside hvis den merchandiser). Fullkatalog-rebuild hvert tiende minutt er øyeblikket folk oppdager at de har 40 000 SKU-er. Inkrementelt eller on-demand. Cloudflare eller verten stakken allerede bruker. Ikke «Vercel fordi innlegget sa det» hvis resten allerede ligger på Cloudflare.

Søk: PHP ?s= er et PHP-treff. På en statisk katalog er søk enten en klientindeks (små kataloger), en ekstern indeks (Algolia, Meilisearch, Typesense) fylt fra samme nyttelast som SSG, eller en Store API- eller REST-spørring gjennom en øy. Ikke send søkeboksen til WordPress hvis resten av butikken aldri gjør det. Fasetter som trenger live lager hører hjemme ved kjøpsboksen, ikke i SSG-HTML.

Relaterte produkter: hvis de er merchandiset i wp-admin, er de data. Spør dem i bygget. Hvis de var woocommerce_output_related_products fra temaet, var de aldri data, de var en mal. Bygg som statisk stripe fra samme kategori, eller ta bort.

Prisen på produktkortet er merchandising. «Inkl. mva» i SSG-HTML er en påstand om visning, ikke om kasselinjen. OSS og VOEC regnes på originen. Priser per land bare som SSG hvis du også SSG-er stier per land og kan invalidere dem. De fleste butikker viser en katalogpris og lar Woo legge merverdiavgift i kassen. Det er standard. En gammel britisk brutto foran en norsk gjest er e-posten fra økonomi.

Bilder blir i WordPress-mediebiblioteket. Astro leser URL-er, eller et byggesteg kopierer AVIF. Ikke finn opp et andre DAM med mindre du allerede har ett. LCP-bildet er fortsatt helten på produktsiden. Headless velger ikke formatet for deg. Feltmåling av det ligger i ytelsesguiden, ikke her.

Forhåndsvisning: redaktører må se et utkastprodukt på Astro-verten. En webhook eller et preview-token som henter ett produkt fra originen, holder. Betyr forhåndsvisning «logg inn i wp-admin og bruk tilpasseren», er splittelsen ikke ferdig, og de krever det gamle temaet tilbake.

JSON-LD for Product kommer fra samme nyttelast som siden. Ikke GraphQL én gang for HTML og REST én gang for schema. Google ser driften. Canonical peker på Astro-URL-en. canonicalUrl i et gammelt temahode som fortsatt svarer, er et split-signal.

Kampanjesider som marked lager i en sidebygger hver uke, er feil flate for Astro. Katalogen kan likevel være Astro. Kampanje-URL-ene blir PHP. Headless betyr ikke å forby sidebyggeren. Det betyr å ta den av produkt-URL-en.

#Store API mot GraphQL for kurv og katalog

To rør. Å blande dem er det vanlige selvpåførte såret.

Katalogbygg: WPGraphQL pluss WooGraphQL, eller REST-produktsendepunktet, ved byggetid. Én spørring per produktside. Navn, priser, lagerstatus, bilder, kategorier, attributter. Ikke handlekurven.

Handlekurv og sesjon: WooCommerce Store API (/wp-json/wc/store/v1/cart). Den eier kurv-informasjonskapselen, noncer, kuponger, fraktkalkyle. Den kapselen må ligge på originen som senere tar kassen. Er Astro-nettstedet shop.example.no og Woo cms.example.no, har du et cookie-problem før du har et React-problem. Samme nettsted, eller en dokumentert proxy.

Vi ser team legge-i-kurv gjennom WooGraphQL-mutasjoner fordi katalogen allerede snakker GraphQL. Så viser WooCommerce-kassen tom kurv, og Vipps åpner seg på en ordre uten linjer. Sesjonen flyttet aldri. Store API for kurven. GraphQL for SSG-nyttelasten. Skriv det på veggen.

Same-site-informasjonskapsler: ligger Astro på toppen og WordPress på wp., sett kurv-kapselens domene eksplisitt og proxy /wp-json/wc/store/ til originen. CORS på Store API er ikke erstatning for kapselen. SameSite=Lax på en kryss-nettsted-kasseomdirigering ser ut som «Vipps går på staging» (samme vert) og «tom kurv i produksjon» (to verter). Ett vertsnavn for kjøperen, internt vertsnavn for wp-admin.

Nonce-utløp på en statisk side er en ekte feil. Kurvøya må hente fersk nonce fra Store API ved hydrering, ikke bake en fra morges bygg inn i SSG-HTML. Bakt nonce gir 403 etter noen timer, og knappen «gjør ingenting». På en norsk Black Week-mandag er det den saken supporten får først, foran lager.

Lager ved bygg er et øyeblikksbilde. En utsolgt størrelse som fortsatt står i HTML, er en refusjon. Webhook woocommerce_product_set_stock (eller variant-ekvivalenten) må invalidere den stien. Hvis du ikke kan det, SSG-er du ikke kjøpsboksen. Render kjøpsboksen fra Store API ved forespørsel, fortsatt som liten øy. Katalog-HTML kan bli statisk.

Kuponger hører hjemme i samme sesjon som kurven. En GraphQL-kupong som maler prisen på produktsiden uten å sette kurv-nonce, ser annerledes ut i kassen. Kunden forventet en annen rabatt. Store API bruker koden, WooCommerce blir kilde til sannhet.

Frakt i mini-kurven er antakelser til postnummeret er der. Tabellsats og Bring Servicepakke henger på postnummer og kurvverdi. Øya får gjette. Kassen regner. En fast fraktlinje i SSG-HTML er merchandising, ofte feil for hentested og Hjemlevering.

#Behold kassen på WooCommerce, ikke i en Astro-øy

Vipps, Bring og Klarna er begrunnelsen, og den står i avsnittet over. Her er bare driftsvalget.

Omdiriger til /kasse/ eller /checkout/. Katalog og kurvøy lever på Astro. «Til kassen» er en lenke til WooCommerce-kassemalen, forbi HTML-cachen, med Store API-kapselen allerede satt. Hvert gateway-plugin, hvert fraktplugin, hver «ordre mottatt»-mail blir. PCI-omfanget blir der det var.

Egen kasse i Astro betyr at du skriver om adressefelt, postnummer, hentested, merverdiavgift, Vipps-retur, Klarna-sesjon, 3-D Secure, mislykket betaling, «betal ordre»-lenker og etikett-meta. Vi har gjort det når merkevaren trengte et steg ingen PHP-mal tålte. Det er et produkt. Det er ikke standard.

Ordre mottatt og Min konto kan bli på WooCommerce. Headless betyr ikke at hver URL er Astro. Det betyr at URL-ene reklametrafikken treffer, er filer. /min-konto/ bak Access eller bak innlogging er greit som PHP.

Webhook-URL-er (/?wc-api=, Vipps, Klarna, Stripe) må treffe originen, ikke Astro-CDN-en. Hopp over de stiene i cachen. Samme skip-listedisiplin som en WAF: hvert hopp har et navn.

Merverdiavgift og OSS (og VOEC der det gjelder) regnes på originen. En statisk kronepris på produktkortet er merchandising. Kasselinjen er den bindende. Ikke «fullfør headless» ved å skrive om den eneste malen som allerede tar Vipps.

#Lager, cache

Statiske filer på et CDN skalerer. Lager gjør ikke det. To kunder som kjøper siste SKU, er et butikkproblem, ikke et laboratorieskjermbilde.

Mønster som holder:

1. Katalog-HTML er statisk, inkludert pris, til en webhook sier noe annet.
2. Buy box spør Store API om stock_status når øya hydrerer, eller du godtar et kort gammelt vindu og retter i kassen (WooCommerce nekter oversalg hvis du har satt det slik).
3. Ordreopprettelse er origin. ERP, mail, Tripletex og Bring-etikett fyrer der.

«Ubegrenset antall samtidige brukere» gjelder HTML. Det gjelder ikke kasse, lager, database. Dimensjoner PHP til kassetoppen du faktisk har (slipp, nyhetsbrev, Black Week, januarsalg). CDN-en tar ikke kortet og tar ikke Vipps.

HTML-cache foran et klassisk tema er fortsatt første spak. Har produktsiden allerede fil pluss AVIF, og briefen likevel lyder «headless fordi fort», les ytelsesguiden først. Headless gjør ikke et 3 MB PNG til et lite hero.

Invalidering er del av arkitekturen, ikke en cron. woocommerce_update_product treffer produktsti, kategoristier, ofte forside. woocommerce_product_set_stock treffer kjøpsboksen. Full tømming etter hvert lagerklokk-tak er hvordan butikker brenner CDN-budsjettet. Tagger eller presise stier.

Kommer lageret fra et ERP (se WooCommerce ERP-integrasjon), er WooCommerce fortsatt kilde til sannhet for butikken, ikke Astro. Webhooken som tømmer kanten, henger på Woo-hendelsen, ikke på ERP-filen. Ellers viser Astro 12, Woo 0, ERP 7, og support forklarer tre tall.

Variantlager er den vanlige blindsone. Parent er «på lager», størrelse M ikke. SSG som bare maler parent, selger M. Øya må spørre varianten, eller kassen rydder etterpå og kunden er borte.

To siste sett i størrelse 42 på et kles-slipp er den klassiske saken. Statisk HTML sier «finnes». Øya etter hydrering sier «tomt». Woo-kassen nekter. Kunden ser tre sannheter på nitti sekunder. Enten invaliderer lagerwebhooken kortet før slippet sprer seg, eller kjøpsboksen er levende, eller du selger over lager med åpne øyne og retter i kassen. Velg én og skriv den i runbooken. Ikke la det stå som «CDN tåler alt».

#Når du ikke skal gå headless

• Katalog under noen titalls SKU-er, ingen trafikkproblem, tilpasserendringer hver uke
• Butikkfronten er pluginlisten (byggere, ett-sides-kasse, chat bakt inn i temaet)
• Ingen på laget eier Astro-repoet etter lansering
• Briefen er et laboratorieskjermbilde, og produktsiden har allerede HTML-cache og AVIF
• Kassen er produktet: Vipps pluss Klarna pluss Bring-hentested pluss ett-sides, og ingen får røre den
• Redaksjonen forventer å bygge forsider i Elementor uten å vente på et frontend-deploy

Da: plugindiett, HTML-cache, bildepipeline, samtykkeslott. Billigere, reversibelt. Headless er en systemsplit. Du har nå to deploy, to forhåndsvisninger, to feilbilder. Det lønner seg når temaet er flaskehalsen og katalogen mest leses.

Abonnement og medlemskap: kravet lever i Woo. Astro-siden kan vise «du har tilgang» hvis den kan spørre. Maler medlemskapspluginet innhold ved å pakke the_content i PHP, ligger det innholdet ikke i SSG-en. Eksponer eller la de URL-ene bli på WordPress.

B2B med nettopriser per kundegruppe er et andre varselskilt. Katalogprisen i SSG er offentlig. Den ekte nettolinjen sitter i sesjonen. Enten kjøpsboksen etter innlogging fra Store API, eller la de SKU-ene være. En lekket netto-HTML-build er mer pinlig enn et tregt tema. Organisasjonsnummer hører hjemme i kassen, ikke i produktkortet.

Hvis marked hver uke trenger en landing i en sidebygger, er Astro feil flate for det. Katalogen kan likevel være Astro. Kampanje-URL-ene blir PHP.

En gavebutikk med førti SKU-er, Customizer-kveld hver torsdag og Bring-widget som hele kassen, skal ikke splitte systemer. Sett HTML-cache, kutt zoom-pluginet, lever AVIF. Ta opp headless når produkt-URL-en er taket og kassen allerede virker.

#Migreringsrekkefølge

1. Inventar. Pluginliste i blir / dør / ukjent. Ukjent blir en spike, ikke en overraskelse ved lansering. Merk Vipps Checkout, Vipps Login, Klarna, Bring Fraktguiden, Helthjem, Tripletex, Cargonizer hver for seg.
2. API på live-butikken. Store API er der allerede på moderne WooCommerce. GraphQL hvis katalogbygget vil ha det. Kundene ser ingenting.
3. Astro-katalog på staging, ekte produktdata, ennå ingen kasse. Sammenlign permalinks. Trailing slash og category-base-kamper finner du her, ikke i uke åtte.
4. Kurvøy pluss cookie mot staging-origin. Legg i kurv, kupong, tom kurv. Deretter, og først da, lenke kassen.
5. Kasse fortsatt på Woo. Forbi cachen. Gateway i ekte sandkasse. Ordremail. Refusjonssti. Vipps-testkjøp. Klarna Playground. Bring-test API. Hentested-felt. Takkeside med etikett-hook.
6. SEO. 301-kart, canonical, produkt-JSON-LD fra samme felt som siden, sitemap over Astro-URL-er. Inspiser en produkt-URL før overgangen. Ikke finn opp lastmod på 10 000 SKU-er.
7. Katalog-DNS. La wp-admin og kasse bli på originen. Se på lagerwebhooker en uke.

Blå-grønn av katalogen er enkelt (det er filer). Blå-grønn av kassen er det samme som i dag: du har allerede én. Ikke finn opp en andre.

Cutover-uken er mest DNS og 301, ikke React. Hold et kort vindu der det gamle temaet fortsatt svarer via header-bypass, slik at du kan sammenligne en SKU. I det øyeblikket begge butikkfronter gjør legg-i-kurv mot samme Store API, dobbeltlegger gamle faner. Tøm det gamle temaet: 301, så 410 på tema-ressurser, så slett. Dual-kjøring «for sikkerhets skyld» er veien tilpasseren kommer tilbake på.

Glem ikke vilkår-URL-er i 301-kartet. /vilkar/, /personvern/, /angrerett/ er ofte lenket fra mail og fra Vipps-kvittering. En 404 der etter overgangen er høyere enn en 404 på en gammel kategori.

Gateway i sandkasse betyr: Vipps testnøkler, Klarna Playground, Bring test. Et live Vipps-trekk på staging «bare for å se om det går» blander PCI-omfang og logger. Ikke gjør det.

Forhåndsvisning av utkastprodukt på Astro-verten må virke før DNS-kutt. Ellers logger redaktøren inn i det gamle temaet «bare denne uken», og uken blir kvartalet.

#Revisjon og videre lesing

Felt-LCP, cachelag og vekt på Store API-nyttelast: ytelsesguiden. Systemsplittelsen: denne siden. Flaten WooCommerce-utvikler er det kommersielle katalogarbeidet. Astro-utvikler er fronten. ERP-integrasjon er det som ikke må knekke når temaet dør. Headless-arkitektur er samme split uten handlekurv.

Revisjonsspørsmål vi stiller før et tilbud:

• Hvilke plugin skriver HTML i løkke, produkt, kurv, kasse, takk?
• Hvilke av dem har REST eller Store API, hvilke bare mal-hooks?
• Får kassen bli på WooCommerce, inkludert Vipps, Klarna, Bring/Posten, Helthjem, hentested?
• Hvem eier Astro-repoet etter lansering, og hvem trykker produkt-webhooken?
• Hvor ligger lageret om natten, når ERP skriver?
• Er Vipps Login i bruk på Min side, og på hvilket domene sitter sesjonen?

Uten den listen er «vi gjør headless» en temalansering med to verter.

Vi måler ikke denne butikken med et laboratorieskjermbilde i briefen. Vi måler om hookene fyrer etter overgangen, om hentested-ID ligger i ordren, og om lagerwebhooken treffer produktstien. Tall som ikke står i denne teksten, er ikke tall vi har.

#Konklusjon

WooCommerce blir butikken. Astro 7 blir katalogen. Handlekurv som øy på Store API. Kasse på PHP, i Norge inkludert Vipps, Klarna og Bring-widgeter. Plugin som malte temaet, bygges om eller tas bort. Plugin som drev forretningen, blir. GraphQL bygger sider. GraphQL holder ikke kurven.

Skriv med pluginlisten og spørsmålet om kassen får bli på WooCommerce. Lyder svaret «den må se identisk ut med temaets ett-sides-kasse», kjøper du en redesign. Flaten WooCommerce-utvikler er der det omfanget starter. Astro-utvikler er der katalogen bygges. ERP-integrasjon er der lageret ikke får lyve.

Måleverdier, cachelag og vekten av Store API-nyttelasten hører hjemme i ytelsesguiden. Denne teksten slutter der originen skriver ordren.

Forhåndsvisning: redaktører må se et utkast på Astro-verten. En webhook eller et preview-token som henter ett produkt fra originen, holder. Betyr forhåndsvisning tilpasseren i wp-admin, er splittelsen ikke ferdig.

Bilder blir i WordPress-mediebiblioteket. Astro leser URL-er. LCP-bildet er fortsatt helten på produktsiden. Headless velger ikke formatet. Et WebP fra en sidebygger er fortsatt et dårlig LCP, også på et CDN.