Acquia Site Studio · formerly Cohesion
Site Studio is design system governance. Or it becomes a component warehouse.
Both outcomes come from the same product. What decides is not the tool, it is who has authority to create a component and what happens when someone wants a new one.
The stack
Site Studio does not run alone.
Three pieces, three distinct responsibilities. We operate all three.
CMS
The base. Content, permissions, workflow and the cache layer.
Platform
Site Studio and managed hosting. We are partners.
Search
Managed Solr. The search Site Studio does not solve.
What it is
A visual building layer where a component is configuration, not a drawing.
A component library defined by engineering, from which the content team assembles pages. Each component is versioned configuration: it lives in the repository, goes through review, travels between environments as code.
What is not in the library cannot be used. That restriction is not a limitation of the product. It is the product.
Layers
Variants
Properties
Element tree
What the editor fills in
The same component, twice. On the left what the designer defines; on the right what the editor receives to use. Between the two there is not a single line of code, and that is exactly what you buy when you buy Site Studio.
Look at the token: space/lg carries the same name on both screens. That is not naming coincidence, it is governance. When it changes in Figma and does not change here, the design system has become the component warehouse this page talks about.
The expensive mistake
Treating Site Studio as a page builder.
It starts out looking like speed, and the pattern is always the same:
- 01A campaign needs a different block and gets a new component
- 02The new component is not reviewed, because nobody sees it as code
- 03Six months later the library holds three versions of the same card
- 04The design system stops being verifiable: nobody knows which version is right
The symptom is the library growing. The cause is that there is no answer to who decides a new component is needed.
The engineering layer
The product compiles editor data into the template source code.
That single fact explains almost everything that goes wrong at scale. The generated template is not a file that reads data: it is a file where the value an editor typed becomes part of the compiled source.
The practical consequence: a field declared as text that merely LOOKS numeric is emitted unquoted. A phone number with a stray dot at the end becomes an invalid literal, the Twig fails to compile, and the canvas starts erroring on every render. Saved successfully, broken forever.
The four answers
Four defences for the same fact.
These are not four problems. It is one problem and a progression: contain, repair, guarantee it in the deploy and, if the cost persists, take over generation.
- 01CONTAIN. On save, the compiled Twig is validated and the save is aborted if it does not compile. It belongs in the entity presave, where the template already arrives compiled, parsed the same way rendering would parse it.
- 02REPAIR. A routine checks what already exists: if it compiles, leave it; if it does not, fix it and recompile to verify; if it is still broken, swap in a valid stub and log it. The page loses one block instead of losing everything.
- 03GUARANTEE AT DEPLOY. A compiled template is a generated artefact, and any regeneration overwrites it. The routine runs inside the deploy, in the step right after regeneration. A fix applied by hand disappears on the next rebuild, silently.
- 04TAKE OVER GENERATION. Generate the template yourself, with the source carrying structure only and the value travelling in the context. This is not a setting: it is an architecture decision, and it is what makes the source inert by construction.
Verified correction, never assumed. When the vendor generator is replaced by your own, validation means comparing the rendered HTML: reading the generated code and judging it the same is not proof.
What the product does not do
What you will write, whether you want to or not.
- Invalidating a shared component. Changing a reused block does not invalidate the pages that render it, nor the edge. It takes code to find which pages use it, nested uses included, and purge each one outside the save, because that lookup is expensive and makes the editor wait.
- Preview of what has not been saved. The product does not show the real page with pending changes. It takes rendering through a subrequest, applying the unsaved values, without writing to node, layout or revision.
- Deploying a component package. It does not travel in the standard configuration export and import: it needs a rebuild in the target environment. Getting that step wrong takes down the layout of the entire site.
The solution
Declared translation.
A designer hands over a screen and someone recomposes that screen by hand inside the CMS. That journey is where the library turns into a warehouse: the similar component gets used instead of the right one, and spacing and colour are typed instead of referenced.
There are two layers with different owners: Site Studio governs composition, the design system governs appearance and behaviour. The point of contact is the Site Studio component emitting the design system tag instead of drawing its own markup.
None of it shows up in review, because the result looks like the Figma file. Manual recomposition is the cause. One table declares, per component, what it emits in the design system and what it becomes on the canvas, and composition stops being recomposed: it gets published.
What it does not guarantee yet
The architecture supports the guarantee. The implementation still delivers it as a preference.
When a Figma node matches no entry in the table, the transformer does not refuse: it infers a generic structure from the node type, the name, the auto-layout direction and the fill. The design loses the design system component and survives as structure. And the match is not exact: the name is normalised and compared by substring in both directions, so "Button Group" matches the entry "Button".
The deviation is counted when the component exists in Figma and not in the table. In the other two cases it does not appear: a component matched to the wrong entry is counted under the wrong name, as if it were right, and a hand drawn lookalike never enters the count at all. The report shows absence, not divergence.
The table is where the gate belongs: refusing instead of inferring, and matching exactly instead of by substring. Two small, well understood changes. They are not there yet, and saying otherwise would be the one passage on this page that does not hold up under a question.
What is not in the library cannot be used.
That restriction is not a limitation of the product. It is the product, and it is what keeps the library from becoming a warehouse.
The decision
When Site Studio is worth it, and when it is not.
Worth it when
- Many people publish, with different responsibilities
- A design system exists and must survive the hurry of whoever publishes
- The operation is multi-brand, multi-country or multi-site
- Engineering is the bottleneck for publishing, and that is costing campaigns
Not worth it when
- The site has few pages and a small team publishing
- There is no design system to protect, and Site Studio would become the place where it should have been born
- The expectation is that the tool replaces the decision about governance
The useful question is not whether Site Studio is good. It is whether your operation has the problem it solves.
Questions from people already running it
- Can we migrate from Cohesion to Site Studio without rebuilding the site?
- In most cases yes: it is the same product lineage and the migration is a version change, not a platform change. The real work is rarely the upgrade itself, it is deciding what to do with the components the installation accumulated. Migrating while carrying a bloated library means paying twice for the same problem.
- Does Site Studio make Drupal slower?
- Not by itself. What weighs is how many distinct components render on the same page and how granular the cache tags they declare are. A lean library with well declared caching performs indistinguishably from hand written templates; a bloated library is slow for the same reason any page with too many components is.
- Who should be allowed to create components?
- Whoever answers for the consistency of the design system, which usually means engineering together with design, never whoever is closing a campaign. It is not about trust: people under deadline always take the shortest path, and the shortest path is creating a new component instead of finding out whether a similar one already exists.
- How do we know our library is already too large?
- A practical check: ask two people from the content team to build the same page, separately. If they pick different components for the same block, the library already holds duplicates and is no longer enforcing the design system.
- Does Site Studio replace a design system?
- No. It enforces a design system that already exists, which is different. Without design decisions made beforehand, the library becomes the place where each decision is taken again, one campaign at a time, with nobody reviewing the whole.
A real design system has numbers. A component library has a catalogue.
- 479
- components in the design system
- 675
- templates built on top of them
- 3.172
- canvases assembled in production
- 49
- custom modules in production, of 79 built
- 18
- editors publishing without raising a ticket, in 90 days
- 9.028
- content revisions in those same 90 days
Measured in the database of a large-scale corporate platform we operate. No client name and no sector: design-system scale does not identify a company, which is why these figures can be published while others from the same project cannot and are not.
Tell us what your library looks like today.
How many components exist, who may create a new one, and what has already broken because of it.
Engineering is not decoration. It is direction.