Home

Frequently Asked Questions

1. How do I use FluidPage?

Read the documentation: How to use FluidPage

2. How is FluidPage different from the FLUIDTEMPLATE typoscript object?

FluidPage provides functionality that we can't figure out how to achieve using FLUIDTEMPLATE:

• First, the extension adds the backend layout selector fields to the rootline, which doesn't happen in TYPO3 out of the box.
• Second, the extension determines which template to use (similar to how TemplaVoila works) by walking up the rootline and looking at the value of those fields on page records. This template selection process is not present in FLUIDTEMPLATE and, IMO, would be difficult or impossible to achieve with pure typoscript.
• Third, the extension extracts the contents of the body tag from the HTML template before passing it to FLUID. This is important because it makes it easier for there to be a clear separation of roles (one person can develop a fully valid HTML template, and another person can implement it in TYPO3). If try to use a FLUIDTEMPLATE for a page, that template will not be a full HTML document, as in most cases the contents of head need to be generated from TYPO3 and Typoscript.

Now, that said, we'd still like to rely on core functionality as much as possible in FluidTemplate, and we're looking into whether it's viable to utilize FLUIDTEMPATE for the actual rendering of the template, with some pre-processing in the extension.

3. What's your problem, bagging on TemplaVoila?

Look, we don't mean to criticize TemplaVoila. TemplaVoila has been around for years and it's a great extension; if it's working for you, fantastic! It didn't work for us after years of use, however, for a few key reasons:

• First, while it is possible to set colPos on templaVoila content areas, we found that it was easy to forget and in many cases we ended up in cases where the relationship between content record and page was only stored in XML and difficult to get at in extensions that needed to report on where content was being used.
• Second, it's hard to fit TemplaVoila into our workflow, because a lot of important configuration is stored in the database instead of the filesystem. Until recently data structures and template objects were all in the DB, which meant that configuration could not be tracked in version control. Now you can store these things as files, but last I checked it was experimental. Moreover, the mapping itself is still not something we can track in version control, and that makes it hard for us to keep our environments in sync.
• Third, TemplaVoila has its own UI and that UI doesn't always feel like it's entirely in sync with the backend UI in general; sure, this may be a minor complaint, but that was our sense.
• Fourth, we find it time consuming to have to remap templates even when there are small changes to HTML templates that don't affect the structure of the template and its mapping.

We don't mean for our criticism to diminish anyone's work. However, rather than try to contribute to TemplaVoila, we think that something as fundamental to what TYPO3 does as the page module and how templates are handled should be in the core, not the work of an extension. That is why we aim to keep FluidTemplate as lightweight as possible. That's why our goal here is to use core functionality (backend layouts, fluid, and typoscript) as much as possible. TemplaVoila is great and while we have a critique of it, we don't mean for that critique to take away from anyone's hard work!