Bug #16871
closedUmlauts error in AJAX Pagetree (4.1beta3)
Added by Steffen Gebert almost 18 years ago. Updated over 17 years ago.
0%
Description
There seems to be an encoding problem in the new AJAX pagetree: Every via AJAX loaded subtree has an error symbol (? in FF, Box in Opera) instead of an umlaut (ä,ö,ü).
When the pagetree page is completely loaded all umlauts are correct.
(issue imported from #M4814)
Files
0004814.png (11 KB) 0004814.png | Administrator Admin, 2007-01-21 12:42 | ||
0004814.patch (1.29 KB) 0004814.patch | Administrator Admin, 2007-01-21 15:16 | ||
0004814_2.patch (12 KB) 0004814_2.patch | Administrator Admin, 2007-01-22 09:32 |
Updated by Oliver Hader almost 18 years ago
I can confirm this. See the attached image. The highlighted page-name should be "Übungsleiter". There is an error on character encoding for the AJAX response.
Updated by Oliver Hader almost 18 years ago
Please see the attached file 0004814.patch which should solve the problem.
Updated by Martin Kutschker almost 18 years ago
Don't use utf8_encode. TYPO3 has an API for that kind of stuff (quoted from memory):
$LANG->csConv->utf8_encode($string)
In doubt see lang.php and class.t3lib_cs.php
Updated by Michael Stucki almost 18 years ago
In fact, you should call it with $GLOBALS['LANG']->charSet as 2nd attribute.
$GLOBALS['LANG']->csConvObj->utf8_encode($this->content,$GLOBALS['LANG']->charSet);
See similar case in alt_clickmenu.php, function printContent().
Updated by Benni Mack almost 18 years ago
hey oliver. Thanks for the patch. Just found out the problem by myself. :-)
a) Thanks for the backpath - stuff. I forgot that while coding.
b) The same procedure has to be done in the alt_file_navframe.php
c) Also use Stucki's recommendation with the csConv.
Once the changes are in the new patch, we're good to go to get this in SVN!
Updated by Oliver Hader almost 18 years ago
Please see 0004814_2.patch
What have I done:
1) Added a conversion to utf-8, dependent to the existing encoding, as suggested by Masi
2) Added header that is set to 'Content-type: text/html; charset=utf-8' - before mimemagic determined these settings, now it's told what to do
3) Wrapped $this->doc function calls and instances in an if-statement - it's not necessary to create an instance of template, set variables etc. if they are not used on an AJAX call
What do you think?
Updated by Benni Mack almost 18 years ago
hey oliver. looks very good. But haven't used it yet. I'm gonna patch my 4.1beta3 with it tomorrow morning and get back to you ASAP, so you can send it to the core list. sorry for the delay.
Updated by Benni Mack almost 18 years ago
Hey Oliver,
one other thing that came to my mind while recoding the tree with prototype would be that we would instantiate the prototype library only ONCE per call.
Otherwise if somebody would like to include some other features AND the tree.js and it both loads the prototype library, it's not that nice. That's why I got this idea:
let's create a function in template.php with the singleton pattern and a static variable:
----
function includePrototypeLibrary() {
static $included = false;
if (!$included) {
$included = true;
$this->JScode .= '<script type="text/javascript" src="'.$this->backPath.'prototype.js"></script>';
}
}
----
Maybe we could add that small change too within the cleanup. The nice thing is that it makes it easier other developers to use this library without them having to think about what else is used on this page. Should we open another issue for this?
Updated by Oliver Hader almost 18 years ago
Hi Benjamin,
good idea with adding a includePrototypeLibrary(). But I would add this into t3lib_div or some other common library. It is possible the extension developers want to use prototype.js in Frontend as well - template.php is for Backend only.
To avoid including the javascript framework more than once, I'd suggest to set a global variable like $GLOBALS['JSincluded']['prototype']=true so that even other moduels (no matter of FE or BE) know, that this was already included.
What do you think?
Updated by Benni Mack almost 18 years ago
sounds great. Would you make a patch for this?
Btw: Should we discuss this on the dev-list where to put the library? Most of the people will suggest "well, then make an extension out of it" ;-).
Updated by Benni Mack almost 18 years ago
Actually. Let's open up a new issue for this because then the umlaut bugfix can go into the core-list right away. Patch "0004814_2.patch" works fine!
Updated by Oliver Hader almost 18 years ago
The further discussion on including/libs/etc. can be found at bug #16900.
Updated by Oliver Hader almost 18 years ago
Committed to Trunk.
(only 0004814_2.patch, no additionals)