Acquia Site Studio Site Builder: The Vanishing Component After a Config Import

The Vanishing Component After a Config Import

A team has three environments: local, staging, and production. A developer builds a new card component locally, using a paragraph bundle called card_media and referencing an image style card_thumb. After exporting configuration and importing it on staging, editors report that the card renders as an empty region. On production, which is imported next, the same thing happens. The component source is present in the Site Studio UI, but the rendered markup is missing entirely. The team also notices that the base styles for the component do not appear in the compiled CSS on staging or production. Local works fine. No PHP or Twig errors appear in the logs.

1. What is the most likely category of failure, and how would you confirm it without guessing?

Read the worked answer

The symptom pattern - component exists in the UI but renders nothing and its CSS is absent - points to a dependency that was not captured in the exported configuration, not a code error. Site Studio components can depend on Drupal config entities (paragraph types, image styles, view modes, field storage) that are not automatically bundled with the component export.

Confirmation steps:

Compare the exported config on local vs. what is present on staging: check config/sync for the paragraph type, image style, and any view mode the component references.
On staging, inspect the component in the Site Studio UI and look at its referenced entities; if a referenced entity is missing, the render pipeline has nothing to bind to.
Check the compiled CSS/asset build - if the component's stylesheet import points to a missing source, the build silently skips it.
Use drush config:status to list config that differs or is missing between the export and the target.

The key judgement is to verify the dependency chain, not to re-export blindly or clear caches repeatedly.

2. The team's instinct is to re-export everything from local and import it to staging. What are the risks, and what is the better approach?

Read the worked answer

A full re-export is risky because it can overwrite environment-specific config (e.g., staging's system.site, environment-specific keys, or config that was intentionally divergent) and can create config conflicts that are harder to diagnose than the original problem.

Better approach:

Add the missing dependencies explicitly to the component's export set - paragraph type, image style, and any referenced field storage/config.
Import incrementally and verify on staging before promoting to production.
Document the dependency contract so future components list their required config entities.
Consider a config ignore strategy for environment-specific settings so a full export stays safe.

The judgement being tested: fix the root cause (missing dependencies) rather than the symptom (empty render) and avoid the blunt instrument of a full re-export.