Weāve built ten-plus DatoCMS projects and keep running into the same four modelling problems: pages that contain content instead of referencing it, shared sections copy-pasted rather than linked, enums used for values editors want to change, and blocks used where models belong.
Wrote up the pattern behind all four, which is that a CMS is a database and the rules that prevent these are the same rules that apply to tables and rows.
Curious whether others land on the same four, or whether thereās a fifth we keep getting away with.
I think thatās a good summary! You did a nice job breaking down the basic reusability & lifecycle difference between a block and a model.
A block is basically a field template, but its contents canāt be linked to from anywhere else. For anyone coming from Wordpress, itās basically ACFās Flexible Content fields, and similar implementations exist in other CMSes too.
The below is fully IMHO, speaking for myself and not for Dato as a company:
In my experience, from a user support angle, I might add that non-developer editors, marketers, copywriters, etc. might not necessarily know anything about a database, or how a table is different from a record from a field, much less what a foreign key is. Most of the day-to-day friction I see isnāt necessarily from devs setting up a schema in a new CMS for the first time, but from regular users who have never learned the concept of a āschemaā to begin with ā the very idea that the content is different from the structure of a thing isnāt a common concept outside of database design.
Our CMS (and arguably any CMS) is an attempt to paper over that abstraction with a more user-friendly UI, but relationships are often the confusing partā¦ where devs might think in references and lifecycles, I think editors are more often just concerned about getting that page looking just right and published on time
That could often mean a back-and-forth between the dev team and the editorial team during the initial project setup:
Working together to design the initial schema based on editorial needs, but without jargon. Instead of āa foreign key into another tableā, simpler concepts like āwe should use models for anything that is used in more than one place, because we can edit it once and the changes will show up everywhereā might be easier to understand and develop for.
Prototyping it internally and iterating based on feedback
Once everything looks good, locking it down with validations, roles, and permissions so editors canāt accidentally footgun themselves ā make it as foolproof as possible, especially since later generations of users wonāt have the historical context of why things were set up a certain way years ago
Make the ācorrectā path the easy one whenever possible, using hints, fieldsets, maybe even custom plugins as necessary.
Document the whys and wherefores somewhereā¦ nobody is going to read it until and unless something breaks (which it inevitably will, usually years later when the original implementers are long gone). It helps AI agents understand business decisions made outside the context of the defined schema and codebase, too.
I think the critical part here is the two-way communication and co-design of a complex system. If the devs own the entire schema and project setup and donāt talk to the editorial team, the finished product is not likely going to survive real-world use for long. Youāre going to see frustration and very strange workarounds that users ingeniously develop specifically to get around the guardrails you put in place It has to be something co-owned and co-designed by the end-users from the get-go, IMHO, so they know when and why something was done a certain way (for their own long-term sanity, not because youāre being a dictator!).
Thanks Roger, really appreciate you taking the time to write this out. The point about content vs structure not being an obvious concept outside database design is one Iāll be stealing. It explains a lot of the confusion we see in early workshops, where editors talk about āthe pageā as one thing and weāre mentally splitting it into five models.
Fully agree on co-design. One thing that works well for us: we involve the client and editorial team as early as possible, and we deliberately run the DatoCMS side way ahead of the actual frontend build. The schema and content entry are usually usable weeks before the website catches up. That gives editors a much longer feedback loop. Theyāre working with real content in the real CMS while the model is still cheap to change, instead of discovering problems two weeks before launch when every adjustment ripples into the frontend.
Your point about making the correct workflow the easiest path resonates too. Editors will always find the path of least resistance, so it might as well be the right one.
It has to be something co-owned and co-designed by the end-users from the get-go, IMHO, so they know when and why something was done a certain way (for their own long-term sanity, not because youāre being a dictator!).