Skip to main content
Crafting Smarter Layouts: Reusable Twig Partials in FlyntWP

Crafting Smarter Layouts: Reusable Twig Partials in FlyntWP

When I first started building WordPress sites, the promise of low-code page builders was alluring.

When I first started building WordPress sites, the promise of low-code page builders was alluring. Drag-and-drop, quick launches – it sounded great on paper. In practice, however, I quickly encountered the downsides: bloated HTML, slow load times, and a complete lack of developer control that made even simple customizations a nightmare. That’s why I’ve fallen in love with FlyntWP. It’s a refreshingly programmatic approach, leveraging the power of modern tools like Vite and the elegance of Twig components to build truly lightweight, performant websites. This isn’t just about avoiding bloat; it’s about crafting a better development experience and delivering flawless Core Web Vitals right out of the box.

One of the foundational principles that makes FlyntWP so powerful is its emphasis on modularity. We think in components, not just pages. While top-level components like a Hero section or a Content_Grid are excellent for structuring page content, the real magic for maintainability and speed comes from thinking even smaller. How often do you find yourself building the same basic elements – a “card” with an image, title, and description, or a button with specific styling – repeatedly across different components? Copying and pasting code is an anti-pattern that leads to inconsistencies and headaches down the road. This is where reusable Twig partials come into play, allowing us to define these common elements once and use them everywhere.

Let me walk you through a practical example: creating a simple Card partial that we can then integrate into various Flynt components. This keeps our design consistent, our code DRY (Don’t Repeat Yourself), and our DOM structure incredibly clean. First, within your _components directory, you can create a subfolder for these smaller, internal components. I like to use _partials to distinguish them from the main, user-facing components. So, our Card partial would live at _components/_partials/Card/index.twig.

Here’s what our _partials/Card/index.twig file might look like:

<div class="card {{ class|default('') }}">
        {% if image %}
            <div class="card__image-wrapper">
                <img src="{{ image.src }}" alt="{{ image.alt }}" loading="lazy" width="{{ image.width }}" height="{{ image.height }}">
        {% endif %}
        {% if title %}
            <h3 class="card__title">{{ title }}</h3>
        {% endif %}
        {% if description %}
            <p class="card__description">{{ description }}</p>
        {% endif %}
        {% if link %}
            <a href="{{ link.url }}" class="card__link" target="{{ link.target|default('_self') }}">{{ link.title|default('Learn More') }}</a>
        {% endif %}

Now, let’s say you have a Component_Grid that displays multiple cards, with their content managed via an ACF Pro Repeater field. Within your Component_Grid/index.twig file, you can effortlessly include our Card partial for each item in the repeater. Assuming your ACF Repeater field grid_items returns an array of objects, each containing item_image, item_title, item_description, and item_link:

<div class="grid">
        {% for item in data.grid_items %}
            {% include '_partials/Card/index.twig' with {
                image: item.item_image,
                title: item.item_title,
                description: item.item_description,
                link: item.item_link,
                class: 'grid__item-card'
            } %}
        {% endfor %}

Notice how we use {% include ... with { ... } %}. This is Twig’s elegant way of passing specific variables directly to our partial. The class variable in our Card partial uses |default('') which allows us to pass an additional class (like grid__item-card) for styling specific to its context, without requiring it to always be present. This flexibility is key to building truly adaptable components. The image variable, coming directly from an ACF Image field, provides src, alt, width, and height properties, which are crucial for optimal image loading and Core Web Vitals performance.

The benefits of this approach are immense. You write less code, which means fewer bugs and faster development cycles. Any design or structural update to the Card partial, say changing the order of elements or adding a new icon, instantly propagates across every instance where it’s used. This level of consistency is impossible with traditional page builders and a dream for large-scale projects. Furthermore, by carefully crafting these small, focused partials, we ensure that our generated HTML is lean, semantic, and free of unnecessary wrappers, contributing directly to those “flawless Core Web Vitals” we all aim for. It’s a programmatic approach that keeps your site agile, fast, and a joy to maintain.

Related Posts