Beschikbaar voor nieuwe Shopify-projecten

Native bouwenGids

Metaobjects als besturingslaag: waarom theme settings een plafond hebben

Diek ThunnissenDiek Thunnissen8 sep 20268 min leestijd

Theme settings houden op bij de rand van je thema. Een metafield reist met één product mee. Een metaobject is overal leesbaar: productpagina, eigen landingspagina, structured data, Flow, checkout en headless. De regel om te kiezen, de zes oppervlakken, en de drie valkuilen die de docs niet noemen.

Bijna elke bouwkeuze in Shopify begint met dezelfde vraag: waar moet dit staan? De levertijd, de USP's, de actie van volgende week, de configuratie van een product. Er zijn drie plekken voor, en ze lijken inwisselbaar. Dat zijn ze niet. Het verschil zit niet in wat je erin kunt stoppen, maar in wie erbij kan.

Een theme setting is thema-gebonden: alleen die ene sectie in dat ene thema leest hem. Een metafield hangt aan één product, klant, collectie of order en reist daarmee mee. Een metaobject is een eigen record dat nergens aan vastzit en daardoor vanaf elke plek bereikbaar is. Taylor Page vatte het op DotDev 2026 samen als: theme settings zijn onbereikbaar, metaobjects zijn eindeloos bereikbaar.

Een theme setting sterft met je thema. Een metafield reist met je product. Een metaobject leeft overal.

Waar theme settings ophouden

Theme settings zijn gemaakt voor vormgeving: een kleur, een knoptekst, een sectie aan of uit. Daar zijn ze goed in. Het gaat mis zodra er data in belandt die ergens anders ook nodig is. De verzenddrempel die in de balk staat én in de kortingsregel. De USP's die op de productpagina staan én in de checkout. De creator-deal die op de landingspagina staat én in de cart. Elke keer dat je zo'n waarde op twee plekken bijhoudt, ontstaat er een moment waarop ze niet meer gelijk zijn.

En dat is het lichte geval. Het zware geval is een systeem dat er niet eens bij kan: de checkout, een Flow, een feed-app, een extern verkoopkanaal. Theme settings bestaan alleen binnen het thema. Alles daarbuiten ziet ze niet.

Het patroon: één record, een brug, veel lezers

Je definieert een metaobject met de velden die bij een ding horen. Een creator: naam, handle, kanaal, intro, galerij, producten. Een actie: naam, coupontekst, begin, einde, producten. Een bureaublad bij Ivono: maat, materiaal, prijs, compatibele frames. Dan leg je een brug: een metafield van het type metaobject-referentie op het product (of de klant, of de collectie) dat naar de entry wijst. Vanaf dat moment is de entry overal waar dat product komt, en daarbuiten ook nog.

Bij Ivono is de complete configurator zo gebouwd. Bladen, frames, opties en prijzen zijn metaobjects die naar elkaar verwijzen, en het product draagt alleen de referentie naar zijn startpunt. Geen configurator-app, geen theme settings met vijftig velden. De klant beheert zijn assortiment in records die hij snapt, het thema tekent er de samensteller uit.

De zes oppervlakken

Eén: het thema. Via de brug op het product, of rechtstreeks op handle. De cart-drawer op onze demo-store zoekt de creator op via een cart-attribuut en toont avatar en deal.

Twee: een eigen pagina per entry. Een metaobject-definitie kan entries publiceren als webpagina, met eigen URL en meta description. Onze creator-landingspagina is zo'n pagina: de kale URL is de link die de creator deelt.

Drie: structured data. Alles wat niet in de standaardvelden past (materiaal, herkomst, compatibiliteit) kan uit het metaobject als JSON-LD mee naar zoekmachines en AI-assistenten. Eén bron, dus wijzig je het materiaal, dan klopt de productpagina en de structured data tegelijk.

Vier: Flow. Triggers op entry aangemaakt en entry bijgewerkt maken van een entry een knop. Onze pre-ordercampagne is één metaobject; opslaan stampt de waarden als metafields op elk product in de lijst.

Vijf: de checkout. Checkout-extensies vragen metaobjects rechtstreeks op via de Storefront API. Het bedankpagina-blok op de demo-store toont per kanaal andere content uit dezelfde definitie.

