from TemplaVoila! to Fluidtemplates

TYPO3 – easy change from TemplaVoila! to Fluidtemplates

A small step for a coder – a big step for the upgrading possibilities of your website!

TemplaVoila! is outdated long time ago, but still around in some TYPO3 installations. A shift to Fluidtemplates, in combination with Backend-Layouts, seems to be a big hassle, but is indeed not so complicated since the principles are pretty much the same. In both cases we map a content form a backend column into a certain area of a predefined html-template.

How to do it

a. first step

First we must find out which elements in our main template are mapped with TemplaVoila!, therefor we need the extension (including Static-Info-Tables) still in action, before we disable it. Important is, whether it is an „inner“ or an „outer“ mapping. With „inner“ we just replace the inside of the html element with a viewhelper and a variable. If it is an „outer“ mapping, we have to replace the the whole html-element as such with the viewhelper. Example of an „inner“ mapping:
<div id="myMapID"><f:format.raw>{variableLaterInTypoScript}</f:format.raw></div>

 

templa voila to fuid templates
the path to the mapping – click on (in may case) „ik_TemplaVoila“

 

templa voila to fluid
„Modify DS /TO“
mouse over element mapping
the mapping – mouse over the html-elements shows their ID-number

 

templa voila to fluid mouse over
mouse over shows the ID of the element („#headline“)

Next you write down a list of the names of the columns („pageHeaderHeadline, banner …“) and the corresponding element names and Ids. The columns names you then use to create a backend layout with the same name, numbering from „0“ left to the accordant last number on the right. Check your old columns, because not all of the mapped IDs are coming from a column in the backend, some are replaced by „lib“ or „temp“ TypoScript variables. So just create the same column structure as it was with TemplaVoila! After assigning the backend layout to the root page, the first step is done.

 

b. second step – changes on the main page template

As said before, some of the „markers“ (viewhelpers) are getting their information from a TypoScript variable, like the Menu e.g.

main template fluid
main template fluid

The others are coming from the backend columns.

Now you take your list and replace the html elements on your list, with an viewhelper („<f:format.raw>{yourVariable}</f:format.raw>“). If it is a „inner mapping“ put the viewhelper inside the element.

We also have to delete everything above and including the html body tag. Don’t forget the closing tags at the end!

You have to do these steps very careful, because getting into a wrong element will mess up the whole thing. Work on a copy of the template file!.

 

c. third step – TypoScript in the root of the website

10 = FLUIDTEMPLATE
10 {
     template = FILE
     file = fileadmin/zazu/default/templates/zazu_template.html
     partialRootPath = fileadmin/zazu/default/templates/Partials
     layoutRootPath = fileadmin/zazu/default/templates/Layouts
        variables {
           h1TopSlogan < styles.content.get
           h1TopSlogan.select.where = colPos=0
           rubrikH < styles.content.get
           rubrikH.select.where = colPos=1
           unterNav < lib.field_unternav
           hauptNav < lib.field_hauptnav
           footerNav < lib.field_footernav
        }
  }

The TemplaVoila! TypoScript can be deleted:

 

10 = USER
10.userFunc = tx_templavoila_pi1>main_page

 

d. fourth step – move the content

This is easy to do if you work on a copy (or „Staging“ as it called by the provider Mittwald). After you deactivate the „static-info-tables“ and the „templaVoila!“ Extension, all content will be in the „main column“ now you have to move the content elements into their old order. It is no problem if you can switch between an old implementation and the new one to check what was where. Otherwise you have to find the order by yourself or memory. Anyway with such a step you should always work on a copy!

 

There are probably some extensions doing similar work in a automated process. But who wants to deal with a complicated extension for a small website. In case it is a bigger site of course one should consider to go into something more automated.

Comments and additions are welcome!

 

Autor: Thomas Hezel

DSGVO opt-in for Cookies

DSGVO = Datenschutzgrundverordnung or GDPR = General Data Protection Regulation – TYPO3 and opt-in in Cookies

According to the German hoster Mittwald there is only one TYPO3 extensions that provides a real opt-in for cookies.
Since it looks like an opt-in for cookies will be the final demand by 25th of May 2018, I checked the TYPO3 extension „cookies“ and looked how it behaved under different conditions. You can get the extension here: https://extensions.typo3.org/extension/cookies/

First of all you have to upload it into TYPO3, then add the static template and after that make your settings at the constants panel.

Don’t forget to put your starting page ID in the field „JavaScript Fallback page“ of the constants in the root template. Otherwise you get problems with cHash and the submit is not going through, so you get allways a popup, asking wether you want to sent the formular again. If you have cHash-Problems you can also try to put „$GLOBALS[‚TYPO3_CONF_VARS‘][‚FE‘][‚pageNotFoundOnCHashError‘]“ in the Install Tool Settings on „false“.

After opening your domain in the browser for the first time, there is a dialog window opening at the top of your window (cookie hint).
But checking the cookies in the browser revealed, that Google and others had already set their cookies. So, the setting of cookies via a third party JavaScript is not stopped by the extension. Only the TYPO3-cookie is not set yet.

So this is not a real opt-in!

You can, as described in the extension manual, then use a TYPO3 conditions to unload for example your Google Analytics tracking code. But the cookie that was set at the first load of the page will remain. Of course by setting the browser to block third party cookies and making browser settings to stop tracking will help. But this is then not a real opt-in for a single webpage.

My solution for a real cookie opt-in

The extension sets 2 additional cookies

a. tx_cookies_hidden
b. tx_cookies_disabled

a. This is used to track whether you have already made a choice about cookies, so the dialog will not appear again on the next subpage.
b. If you have chosen to deactivate cookies, this cookie is set to carry  along your choice, while you surf through the website.

TypoScript at the root of the website

page.5 < tt_content.list.20.cookies_main

[globalVar = _COOKIE|tx_cookies_hidden = 1]
page.headerData.1 =TEXT page.headerData.1.value (
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-xxxxxxxx-x"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'UA-xxxxxxxxx-x', {'anonymize_ip': true });
</script>
)
[global]
[globalVar = _COOKIE|tx_cookies_disabled = 1] && [globalVar = _COOKIE|tx_cookies_hidden = 1]
page.headerData.1 >
[global]

Explanation

If the cookie „tx_cookies_hidden“ exists (value „1“), then write the Google tracking code in the header. Meaning the user has clicked on „I agree“, so the cookie „tx_cookies_hidden“ was created.

If the cookie „tx_cookies_hidden“ exists and the cookie „tx_cookies_disabled“ exists, meaning the user has opted for „disable cookies“ (this could happen on the first possibility or later on), then erase what is stored in the page.headerData.1 object.

Now we have one more problem

Clicking on the „I agree“ button doesn’t provoke a reload of the page. As a result no Google tracking code is written in the header since the information only comes to action after a reload. The button „activate cookies“ or „deactivate cookies“ results in a page reload, so we only have the problem with the „I agree“ button. But if the user goes for „I agree“ no tracking code is written and no Google cookie is set before the next reload.

This can be solved with jQuery code for all pages:

//cookies
$('#tx_cookies_hide input').click(
function() {
setTimeout(
function() {
location.reload();
},
500);
});

The delay is needed, so the browser has time to write first the cookies from the extension and to set the „globalVar“ before the reload is activated.

Example where you can see it in action: https://www.implantologie-hopf.de

Addition:

To make the jQuery reload work in the iPhone and iPad world you need to put the cursor to „pointer“ for the „I agree“ button. Seems to be some „Apple-mind-bug“:

CSS:


#tx_cookies_hide input {
cursor: pointer;
}

 

