Orders migreren (WooCommerce): verschil tussen versies

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
 
(12 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 1: Regel 1:
Een fundamenteel probleem bij migratie van orders lijkt te zijn, dat het ID op database-niveau, tevens het order-id is (of iets wat er op lijkt). Zie [[Multistore (WordPress)]] voor details.
+
== Use case ==
  
== Importeren ==
+
Het betreft beheer en onderhoud van een groot aantal webwinkels. Deze webwinkels zijn klonen (al of niet vertaald) van één bepaalde bronsite. Op het moment dat de bronsite flink is bijgewerkt, zou ik deze site opnieuw willen klonen naar een doelsite, en de orders van de eerdere versie van de doelsite, hierin importeren.
  
Importeren van orders kan oa. via WooCommerce's eigen plugin. Die kan zelfs Excel-bestanden lezen
+
== Uitdagingen ==
 +
 
 +
Het gaat niet alleen om het importeren van de orders en orderregels, maar ook om een hoop bijbehorende gegevens:
 +
 
 +
* Klantgegevens. Dit zijn ''accounts'' - Met als bijzonder geval, dat klanten zich niet hoeven te registreren als ze een order plaatsen
 +
* DHL-gegevens
 +
* Order notes
 +
* Betaalgegevens
 +
* Order-ID's: Zie hieronder
 +
* Maatwerkvelden.
 +
 
 +
=== Order-id's ===
 +
 
 +
In WordPress zijn orders een specifiek geval van ''posts''. De ''primaire sleutel'' (''primary key - pk'') van een post is het ''post-id''- of ''ID''-veld. Dit is een ''[[Auto-increment-velden (MySQL) | auto-increment veld]]''. het ''post-id''-veld is tevens het 'reguliere order-id', dus wat de klant te zien krijgt (tot op zekere hoogte - zie verderop).
 +
 
 +
Dit betekent, dat je weinig invloed hebt op het post-id/order-id van een order na migratie: In de use case waar dit artikel over gaat, betreft het migratie van orders naar een vergelijkbare site als de bronsite, maar dan zonder orders (dus ''import'' en niet ''merge''). Er is dus een kans dat het oorspronkelijke post-id nog beschikbaar is. Helaas zal het oorspronkelijke post-id doorgaans niet beschikbaar zijn: Andere soorten posts kunnen namelijk in de tussentijd zijn aangemaakt (bv. pagina's), of orders zijn tussentijds weer verwijderd, etc.
 +
 
 +
Een aanlokkelijke truuk om dit te fixen zou kunnen zijn, door op de bronsite orders bij een heel hoog nummer te laten beginnen, bv. 10.000. Helaas helpt dat niet: Als er tussendoor een ander object van het type ''post'' wordt aangemaakt, krijgt deze ook zo'n hoog nummer.
 +
 
 +
Kortom: ''order-id's'' kunnen niet behouden worden.
 +
 
 +
Maar dit hoeft geen probleem te zijn: Naast het order-id-veld, heb je nog het ''formatted-order-id''-veld, bv. ''NL_EN-65356''. Als dit veld maar blijft behouden, maakt het niet zoveel uit wat er gebeurt met het order-id. Uiteraard is het dan wel belangrijk dat zo'n formatted-order-id niet per ongeluk wordt dubbelgebruikt als na migratie een nieuwe order wordt aangemaakt, maar die kans is klein (er zullen doorgaans meer objecten zijn na migratie, dan ervoor, bv. omdat er tijdens migratie toch accounts worden aangemaakt voor klanten die daar niet om vroegen).
 +
 
 +
== Inventarisatie ==
 +
 
 +
=== WooCommerce-plugins ===
 +
 
 +
WooCommerce heeft twee plugins voor im- & export:
 +
 
 +
* [[WooCommerce CSV Import Suite]]
 +
* [[WooCommerce CSV Export-plugin]].
 +
 
 +
De eerste indruk is gemengd. Zie [[WooCommerce CSV Import Suite]] voor details
 +
 
 +
=== Overige plugins ===
 +
 
 +
Er bestaan meer plugins voor im- & export. Die heb ik tot op heden niet getest.
 +
om complete database-tabellen over te nemen
 +
 
 +
=== Complete database-tabellen overnemen? ===
 +
 
 +
Het klinkt radicaal om complete database-tabellen over te nemen, maar misschien klopt dat precies in deze use-case, waarbij orders & meta-data van een bestaande site naar een lege site worden overgefietst. Alsof je een tree-tier-applicatie hebt, en 'gewoon' een deel van de onderste laag (''storage'') uitwisselt.
 +
 
 +
Probleem: Post-ID's kunnen niet behouden blijven. Voorbeeld: Op de bronsite worden pagina's toegevoegd (bv. ''buttonbar-pagina's'' als onderdeel van een wizard)
  
 
== Zie ook ==
 
== Zie ook ==
  
 +
* [[Auto-increment-velden (MySQL)]]
 
* [[Multistore (WordPress)]]
 
* [[Multistore (WordPress)]]
 +
* [[WooCommerce CSV Export-plugin]]
 +
* [[WooCommerce CSV Import Suite]]
  
 
== Bronnen ==
 
== Bronnen ==
  
 
* https://sgwebpartners.com/moving-orders-in-woocommerce/
 
* https://sgwebpartners.com/moving-orders-in-woocommerce/
 +
* https://woocommerce.com/products/ordercustomer-csv-export
 +
* https://woocommerce.com/products/customerorder-csv-import-suite

Huidige versie van 26 mei 2022 om 11:41

Use case

Het betreft beheer en onderhoud van een groot aantal webwinkels. Deze webwinkels zijn klonen (al of niet vertaald) van één bepaalde bronsite. Op het moment dat de bronsite flink is bijgewerkt, zou ik deze site opnieuw willen klonen naar een doelsite, en de orders van de eerdere versie van de doelsite, hierin importeren.

Uitdagingen

Het gaat niet alleen om het importeren van de orders en orderregels, maar ook om een hoop bijbehorende gegevens:

  • Klantgegevens. Dit zijn accounts - Met als bijzonder geval, dat klanten zich niet hoeven te registreren als ze een order plaatsen
  • DHL-gegevens
  • Order notes
  • Betaalgegevens
  • Order-ID's: Zie hieronder
  • Maatwerkvelden.

Order-id's

In WordPress zijn orders een specifiek geval van posts. De primaire sleutel (primary key - pk) van een post is het post-id- of ID-veld. Dit is een auto-increment veld. het post-id-veld is tevens het 'reguliere order-id', dus wat de klant te zien krijgt (tot op zekere hoogte - zie verderop).

Dit betekent, dat je weinig invloed hebt op het post-id/order-id van een order na migratie: In de use case waar dit artikel over gaat, betreft het migratie van orders naar een vergelijkbare site als de bronsite, maar dan zonder orders (dus import en niet merge). Er is dus een kans dat het oorspronkelijke post-id nog beschikbaar is. Helaas zal het oorspronkelijke post-id doorgaans niet beschikbaar zijn: Andere soorten posts kunnen namelijk in de tussentijd zijn aangemaakt (bv. pagina's), of orders zijn tussentijds weer verwijderd, etc.

Een aanlokkelijke truuk om dit te fixen zou kunnen zijn, door op de bronsite orders bij een heel hoog nummer te laten beginnen, bv. 10.000. Helaas helpt dat niet: Als er tussendoor een ander object van het type post wordt aangemaakt, krijgt deze ook zo'n hoog nummer.

Kortom: order-id's kunnen niet behouden worden.

Maar dit hoeft geen probleem te zijn: Naast het order-id-veld, heb je nog het formatted-order-id-veld, bv. NL_EN-65356. Als dit veld maar blijft behouden, maakt het niet zoveel uit wat er gebeurt met het order-id. Uiteraard is het dan wel belangrijk dat zo'n formatted-order-id niet per ongeluk wordt dubbelgebruikt als na migratie een nieuwe order wordt aangemaakt, maar die kans is klein (er zullen doorgaans meer objecten zijn na migratie, dan ervoor, bv. omdat er tijdens migratie toch accounts worden aangemaakt voor klanten die daar niet om vroegen).

Inventarisatie

WooCommerce-plugins

WooCommerce heeft twee plugins voor im- & export:

De eerste indruk is gemengd. Zie WooCommerce CSV Import Suite voor details

Overige plugins

Er bestaan meer plugins voor im- & export. Die heb ik tot op heden niet getest. om complete database-tabellen over te nemen

Complete database-tabellen overnemen?

Het klinkt radicaal om complete database-tabellen over te nemen, maar misschien klopt dat precies in deze use-case, waarbij orders & meta-data van een bestaande site naar een lege site worden overgefietst. Alsof je een tree-tier-applicatie hebt, en 'gewoon' een deel van de onderste laag (storage) uitwisselt.

Probleem: Post-ID's kunnen niet behouden blijven. Voorbeeld: Op de bronsite worden pagina's toegevoegd (bv. buttonbar-pagina's als onderdeel van een wizard)

Zie ook

Bronnen