July 27, 2026

Sage View Composers: Keeping Your Blade Templates Presentation-Pure

You’ve likely felt the frustration of building WordPress themes that quickly devolve into an unmaintainable tangle. The traditional WordPress loop, sprinkled with `get_posts` calls or even custom queries directly within your `index.php` or `page.php` files, quickly makes templates difficult to read, reuse, and debug. This is precisely the kind of programmatic chaos that Sage, built on top of Laravel's excellent componentry like Blade and Acorn, seeks to eliminate. We developers choose Sage because it brings an MVC-like structure to WordPress, letting us create clean, presentation-focused templates completely divorced from data retrieval logic.

Today, I want to dive into a specific technique that embodies this philosophy: View Composers. If you've ever found yourself asking, "How do I get complex data into my Blade templates without cluttering them up?", then View Composers are your answer. They provide a powerful, centralized way to bind data to views, ensuring your Blade files remain purely responsible for displaying information, not fetching it. This is a stark contrast to the database bloat and code spaghetti often found in themes built with drag-and-drop page builders like Divi or Elementor, which, while offering quick visual builds, often sacrifice long-term maintainability and developer sanity.

Let's consider a common scenario: you have a custom post type, say "Projects," and you want to display a list of these projects on your home page, perhaps filtered by a custom taxonomy or other criteria. The "old" way, even with Blade, might involve something like this directly in `resources/views/partials/projects-list.blade.php`:

@php $args = ['post_type' => 'project', 'posts_per_page' => 3]; $projects = get_posts($args); @endphp

@if (!empty($projects)) <section class="projects"> <h2>Latest Projects</h2> @foreach ($projects as $project) <article> <h3>{{ $project->post_title }}</h3> <p>{{ $project->post_excerpt }}</p> <a href="{{ get_permalink($project->ID) }}">View Project</a> </article> @endforeach </section> @endif

While this works, it pollutes your Blade template with data fetching logic. The template is no longer just about presentation; it's also about *how* to get the project data. This makes the `projects-list.blade.php` less reusable and harder to test.

This is where View Composers shine. We can extract that data fetching logic into a dedicated class and *compose* it into our view when needed. First, let's create a new class, say `app/View/Composers/ProjectsComposer.php`:

namespace App\View\Composers;

use Roots\Acorn\View\Composer;

class ProjectsComposer extends Composer { /** * List of views served by this composer. * @var array */ protected static $views = [ 'partials.projects-list', 'front-page', // Or any other view that needs this data ];

/** * Data to be passed to view before rendering. * @param array $data * @return array */ public function with() { $args = [ 'post_type' => 'project', 'posts_per_page' => 3, 'orderby' => 'date', 'order' => 'DESC', ];

return [ 'projects' => get_posts($args), ]; } }

Now, instead of manually instantiating this composer, we register it with Acorn. The simplest way is to add it to your `config/view.php` file under the `composers` array, or for a more structured approach, within a service provider. Let’s stick to the `setup.php` for quick setup for this example, although a dedicated service provider offers more robust organization for complex applications. In `app/setup.php`, within the `add_filters()` function or directly after it:

add_action('after_setup_theme', function () { // Other theme setup... Roots\view()->composer(['partials.projects-list', 'front-page'], \App\View\Composers\ProjectsComposer::class); });

With this in place, your `resources/views/partials/projects-list.blade.php` becomes wonderfully simple and purely presentational:

Notice how the `$projects` variable is simply *available* in the template. The template doesn't care *how* `$projects` got there; it just knows it needs to display them. This drastically improves readability, makes testing the data fetching logic (`ProjectsComposer`) separate from the presentation, and enhances the reusability of your Blade templates.

This technique is a cornerstone of building robust, maintainable Sage themes. By consistently separating data retrieval from presentation using View Composers and Blade, you're not just writing code; you're crafting an organized, programmatic codebase that scales, adapts, and remains a joy to work with, rather than a constant source of frustration and refactoring. Embrace the Sage way, and free your templates from data-fetching burdens!