DeutschEnglish

Submenu

- - - By CrazyStat - - -

15. November 2016

Typo3 Mask – Javascript and CSS includes of extensions missing

Filed under: JavaScript,Typo3 — Tags: , , , , , , — Christopher Kramer @ 11:36

I was using Mask 2.1.1 with Typo3 7.6.11 for a site as described in the Mask manual with this typoscript:

page < temp.mask.page
page.10.file.stdWrap.cObject.default.value = fileadmin/templates/index.html
page {
        includeCSS.styles = fileadmin/templates/style.css
}

The problem with this was that the CSS and JS files includes from extensions where missing, even though the static templates of this where included. The reason is that this typoscript overwrites the page.include* stuff defined by the templates.

A workaround

To solve this, I copied the page.include* stuff defined by the extensions in a temporary variable and restored it after loading the mask object into page:

tempJSFooterlibs < page.includeJSFooterlibs
tempJSFooter < page.includeJSFooter
tempCSS < page.includeCSS

page < temp.mask.page
page.10.file.stdWrap.cObject.default.value = fileadmin/templates/index.html
page {
        includeJSFooterlibs < tempJSFooterlibs
        includeJSFooter < tempJSFooter
        includeCSS < tempCSS

        includeCSS.styles = fileadmin/templates/style.css
}

There are more includes you might need to consider if your extensions use these:

page.includeJS
page.includeJSlibs
page.jsInline
page.jsFooterInline

Hope this helps someone with the same problem! Please let me know if there is an easier solution.

Update 06.07.2017: The clean way

So the workaround described above works, but it has a disadvantage: You might install a plugin that defines some other page.* property that gets lost. For example, I just had this problem with mindshape_cookie_hint: It defines page.9877 which gets lost when you overwrite page with temp.mask.page. It took quite some time until I found the reason for this problem. And then I found another way which is much simpler than the one described before:

page = PAGE
page.10 < temp.mask.page.10

Just don’t copy the whole temp.mask.page, only temp.mask.page.10. This will preserve all the stuff defined by plugins. The solution is so simple and easy!

So I think this is not really a bug in mask, it is rather a mistake in the documentation.

Please let me know in the comments if this saved your day or if you have suggestions.

Recommendation

Try my Open Source PHP visitor analytics script CrazyStat.

9. October 2013

Typo3 ts_lastupdate: Change Text

Filed under: Typo3 — Tags: , , , — Christopher Kramer @ 12:38

The Typo3 extension ts_lastupdate comes in handy when you want to automatically display the date when the page has been edited the last time. On a German Typo3 installation, what it displays looks like this:

Letzte Änderung: 09.10.2013

You can configure the date format as described in the documentation. But what I missed was a way to configure the text before the date. I wanted it to say “Letzte Aktualisierung” instead of “Letzte Änderung”. The solution I came up with might be a bit quick and dirty but it surely does the trick:

plugin.tx_tslastupdate_pi1.text.wrap =  <!--|-->Letzte Aktualisierung:

So what I do is wrap the text provided by the extension (or rather language file) in comments and place my text afterwards. If you have multiple languages, you might need to use language conditions.

[globalVar = GP:L = 2]
plugin.tx_tslastupdate_pi1.text.wrap =  <!--|-->Letzte Aktualisierung: 
[globalVar = GP:L = 3]
plugin.tx_tslastupdate_pi1.text.wrap =  <!--|-->Last update: 
[global]

If anybody finds a cleaner solution, please let me know.

12. January 2012

Typo3: Mailform charset problems after upgrade

Filed under: Typo3 — Tags: , , , , , , , — Christopher Kramer @ 14:22

After upgrading Typo3 from 4.1.6 all the way to 4.5.10, mails sent through the default Typo3 mailforms were messed up because the charset was wrong. The charset of the page was ISO-8859-1 consistently everywhere, but the Typo3 mailform expected input to be in UTF-8 and sent the mails as UTF-8 although the browser sent the data  encoded in ISO-8859-1.

After lots of things I tried, the following TypoScript fixed the problem. You simply put it into the TS of the Template.

page.config.formMailCharset= iso-8859-1

Of course you can put another charset in there if you have a similar problem with another charset.

It took me so long to find this out as the Typo3 code editor did not know the setting and it was not documented anywhere I looked at.

Maybe this helps somebody…