Zes: headless en andere kanalen. Een app, een marketplace-koppeling, een kiosk in de winkel, een feed: allemaal dezelfde query. Dit was het geval dat Taylor Page tot zijn stelling bracht: productconfiguratie in theme settings was voor een extern kanaal simpelweg onbereikbaar.

De code van alle zes, op onze demo-store, staat in het vervolgstuk: Eén metaobject, zes oppervlakken.

Metaobjects aan metaobjects

Wees niet bang om entries naar entries te laten wijzen. Een creator wijst naar producten, een kanaal wijst naar testimonials, een pre-ordercampagne wijst naar producten, een bureaublad bij Ivono wijst naar frames die naar opties wijzen. Dat is geen complexiteit, dat is je domein zoals het is. En merchants snappen het sneller dan een json-veld: het zijn formulieren met dropdowns, geen komma's die verkeerd kunnen staan.

Eén regel houden we wel aan: de graaf leest van boven naar beneden. Product wijst naar config, config wijst naar onderdelen. Nooit terug. Zodra een onderdeel naar zijn ouder wijst, weet niemand meer wie de waarheid is.

Het beslisframework

Gaat het over hoe iets eruitziet in dit thema? Theme setting. Gaat het over dit ene product of deze ene klant, en verandert het per stuk? Metafield. Gaat het over een ding dat op zichzelf bestaat en waar meerdere producten, pagina's of systemen naar wijzen? Metaobject, met een metafield als brug. Twijfel je, kies dan het metaobject. Dat is nooit fout, andersom wel.

Twee van onze eigen builds als toets. Het memberprogramma: één json-veld op de shop met tiers, drempels en cadeaus, gelezen door vijf Functions, drie checkout-blokken, een accountpagina en een theme-snippet. Shop-breed, dus geen theme setting. Eén record, dus geen metafield per klant. De verzenddrempel per land en klanttype: zelfde toets, zelfde uitkomst.

Drie dingen die de docs niet hardop zeggen

Eén: een metaobject is pas buiten de admin leesbaar als de storefront-toegang op de definitie aanstaat. Zonder dat werkt Flow wel en je thema niet. Wij verloren er een middag aan.

Twee: lijstvelden lees je in Liquid alleen met een forloop of de filter first. Bracket-indexing en .first als property werken niet op metaobject-lijsten.

Drie: Shopify Functions volgen geen metaobject-referenties. Een Function leest een metafield op het product of de shop, maar kan niet doorklikken naar de entry erachter. Wat de checkout moet weten, moet dus als metafield of shop-json naast het metaobject staan, en Flow houdt dat gelijk. Het metaobject blijft de beheer-bron, de metafields zijn de kopie waar de kassa mee rekent.

Het advies van Taylor Page aan het eind van zijn talk nemen we graag over: pak deze week één shop, zoek de plek waar je hetzelfde op twee plaatsen bijhoudt, en zet dat in een metaobject. Bij ons was dat de creator, en daarna de pre-ordercampagne. Sindsdien is een nieuwe campagne een formulier invullen.

Veelgestelde vragen.

Kan een Shopify Function een metaobject lezen?
Niet rechtstreeks. Input queries van Functions volgen geen metaobject-referenties. Zet wat de checkout nodig heeft als metafield op het product of als json-metafield op de shop, en laat Flow die bij elke wijziging van het metaobject bijwerken. Het metaobject blijft de beheer-bron.
Wanneer is een metafield beter dan een metaobject?
Als de waarde echt van dat ene product of die ene klant is en per stuk verschilt: een levertijd, een maatadvies, een VIP-vinkje. Zodra meerdere producten dezelfde waarde delen of meerdere systemen ernaar moeten kijken, wordt het een metaobject met een metafield als brug.
Waarom niet gewoon een app voor dit soort content?
Een app slaat de data op in een eigen database buiten Shopify. Het thema kan erbij via het script van de app, maar Flow, de checkout, de Storefront API en andere kanalen niet. Een metaobject leeft in Shopify zelf, elke laag van het platform kan hem lezen, en hij blijft bestaan als je de app opzegt.
Diek ThunnissenDiek ThunnissenFounder & lead developer. Bouwt, verbetert en migreert de Shopify-laag voor DTC- en B2B-merken. LinkedInPlan een gesprek

Technische Shopify-inzichten uit de praktijk.

Geen sales, wel techniek.