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.

16. March 2016

Typo3: Redirect backend to https and frontend to http

Filed under: PHP,Security,Server Administration,Typo3 — Tags: , , , , , , , , , — Christopher Kramer @ 20:02

If you are using SNI to secure the access to your site through SSL, you might decide that you do not want to use SSL for the frontend, as users of old clients such as Android 2 or Internet Explorer 8 on Windows XP won’t be able to access the site. But for the backend, old clients should not be a problem.

So this solves the redirection in two ways:

  1. Frontend gets redirected to HTTP if accessed through https (optional)
  2. Backend gets redirected to HTTPS if accessed through http

Put this in your .htaccess after “RewriteEngine On” (assuming Apache webserver):

# 1. optionally: redirect FE to http
RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_URI} !^/?typo3
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# 2. redirect BE to https
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} ^/?typo3
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

And hopefully, your backend access is now securely encrypted…

https

 

4. May 2015

Typo3 6.2 and Crawler Failed opening required ‘PATH_t3libclass.t3lib_page.php’

Filed under: Typo3 — Tags: , , , , , , — Christopher Kramer @ 11:28

Typo3 6.2 with the current version of the crawler from TER (3.5) gives this error when executed by the planner from cron:

PHP Fatal error:  require_once(): Failed opening required 'PATH_t3libclass.t3lib_page.php' (include_path='[...]') in [...]typo3conf/ext/crawler/class.tx_crawler_lib.php on line 30

Or if you open the crawler module in the Info-Module, you get only a blank screen and these errors in the log:

PHP Fatal error:  require_once(): Failed opening required 'PATH_t3libclass.t3lib_pagetree.php' (include_path='[...]') in [...]typo3conf/ext/crawler/modfunc1/class.tx_crawler_modfunc1.php on line 30, referer: http://[...]/typo3/mod.php?M=web_info&moduleToken=[...]

PHP Fatal error:  require_once(): Failed opening required 'PATH_t3libclass.t3lib_pagetree.php' (include_path='[...]') in [...]/typo3conf/ext/crawler/modfunc1/class.tx_crawler_modfunc1.php on line 30, referer: http://[...]/typo3/backend.php

I found a bug report for this exists in the crawler bugtracker for over a year now. And the current crawler version 3.6.2 also fixes the problem, but for some reason is not in the TER yet. So to solve the problem:

Download crawler version 3.6.2 and replace “/typo3conf/ext/crawler/” with the contents of this archive.

Hope this helps somebody solving the issue faster.

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.

9. June 2012

Typo3 and other charsets than UTF-8 (latin1 / ISO-8859-1, …)

Filed under: PHP,Server Administration,Typo3 — Tags: , , , , , , , — Christopher Kramer @ 12:30

When updating a Typo3 installation to Typo3 4.5.x, I had problems with charsets and explained the solution here.

Now updating an installation of Typo3 to 4.6.x, I ran into another charset problem: The backend now was completely UTF-8 and therefore, changing texts in the backend caused them to be stored as UTF-8. As the frontend was still ISO-8859-1, special characters (Umlaute) over there got messed up. Maybe there is a way out of this as well ($TYPO3_CONF_VARS['BE']['forceCharset'] I guess), but this clearly shows that Typo3-developers drop support for other charsets slowly and that it might be easier to switch to UTF-8.

In the release notes of Typo3 4.5, I found the following passage:

UTF8 by default: New installations will use UTF8 automatically. Keep in mind that we will be deprecating all other charsets in the release of 4.5, but still support those charsets. 4.7 or maybe even 4.6 will be the first “UTF-8 only” release. When upgrading from older releases to 4.5, you will have to specifically set $TYPO3_CONF_VARS['BE']['forceCharset'] and $TYPO3_CONF_VARS['BE']['setDBinit'] in your localconf.php. An Upgrade Wizard will help you with that.

In the release notes of Typo3 4.6, I could not find a word about UTF-8, but in the release notes of 4.7, it is clearly stated:

check you database if it is utf-8 encoded – TYPO3 4.7 only will work with utf-8.
[…]
The forceCharset option has been deprecated in version 4.5. UTF-8 is now enforced. Even though other values than “utf-8” have not been possible anymore for some time, the option’s value has been queried at plenty of places within the whole core. These references, the option in the Install Tool, as well as many defaults with charset “iso-8859-1” in several classes have been changed, so TYPO3 now works UTF-8-only internally.

So it is clearly time to make the switch.

It is not that complicated – everything is described very well over here.

As the official wiki is very long and explains lots of stuff you might just not care, here are the basic steps:

  • Backup Database and Files
  • Set the charset in your webserver (e.g. “AddDefaultCharset utf-8” in a .htaccess)
  • Adjust some settings in localconf.php:
    // For backend charset
     $TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
     $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;'; 
    
     // For GIFBUILDER support
     // Set it to 'iconv' or 'mbstring'
     $TYPO3_CONF_VARS['SYS']['t3lib_cs_convMethod'] = 'mbstring';
     // For 'iconv' support you need at least PHP 5.
     $TYPO3_CONF_VARS['SYS']['t3lib_cs_utils'] = 'mbstring';
  • Adjust your typoScript (change language to your needs):
    config.locale_all = de_DE.utf-8
  • Convert your templatefiles to UTF-8 (and remap them if you use TemplaVoila) – usually in fileadmin/templates
  • Convert your DB to UTF-8
    1. Backup it first if you have not yet (believe me!)
    2. Paste this tool into fileadmin
    3. Run it by opening it in the browser (http://example.com/fileadmin/db_utf8_fix.php)
    4. If everything says “OK”, change the constant “SIMULATE” to false
    5. Run it again
    6. Clean cache of Typo3
    7. Check your site (esp. special characters). If the content is messed up or parts are missing, do the following:
      1. Restore the backup of the database (yes, I told you!)
      2. Uncomment lines 108 – 123 in db_utf8_fix.php
      3. Run it in browser againClean cache in Typo3
    8. Clean all cache in Typo3 Backend

You can find more detailed information here. There are also lots of other ways described how to convert the database.

Happy converting!

 

Update 2014-05-05: Changed link to db_utf8_fix-script as the original site is reported to be attacked and does not host the script anymore. I cannot check if the script at snipplr is exactly the same, but it looks so.

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…