Contenttypes delen over meerdere klantsites

Je beheert twaalf klantsites bij je bureau en elk heeft een blog, een teamspagina en een dienstenaanbod. Als je het blogpost-contenttype verbetert — door een leestijdveld of een gerelateerde-posts-referentie toe te voegen — wil je die verbetering op elke site, niet alleen op de site waaraan je toevallig werkt. Gedeelde contenttype-bibliotheken maken dit haalbaar.

Het multi-space-probleem

ContentGrid geeft elk project zijn eigen space. Content is per space geïsoleerd, wat correct is — je wilt niet dat content van klant A verschijnt op de site van klant B. Maar schema's zijn ook per space, wat betekent dat schemadrift zich in de loop van de tijd opstapelt. De oplossing is je gedeelde contenttypes als een pakket te behandelen en schema-updates via migratiescripts te pushen in plaats van via handmatige dashboard-bewerkingen.

• Definieer canonieke contenttypes in een gedeelde schema-library/-repository of -map.
• Schrijf migratiescripts die wijzigingen toepassen op een lijst van doelspaces.
• Voer migrations uit tegen alle spaces vanuit CI wanneer de gedeelde bibliotheek wijzigt.
• Houd sitespecifieke extensies gescheiden van gedeelde typen.

De schemabibliotheek structureren

Organiseer je gedeelde typen in een dedicated repository waarnaar alle clientprojecten verwijzen:

• Maak een content-types/-map aan met één bestand per gedeeld contenttype.
• Elk bestand exporteert een ContentGrid-schemadefinitie-object — veldnamen, veldtypen, validaties.
• Maak een migrations/-map aan voor wijzigingen aan gedeelde typen.
• Publiceer de schemabibliotheek als een privé npm-pakket zodat clientprojecten het als afhankelijkheid kunnen installeren.

Wanneer een gedeeld type wijzigt, verhoog je de pakketversie, update je de migratie en voer je de migratie uit tegen alle geregistreerde spaces.

Migrations uitvoeren over meerdere spaces

Schrijf een migratierunner-script dat over je client space-ID's loopt:

• Sla alle client space-ID's en API-sleutels op in een secrets manager of omgevingsbestand, nooit in de repository.
• De runner leest de spacelijst, initialiseert per space een ContentGrid Management-client en roept de migratie up-functie aan voor elke space.
• Leg het resultaat per space vast — geslaagd of mislukt — en stuur een samenvatting naar een Slack-kanaal.
• Bij mislukking gaat de runner door naar de volgende space in plaats van te stoppen, zodat één problematische klant de anderen niet blokkeert.

Gedeelde typen per klant uitbreiden

Klanten hebben vaak sitespecifieke velden bovenop gedeelde typen nodig. Handel dit af met een extensiepatroon:

• Gedeelde typen definiëren kernvelden die overal van toepassing zijn.
• Elke client-space heeft een aparte lokale migratie die sitespecifieke velden toevoegt aan het gedeelde type.
• De gedeelde bibliotheekmigratie raakt alleen de velden die zij bezit — het verwijdert of wijzigt nooit sitespecifieke velden.
• Documenteer welke velden gedeeld zijn en welke lokaal zijn, zodat toekomstige ontwikkelaars weten wat ze waar moeten wijzigen.

Deze opzet kost een dag om te bouwen maar betaalt zich snel terug voor teams die vier of meer klantsites beheren. Schemawijzigingen die vroeger een week kostten over alle sites nemen nu een middag in beslag, en alle sites blijven consistent zonder handmatig kopiëren.