About Wireframe

What is Wireframe, where did it come from, who is it for – and what sets it apart from all the other ProcessWire output strategies, or output frameworks, out there?

What is Wireframe?

If you've been around ProcessWire for a while, there's a good chance that you're familiar with the concept of output strategies. This refers to the way you organize your template files – the files that typically contain both markup generation and backend code (so-called business logic) for your site.

Wireframe is an output framework for ProcessWire. It provides you with a way to build ProcessWire powered sites using a model-view-controller inspired architecture, proper separation of concerns, and other software development best practices.

Wireframe is easy to get started with, yet it provides developers a solid foundation for building all types and sizes of websites.

Who is it for?

Using Wireframe is easy, so technically it's a tool for anyone interested in developing a website (or a web app for that matter) using ProcessWire. That being said, if you're just interested in taking one of the existing site profiles, making slight modifications to the front-end, and calling it a day – well, you may be better off looking at other solutions.

On the other hand if you're interested in applying a software development mindset to ProcessWire site development, you're quite likely going to enjoy using Wireframe.

Show me the code!

By now you're probably itching to see some code? No worries, we're almost there.

One last thing to know before we can get our hands dirty is that Wireframe consists of a set of components and files, all of which have their own purpose in the greater scheme of things: there's the bootstrap file, and then there are controllers, layouts, views, and partials – the last three of which form the "View".

On a very general level the bootstrap file and controllers are where your code belongs, while the rest form the view layer. There's also an object called "View", which allows the backend to talk to the front-end by passing variables, selecting a layout or view file, etc.

Bootstrap file

Bootstrap file is responsible for initiating the Wireframe module. Wireframe makes use of the "alternate template file" setting native to ProcessWire: by selecting your bootstrap file as the alternate template file for your templates you can route requests to this file, which then configures and boots up Wireframe.

The variables we pass to the Wireframe::render() method from this file become available in the View component, which allows you to access them from all your layouts, view files, and partials.

/site/​templates/​wireframe.php

<?php namespace ProcessWire;
  
// init Wireframe
$wireframe = $modules->get('Wireframe');
$wireframe->init();
  
// render the page (the render method takes an array of optional arguments
// for use in the View)
echo $wireframe->render([
    'lang' => 'en',
]);

Note: while usually you'll only have a single bootstrap file, that's not a hard rule by any means. If you want to, you can have more than one of these, each with their own settings.

Controllers

Controllers are optional components, basically something to mediate between View and model (latter of which means ProcessWire itself). In Wireframe the controllers are where your business logic lives. Controllers are PHP classes named after the templates they relate to: the controller for the home template should be called HomeController, etc.

/site/​templates/​controllers/​HomeController.php

<?php
  
namespace Wireframe\Controller;
 
/**
 * HomeController is the Controller for the home template
 */
class HomeController extends \Wireframe\Controller {
  
    /**
     * Render method is executed right before the view is rendered
     */
    public function render() {
        // Send a list of child pages to the View
        $this->view->children = $this->page->children;
    }
  
    /**
     * Public controller methods become accessible as params in the View, which
     * means that you can access them from your layouts, view files, and partials.
     *
     * @return string
     */
    public function login_status() {
        // Pass user name to the view
        $out = 'Not logged in';
        if ($this->wire('user')->isLoggedin()) {
            $out = "Logged in as " . $this->wire('user')->name;
        }
        return $out;
    }
  
}

Layouts

Layout files – of which your site can have only one, none at all, or multiple – are usually where the "shared parts" of your front-end live. Wireframe promotes this pattern instead of including separate header and footer partials in all of your view files, mainly for the sake of maintainability. (Your layout and view files can make use of as many partials as you need, though.)

Oh, and that `<?= $placeholders->default ?>` request below? That's how you define a slot for page content. You can have multiple placeholder slots, but the "default" one is often quite enough.

/site/​templates/​​layouts/​default.php

<!doctype html>
<html lang="<?= $this->lang ?>">
    <head>
        <title><?= $page->title ?> | <?= $this->site_name ?></title>
    </head>
    <body>
        <?= $placeholders->default ?>
    </body>
</html>

Views

Views are template-specific and typically represent a single page when it's rendered on the site. Each template could have multiple views, which effectively allows you to render the same page in different ways depending on some sort of switch (usually implemented within the controller class for that template.)

Just for an example your home template could have a default HTML view, an RSS view, and a JSON view for some sort of API to consume. You could use URL segments to pick the appropriate view, or you could always respond AJAX requests with JSON data, etc.

/site/​templates/​​views/​home/​default.php

<h1><?= $page->title ?></h1>
  
<div class="body">
    <?= $page->body ?>
</div>
  
<div class="login-status">
    <?= $this->login_status ?>
</div>

More details in the docs

Back to top