Bug #49196
closed
includeLibs messes up head/body
0%
Description
When using includeLibs, wether it is the example from http://docs.typo3.org/TYPO3/TyposcriptReference/ContentObjects/UserAndUserInt/Index.html or my own, messes up the head.
In all my 6.1 installations, even a rather blank one (no extra extensions loaded).
The first time I noticed was using 6.0.4.
When you look in the source, there is nothing wrong, but looking with Chrome "inspect element", I see this:
<html dir="ltr" lang="nl-NL"><head></head><body>
<meta charset="utf-8">
<base href="http://.../">
etcetera...
All what needs to be in the head is parsed into the body. Also the W3C validator complains about it.
I've been busy for days to find the cause but I have not enough knowledge to see what's going on.
It seems a severe issue to me.
Updated by Chris topher over 11 years ago
- Status changed from New to Needs Feedback
Hi Vincent,
can you post the TypoScript (maybe only the relevant parts), which you are using for the includeLibs (and the USER_INT object, if any)?
Does the php file, which you include, produce any direct output?
Updated by Vincent Mans over 11 years ago
Hi, I have two:
1) One from the book, like I mentioned, to test if includeLibs from the book works.
includeLibs.listRecords = fileadmin/example_listRecords.php
page.30 = USER
page.30 {
userFunc = user_various->listContentRecordsOnPage
reverseOrder = 1
debugOutput = 1
}
2) And one like this in another 6.1 installation:
plugin.tx_powermail.settings.setup {
dbEntry {
tt_news.tx_newscalendar_calendardate = TEXT
tt_news.tx_newscalendar_calendardate.field = datum
tt_news.tx_newscalendar_calendardate.postUserFunc = user_convertToUNIXTimestamp->main
}
}
The php as it worked:
class user_convertToUNIXTimestamp {
var $cObj;
function main($content,$conf){
$content=strtotime($content);
return $content;
}
}
?>I think it worked well before 6.0.4, at least, the functions gave the correct result.
Updated by Chris topher over 11 years ago
I have just tested your example 1) with the class class user_various from here.
With this TypoScript template
includeLibs.listRecords = fileadmin/example_listRecords.php
page = PAGE
page.30 = USER
page.30 {
userFunc = user_various->listContentRecordsOnPage
reverseOrder = 1
debugOutput = 1
}
I get the correct output in TYPO3 6.0.6. The head content is in the head and the output of the script is displayed inside the body tags.
Try stripping your TypoScript template down to see, if there is a setting, which makes it break for you.
Maybe this is a bug in Chrome, which for some reason displays you false-information?
Updated by Vincent Mans over 11 years ago
I've been stripping the whole setup for days now, and it leaves me with ... includeLibs as the only issue!
Chrome complains, W3C complains as well, with includeLibs in the setup:
Line 1, Column 2: Non-space characters found without seeing a doctype first. Expected <!DOCTYPE html>.
<!DOCTYPE html>and after that nothing useful anymore.
Firefox latest complains too.
Again, the html5 source itself looks good.
Who eats my head???
Updated by Chris topher over 11 years ago
Vincent Mans wrote:
Chrome complains, W3C complains as well, with includeLibs in the setup:
So not browser-dependent...
Line 1, Column 2: Non-space characters found without seeing a doctype first. Expected <!DOCTYPE html>.
So the page misses a doctype at the very beginning.
Again, the html5 source itself looks good.
Except that the head tag is closed immediately, I guess.
What do you get, when you use the TypoScript template from my previous post and comment the line starting with includeLibs.listRecords?
Is the head tag still closed immediately?
Updated by Vincent Mans over 11 years ago
It misses a doctype indeed, but ONLY when using the Element inspector (or W3C Validator). If I do a View pagesource, it looks good!!
So I was thinking some javascript might be in effect, but that's not the case. It is just an issue with includeLibs activated.
If I comment that line, includeLibs, then there is no problem at all.
Updated by Vincent Mans over 11 years ago
Now I have stripped everthing that can be stripped. No javascript or css included, just rendered html5. The same problem remains.
Even in this case with only this TS setup, root template, the head and body is mixed up when using includeLibs:
page = PAGE
includeLibs.listRecords = fileadmin/example_listRecords.php
page.30 = USER
page.30 {
userFunc = user_various->listContentRecordsOnPage
reverseOrder = 1
debugOutput = 1
}
Updated by Alexander Opitz over 11 years ago
Cannot reproduce this with 6.2-dev using same method like Christopher.
So maybe your root template, did it happen if you are logged into backend or not, which extensions are installed/active?
Updated by Vincent Mans over 11 years ago
In the latest case, I had all extensions removed.
The include shows the PHP code, it does not run the functions.
Tried several caching on/off via php_flag in .htaccess, without result.
The only thing I see is that when I refresh the page from my latest example, containing no content elements, gives a valid empty page after page refresh.
It must be some caching mechanism and/or other settings on the server I suppose?? Any ideas?
Updated by Vincent Mans over 11 years ago
Are you all sure that you used the Inspect element in Firebug or Chrome? Because the html looks good via source code view.
In the completely stripped version, it still goes wrong. No .htaccess in effect. This is the situation:
Being logged in makes a difference, and being the very first viewer does!!!
- BE logged in in Chrome > empty all cache > watch in FF > head/body mixed up, script runs > FF page refresh > head/body okay, script not running (script is just php echo)
- now looking with another browser, not being logged in: head/body okay, script not running
- during being logged in, head/body mixed up, script runs, all the time also after refresh
This is the current TS, no extensions installed:
page = PAGE
includeLibs.listRecords = /typo3conf/ext/example_listRecords.php
page.10 = USER
page.10 {
userFunc = user_various->listContentRecordsOnPage
}
Using the "inspect element" (NOT THE PAGE SOURCE ITSELF!!!) gives me this:
<html lang="en"> <head></head> <body> hallo!!!!!!!! <meta charset="utf-8"> <title>Home</title> <meta content="TYPO3 6.1 CMS" name="generator"> <link media="all" href="typo3temp/stylesheet_8b9c2e8d89.css?1371494258" type="text/css" rel="stylesheet"> </body> </html>
We (my server admin) tested several server/php caching settings without any difference.
Updated by Vincent Mans over 11 years ago
Issue seems solved, didn't test it in the real setting (only in small test):
BOM! My included PHP script was UTF-8 BOM. All the time I was looking in the wrong direction. Saving it as UTF-8 NO BOM solved it (or putting it in a completely blank new file).
Solution came from here, and you can find many details on Stackoverflow:
http://wordpress.org/support/topic/head-scriptslinks-showing-up-inside-body-tag (last contribution)
There are a few options to test this, from commandline:
#curl http://www.domain.tld | xxd
or see what files are BOM material:
#grep -orHbm1 "^`echo -ne '\xef\xbb\xbf'`" . | sed '/:0:/!d;s/:0:.*//'
Well, my time on this issue is a really bad score, for most victims it took only half a day. I hope someone else can use this info.
It's not a TYPO3 bug, and it's no feature either, that's for sure.
Updated by Alexander Opitz over 11 years ago
- Status changed from Needs Feedback to Closed