UPDATE:
May 16th 2018 – Version 5.0 of the extension is available and has some changes!

a. name change from cookie „tx_cookies_hide“ to „tx_cookies_accepted“ please mind the „ed“ of „accepted“

b. id name change for the „I agree“ button to #tx_cookies_accept“, please be carefull here wie have no „ed“ but just an „…_accept“!

c. css for iPhone cursor: pointer changes id-selector

d. some action response text is added and can be set on „display: none“, or used

 

a. TS  changes to:


page.5 < tt_content.list.20.cookies_main

[globalVar = _COOKIE|tx_cookies_accepted = 1]
page.headerData.1 =TEXT page.headerData.1.value (
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-xxxxxxxx-x"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'UA-xxxxxxxxx-x', {'anonymize_ip': true });
</script>
)
[global]
[globalVar = _COOKIE|tx_cookies_disabled = 1]
page.headerData.1 >
[global]

 

b. jQuery selector for the reload with the „I agree“ button changes to:

//cookies
$('#tx_cookies_accept input').click(
function() {
setTimeout(
function() {
location.reload();
},
500);
});

 

c. CSS for the iWorld jQuery window reload bug:


#tx_cookies_accept input {
cursor: pointer;
}

d. CSS:

#tx_cookies .typo3-messages {
  display: none;
  }