Shopware 6
Een Shopware-plugin die je fabrikantcatalogus uit pCon importeert, de 3D-configurator op de productpagina laadt, en wat de klant samenstelde in de order wegschrijft. Hij installeert via Composer als elke andere plugin, en hij heeft geen buildstap op je server nodig.
Dit is het deel dat bepaalt of een configurator speelgoed is of een verkoopinstrument. Per samengestelde regel krijgt Shopware:
Elke configuratie is een eigen regel. Twee bureaus uit hetzelfde product blijven twee regels met twee prijzen, en dat is het verschil tussen een order die je kunt uitleveren en een order waarover iemand moet bellen.
Een private Composer-repository, die je eenmalig aan je project toevoegt. Daarna is het een gewone plugin: refresh, installeren, activeren. Je vult de sleutel in die je in het portaal hebt aangemaakt en de verbinding meldt zichzelf aan.
Blader in de beheeromgeving door de boom van de fabrikant, kies artikelen en importeer ze als Shopware-producten: titel, specificaties, prijs, de render als productafbeelding, de kenmerken als eigenschappen waarop je kunt filteren, en het merk als echte fabrikant.
Er zit niets vast in het product. De pagina bouwt de configurator-URL bij het renderen uit de artikelreferentie en de instance die centraal bij je account staat, dus van instance wisselen is een instelling en geen datamigratie.
De configurator post de OCI-velden naar een ondertekende route op je eigen shop. De plugin controleert de handtekening, controleert de prijs, importeert de render en zet de bezoeker in zijn eigen wagen met de configuratie op de regel.
Wat het van je omgeving vraagt: Shopware 6.7, zelf gehost en dus niet op Shopware Cloud, op PHP 8.2 of nieuwer, en max_input_vars verhoogd naar 5000. Dat laatste is een hostinginstelling en geen plugininstelling, en het bepaalt of een configuratie van twintig artikelen of meer in één stuk de wagen haalt.
Architectuur
Hier hoor je precies over te zijn, want het bepaalt wat een update je later kost. Geen wijzigingen in de kern, geen vervangen templates, en niets waar een Shopware-bureau ons op zijn woord voor moet geloven.
Een cart-processor zet de samengestelde prijs bij elke herberekening terug op de regel, in de btw-vorm van die wagen. Shopware rekent bij elke paginaweergave opnieuw en nog een keer bij het plaatsen van de order, dus dit is het verschil tussen een prijs die blijft staan en een die terugvalt op de catalogus.
De artikelreferentie en de handmatige URL zijn custom fields op het product, aangemaakt bij het installeren. Zichtbaar in de beheeromgeving, met de hand aan te passen, en weer weg als je de plugin verwijdert.
Kenmerken worden eigenschappen, dus filteren werkt op de configuratieopties zelf. Het merk wordt de fabrikant die Shopware al kent, in plaats van een categorie die voor fabrikant speelt.
De beheermodule wordt voorgecompileerd meegeleverd en de opmaak van de storefront maakt Shopware in PHP, dus er staat geen Node op je productieserver en er is na een update niets te herbouwen.
Snelheid en vertrouwen
Shopware cachet productpagina's, en die cache is een groot deel van de reden dat de shop snel is. Een configurator hoort niet de reden te zijn dat je hem opgeeft.
De import loopt server-naar-server achter een sleutel die nooit in de browser komt, de configurator is toegestaan op grond van een domeinwhitelist, en de winkelwagen krijgt een handtekening die je eigen shop controleert. Dat zijn drie gescheiden kanalen die nooit een sleutel delen. Hoe dat in elkaar zit.
De plugin staat niet in de Shopware Store en heeft dus een eigen kanaal: een private Composer-repository die je eenmalig aan je project toevoegt. Daarna toont composer outdated nieuwe versies en installeert composer update ze, net als elk ander pakket, en Composer controleert de checksum voordat hij iets uitpakt.
Het downloadadres verloopt met opzet niet. Composer schrijft het in je composer.lock, en een link die na een dag doodging zou de deploy breken die je volgende maand draait uit een lockfile van vandaag. Er zit geen licentiesleutel in de plugin, geen aftelklok en geen killswitch: loopt een abonnement af, dan zegt de plugin dat tegen de beheerder en blijft de shop verkopen.
Je hebt een eigen pCon.ui-instance van EasternGraphics nodig, en zij moeten het domein van je storefront met de hand op de whitelist zetten. Dat zijn één live domein plus twee ontwikkeldomeinen, geen wildcards, en elk subdomein apart. Vraag om een shop-instance en niet om een lead-instance: een lead-instance heeft geen knop naar de winkelwagen, dus dan kan er niets bij je shop aankomen. Je fabrikanten moeten daarnaast OFML-data publiceren en hun catalogus met jouw account hebben gedeeld. Weet je niet of ze dat doen, dan is dat precies de vraag om aan ons te stellen.