Architectuur

Deze pagina legt de technische architectuur van WCPOS uit voor ontwikkelaars en gevorderde gebruikers.

Tweedelig systeem

WCPOS is ontworpen als een tweedelig systeem:

1. PHP-plug-in: Gehost op je server, dit is een relatief kleine plug-in die de WooCommerce REST API uitbreidt met POS-specifieke endpoints.

2. JavaScript-client: Deze draait lokaal in je browser, de desktop-app of de iOS-/Android-apps.

Je kunt het zien als twee aparte werelden:

• De PHP-wereld is waar databeheer plaatsvindt met behulp van WordPress en WooCommerce.
• De JavaScript-wereld houdt een lokale, offline bruikbare kopie bij van de winkelgegevens die je kassa's nodig hebben, geoptimaliseerd voor snel zoeken en directe respons.

SVG not found

Gegevenssynchronisatie

Gewijzigd in v1.10.0

v1.10.0 vervangt de vorige replicatielaag door een specifieke synchronisatie-engine. De samenvatting hieronder is de korte versie — de volledige uitleg staat in Hoe de synchronisatie-engine werkt.

De client werkt local-first: elk scherm leest en schrijft in de lokale database van het apparaat, en een synchronisatie-engine op de achtergrond houdt die database en WooCommerce bij elkaar. De engine spiegelt je hele winkel niet blindelings — hij vertrekt vanuit wat je schermen daadwerkelijk nodig hebben:

• Wijzigingsdetectie: de POS raadpleegt een licht wijzigingslogboek met voorwaardelijke verzoeken; een inactieve winkel antwoordt met een enkele 304 zonder body.
• Aangegeven behoefte: een scherm geeft aan wat het toont, en de engine bepaalt of daar een verzoek voor nodig is of dat het lokaal al beantwoord is.
• Aanvullingen en banen: een begrensde catalogusaanvulling, een venster met recente bestellingen en onderhoudsbanen tijdens inactiviteit vullen en verifiëren de lokale gegevens volgens schema's die je per apparaat kunt afstemmen.
• Duurzame schrijfacties: verkopen en bewerkingen komen lokaal in de wachtrij en worden naar WooCommerce verzonden, met zichtbaar herstel voor alles wat de server weigert.

Wat wordt er gesynchroniseerd: producten en variaties, categorieën/tags/merken, klanten, belastingtarieven, coupons (Pro) en bestellingen. Betaalgateways worden bij het afrekenen opgehaald.

Voor- en nadelen van de architectuur

Goed 😊	Slecht 😟
Zoeken in lokale gegevens is direct	Gegevens gesynchroniseerd houden is een uitdaging
Gecachte gegevens offline beschikbaar	Beperkt door de WooCommerce REST API
Mogelijkheid om betere native apps te maken voor desktop, iOS en Android	WordPress-thema's en hooks kunnen de POS-app niet aanpassen

Lokale database

De client slaat gegevens op in een lokale database op elk apparaat — de web- en desktop-app gebruiken OPFS-opslag (Origin Private File System) die in een worker draait, en de mobiele apps gebruiken hetzelfde schijfformaat via een bestandssysteem-engine. Alle platforms delen één opslagformaat en dezelfde herstelgereedschappen. Dit biedt:

• Persistentie: Gegevens blijven behouden na herstart van de browser en na het opnieuw opstarten van het apparaat
• Prestaties: Snelle query's zonder netwerklatentie — filteren, sorteren en pagineren gebeuren binnen de opslaglaag, zodat alleen de zichtbare pagina met rijen de interface bereikt
• Offline bladeren: Gecachte gegevens blijven toegankelijk zonder internet

Elke combinatie van site + winkel + kassamedewerker krijgt een eigen lokale database, zodat kassamedewerkers en winkels op één apparaat nooit lokale gegevens delen. Bij upgrades wordt een lokale database nooit ter plaatse gemigreerd — de app downloadt opnieuw vanaf de server, die altijd de gezaghebbende kopie is.

Afrekenarchitectuur

Het afrekenproces gebruikt een iframe/webview die de WooCommerce Order Pay-pagina laadt. Deze aanpak:

• Maakt gebruik van bestaande betaalgateways: Elke WooCommerce-betaalgateway kan in de POS werken
• Handhaaft de beveiliging: Betalingsverwerking verloopt via de veilige infrastructuur van WooCommerce
• Vermindert complexiteit: Geen noodzaak om integraties van betaalgateways opnieuw te implementeren

API-uitbreidingen

De PHP-plug-in breidt de WooCommerce REST API uit met extra endpoints voor POS-specifieke functionaliteit, geregistreerd onder de eigen naamruimten wcpos/v1 en wcpos/v2 — wcpos/v2 bevat het synchronisatie-oppervlak van v1.10.0, en daarom worden de app- en plug-inversies gelijk opgeleverd. Zie WooCommerce REST API voor een introductie.

De naamruimte wcpos/v2

v1.10 introduceert de REST-naamruimte wcpos/v2. Synchronisatie leeft hier, en de gedeelde POS-services die voorheen vanuit wcpos/v1 werden geserveerd, worden nu vanuit wcpos/v2 geserveerd (de serviceroutes van wcpos/v1 zijn doorgeefluiken naar hun v2-implementaties). De routes van wcpos/v1 registreren nog steeds voor achterwaartse compatibiliteit, maar zijn bevroren — de huidige client roept ze niet meer aan.

Punten die van belang zijn als je tegen deze endpoints integreert:

• De v2-routes registreren altijd. De oude optie woocommerce_pos_sync_api_enabled is verwijderd; er is niet langer een schakelaar die de API aan- of uitzet.
• Publieke endpoints. wcpos/v2/site, wcpos/v2/ping en wcpos/v2/echo zijn publiek (gebruikt voor het testen van mogelijkheden en connectiviteit, waaronder de transport-terugvalopties voor restrictieve hosts).
• Bestellingen zijn UUID-primair. De bestellingsidentiteit op de lijn is de UUID; het verouderde veld wooOrderId is uit de order-pull-envelop verwijderd. Bestellingsmetadata is op de lijn getypeerd via één enkele normaliser.
• Opslag van prijzen per regelitem is gedocumenteerd voor synchronisatiecompatibiliteit met derden — zie Hoe POS-prijsoverschrijvingen worden opgeslagen.
• Standaard productsortering in de POS is nu naam oplopend (voorheen menu_order, id).
• Verwijderde verouderde methoden. Verschillende verouderde methoden van de API\Settings-controller (bijvoorbeeld get_general_settings(), update_access_settings(), get_general_endpoint_args(), remove_license_transient()) zijn verwijderd; de klasse-alias blijft bestaan, maar die methoden niet.

Pro spiegelt de splitsing

WCPOS Pro volgt dezelfde V1/V2-splitsing — de gedeelde services worden gepromoveerd naar wcpos/v2 terwijl de bestelgegevens bevroren blijven op v1. Winkelgebonden productprijzen draaien op de v2-baan, en de winkelscope van de kassa wordt meegedragen op bestelschrijfacties zodat bestellingen voor meerdere winkels tegen de juiste winkel worden geprijsd en belast. Zie Pro.