Guides

HTML to Twig templates - the complete guide

Converting a static HTML/CSS design into Twig templates is one of the most common frontend-to-backend handoff tasks in PHP projects. Whether you're delivering to a Symfony developer, integrating with Drupal's theme layer, or building a standalone Twig-based site, the conversion process follows the same pattern.

A static HTML file has hard-coded values everywhere: headlines, image paths, text strings. Twig templates replace those with variables: {{ fm.props.headline }}, {% if fm.props.imageUrl %}, {% for item in fm.data.products %}. The HTML structure stays identical - only the dynamic parts change.

The full conversion involves identifying which values are dynamic versus static, replacing them with named Twig variables under a consistent namespace, wrapping optional blocks in {% if %} conditions, splitting the HTML into partials, layouts, and page templates, and documenting the variable contract so the backend developer knows what to pass. Done manually on a 10-component design, this takes several hours and produces output that varies in naming and structure depending on who does it.

Astro's component model - typed Props interfaces, explicit slots, no runtime by default - maps directly and mechanically to Twig. Required props become required variables. Optional props become {% if %} blocks. Slots become {% block %} regions. The mapping is deterministic. Structuring your design as a constrained Astro project before the Twig conversion gives you a typed, validated intermediate representation. Frontmatter Solo reads that Astro project and generates the Twig output automatically - partials, layouts, pages, a variable manifest, and an INTEGRATION.md that documents every variable the backend needs to populate.

The generated Twig output follows generic Twig conventions and works with Symfony, Drupal, Craft CMS, Statamic, and standalone Twig. Frontmatter Solo is the automation layer: one command, documented contract, backend-friendly output.