Regular readers of the blog know that we've really embraced ExtBase, TYPO3's new MVC framework, and its new templating system, Fluid. Not only is it ultimately more rewarding to develop with ExtBase than with the older, more procedural methods for building TYPO3 plug-ins, it's also more efficient. Because ExtBase encourages object-oriented development and strong separations of logic and presentation, we end up with more modular code that we can reuse across projects. This modularity helps drive revenue growth for CIC while reducing the time (and costs) associated with developing custom TYPO3 extensions for our clients. Win win!

Over the past month or two, as we’ve finished transitioning from our own MVC framework (CICMVC) to ExtBase, and as we’ve fully incorporated Git and Phing into our release processes, we’ve made a number of architectural changes to the starter package we use for new sites. One of the biggest changes that we’ve made is to finally abandon TemplaVoila in favor of fluid-based page templates and back-end layouts.

Unlike many agencies that have embraced TemplaVoila wholeheartedly, we’ve never quite been comfortable with it. We’ve always felt that the mapping process required by TemplaVoila is tedious (and error-prone). TemplaVoila templates also aren’t very portable, and because parts of them are stored in the database, they’re difficult to track in version control, which causes a number of problems for us. Nonetheless, we’ve kept coming back to TemplaVoila over the years because of the obvious shortcomings of the TYPO3 page module, which has traditionally been limited to four content areas.

But all that has changed now, hasn’t it? After all, we no longer need TemplaVoila for FCEs, since we can simply create custom content objects using ExtBase and the approach I outlined in previous posts on this blog. It may take a few minutes longer to make a custom content element (unless you’ve had some practice at it), but the payoff in standard TCA user interfaces (come on, admit it: FlexForms suck!) is worth the added trouble. More important, we no longer need the TemplaVoila page module because we now have back-end layouts.

Like TemplaVoila templates, back-end layouts make it possible to create a tailored editing interface that contains as many or as few content areas as needed, thereby addressing the limits of the classic page module. It also provides the editor with a clear interface on the page module for selecting a template for pages and child pages. Finally, it can be used without any of the tedious mapping process and the added XML abstraction layer that TemplaVoila requires.

We’ve written an extension called "Fluid Pages" that incorporates backend layouts with Fluid templates and solves the problems described above (you can download the t3x file here). I think it’s a viable approach to page templating in TYPO3, one that’s easier for both editors and developers, and I’d love to know what you think.

Read on for specifics about how to get up and running with Fluid Page templates!

1. Download and install the “fluidpages” extension. This extension will make a few minor changes to your TYPO3 installation.

First, it will add a field to the backend layout record called “body class name.” This field can be referenced in the fluid template for a page using a {layoutClass} variable marker. In many cases, we like to use just one or two HTML templates for a site and use body classes to change look and feel.

Second, it includes TSConfig that improves to the layout selection UI on the page record. By default, TYPO3 includes a layout field on the page record AND a backend layout field on the page record. I’m sure that seemed like a good idea at some point, but in our view, that’s only going to confuse content editors. We want our clients to be able to select a template for a page and then have that template be reflected in the backend and in the frontend output. I don’t think there are many real use cases where these fields will diverge, so we’re fixing this UI issue. The TSConfig will hide the “layout” field on the page record (and the newUntil and module fields, which our clients also find confusing), and rename the  “backend_layout” field to “Page Template (this page only)”. The “backend_layout_next_level” field is renamed to “Page Template (subpages of this page). We feel these are UI improvements, but if you don’t like them, you can always remove them in TSConfig.

2. Make a storage folder in the backend and make sure it’s the general records storage page (that is, on the root page of the site, select that folder in the general records storage page field).

Create a backend layout record in the storage folder. I’m going to make a simple layout with three content areas (top, left, and right). Be sure to set a column number for each area.

Assign it a body class (eg: two-column-header) and an appropriate title. Save the record when you’re finished.

3. Now, we need to setup our PAGE object in Typoscript to use fluidpages.

First, we’ll create RECORDS content objects for each content area. We can piggy back off of css_styled_content here by adding the following to our Typoscript setup:

4. The next step is to setup the PAGE object in Typoscript and point it at the fluidpage extension’s output.

In the snippet below, the page object is declared at line 11. At line 15, we set the body tag to be a space character so TYPO3 doesn’t try to render it (there may be a better way to prevent TYPO3 from rendering the body tag, but we haven’t found it yet). At line 18, we set page.10 to be the output of the fluidpages extension, similar to how templavoila is referenced in Typoscript. At line 23, we’re telling fluidpages which Fluid template file to use when a page is set to use the backend layout with the UID of “1”. If you have multiple backend layouts, which you probably will, you can add additional entries in the templates section that are tied to backend layout UID. We tend to store our extensions in a template so that we don’t mix developer content with client content in fileadmin, but it’s certainly possible to use a fileadmin/templates path here if you prefer. At line 27, we define Typoscript objects that can be referenced as variables (eg: {castIronCoding} ) in the fluid template itself.

5. Finally, go ahead and create your fluid page template.

This template should follow all the regular rules of Fluid templates in terms of syntax and well-formedness. The only rule is that you need to include a subpart marker before the opening body tag and after the closing body tag (see line ### in the snippet below). In a future iteration, we’ll remove the need for the subpart marker; we just haven’t gotten to it yet. Our template looks like this:

This template probably won’t work for you out of the box. We have a userFunc or two being called via Typoscript to handle the IE conditional HTML tag, and we’re using the HTML5 doctype. That can all be changed to whatever you’re more comfortable with. The important parts are here:

• At line 36 you’ll see the opening ###LAYOUT### marker. We’ll get rid of this at some point, but for now you need that above your body tag. Notice the corresponding marker at line 98. Those tell fluidTemplate what part of the template to treat as a fluid template.
• At line 37 you can see how the body class from the backend layout record gets included in the template. This could obviously be referenced elsewhere in the template.
• At line 52 we’re including a typoscript object. This is one of the best parts of this approach to templating—there’s no more need to map elements to typoscript objects, like in TemplaVoila, nor do you need to do the mapping in Typoscript, like in automaketemplate. Now we can just reference Typoscript objects directly in the template.
• At line 58 we render the “castIronCoding” typoscript object that we defined in the PAGE typoscript
• At line 55 there is an example of a condition based on which layout is being used. This allows us to use the same HTML template for multiple layouts, which reduces the time required to maintain and modify templates.
• At line 57, 71, and 77 we’re including the content areas that we setup in Typoscript.

That’s pretty much it!

In our view, this approach to TYPO3 templating is more powerful, more user-friendly, and easier to develop/maintain than the alternative approaches. Moreover, it’s entirely based on the powerful tools that are already present in TYPO3: fluid and Typoscript, which suggests that this approach could serve as a core approach to page templates at some point in the future.

Click here to download the fluid pages extension. If people like it and use it, let us know and we'll put it in a repository on GitHub.

Thoughts? Suggestions? Feedback? We love it! Keep it coming!