Acquia Site Studio Site Builder common mistakes
Acquia Site Studio Site Builder · Understand the traps and how to avoid them.
Treating Site Studio as a module that is enabled and then expecting components to appear, without running the Site Studio import/sync step for the UI kit.
Site Studio ships its component, template, and style definitions as configuration that must be imported into the site; candidates who only enable the module see empty component lists and then misdiagnose the problem as a permissions or caching issue.
What to do instead
Learn the import/sync workflow (importing the Site Studio package for the chosen UI kit) and verify components exist under the Site Studio component list before building anything.
Editing a component's markup or fields directly in the live site and expecting the change to persist across environments, instead of exporting/rebuilding the package.
Site Studio stores components as exported configuration; ad-hoc edits in one environment are not automatically carried to another, so candidates confuse per-environment edits with the packaged definition.
What to do instead
Make changes in the source environment, then rebuild and export the Site Studio package and import it into the target environment; treat the package as the unit of deployment.
Building a component with hard-coded text content in the template instead of exposing editable fields, then being unable to change content per page.
Candidates conflate the component's Twig/HTML template with its editable content model and forget that content must be authored through fields to be reusable and editable by editors.
What to do instead
Define the component's fields (text, WYSIWYG, image, link, etc.) and reference them in the template, keeping static markup only for structural elements.
Confusing a component's default values with slot/child-component behavior, placing nested components where a field was expected or vice versa.
Site Studio supports both field-based content and dropzones/slots for nested components; candidates mix the two and get components that render empty or reject dropped elements.
What to do instead
Decide per component whether content is field-driven or slot-driven, configure the dropzone/slot regions explicitly, and test by dropping a child component into the slot in the layout builder.
Making changes to a shared component and assuming every page using it updates, when pages have overridden the component instance.
Site Studio allows per-instance overrides of component field values; candidates don't realize an instance can diverge from the component definition, so they expect global propagation.
What to do instead
Understand the difference between the component definition and its instances, check whether an instance has overrides, and use the component-level edit only when a global change is truly intended.
Building a full page directly in a template and then being unable to reuse the layout, instead of composing pages from templates plus components.
Candidates skip the template layer and treat the layout builder as a page editor, producing one-off pages with no reusable structure.
What to do instead
Create a template that defines the page regions and slots, then build pages by placing components into that template so the structure is reusable and consistent.
Expecting a template's regions to render without assigning the template to the content type or page, or without the correct template being selected for the route.
Template selection depends on configuration tying templates to content types or paths; candidates build a template, see default output, and assume the template is broken.
What to do instead
Verify the template is assigned to the relevant content type or page and that template selection rules resolve to it; test with a node of that type.
Editing CSS in a global stylesheet for a single component instead of using the component's scoped styles, causing unintended changes elsewhere.
Candidates reach for the site-wide CSS field because it is familiar, not realizing Site Studio supports per-component style definitions that keep changes contained.
What to do instead
Put component-specific rules in the component's own style definition and reserve global stylesheets for truly site-wide rules; verify by checking other pages after the change.
Assuming changes to styles or components appear immediately, then 'fixing' a non-problem by re-editing, when caching or the compiled CSS/asset pipeline is the actual cause.
Site Studio compiles styles and caches output; candidates don't rebuild or clear caches and chase phantom bugs, sometimes introducing real ones while doing so.
What to do instead
After style or component changes, rebuild/regenerate the Site Studio assets and clear the relevant caches, then re-check before making further edits.
Misconfiguring breakpoints/responsive settings by editing desktop styles and expecting them to cascade correctly to smaller breakpoints, or setting values at the wrong breakpoint.
Site Studio's responsive style editing is breakpoint-scoped; candidates apply values at a base or larger breakpoint and are surprised when a smaller breakpoint overrides or fails to inherit as expected.
What to do instead
Set base styles first, then add breakpoint-specific overrides deliberately, and preview at each defined breakpoint to confirm the cascade behaves as intended.