Empty Text Added Immediately After Body Tag Ruins Layout

Permalink
Attempting my first conversion of HTML/CSS/JS static site to a C5 deployment.
Going ok in principal, but several lines of empty text are added dynamically straight after the BODY tag and this is messing up my layout.
I assume this is the empty container for the editing bar. Any code snippets on how to:
a) prevent the empty string/text being added when not logged in
b) manage the positioning / insertion of the legitimate editing bar when it is enabled after logging in?
Apologies if this is a trivial question, but after getting this close after 6 hours of playing my mind has stopped working...

GavMurphy
View Replies: View Best Answer
TheRealSean replied on at Permalink Reply
TheRealSean
without seeing your code, Im guessing but check your header in your elements folder or your page type page (ie view/default)

Its possible that you have your extra content in there.

The other option could be the use of a block which is including this content, is there any chance you could post the code section where the text is output?
GavMurphy replied on at Permalink Reply 1 Attachment
GavMurphy
Thanks for the swift reply, Seanom.

Attached the files to date - this is still a work in progress...

There is nothing but straight HTML between the body tag and the wrapper div, and even if there was in terms of the file, this would be white space and ignored. However, using Fireug or Chrome's dev tool, when viewing the rendered source instead of actual source, I have a " " section split across about 4 or 5 line breaks that when I remove the block of 'text' using Firebug or the Dev Tool, the page renders correctly.

The static site that I'm working towards building in C5 can be seen athttp://www.volare.net.nz

As a complete aside, I'd be keen to know how I stop the standard utf-8 http-equiv definition coming from C5, or at least change it so that it is correctly HTML5 compliant...
TheRealSean replied on at Permalink Reply
TheRealSean
Try moving the Loader::element('header_required') to just before the closing header tag,

the space being added is the space where the tool bar goes.

<?php Loader::element('header_required'); ?>
<?php echo Config::get('SITE_TRACKING_CODE'); ?>
</head>


Give that a go, it seemed to work for me.

Im not to sure about the HTML5 bit though Im afraid not quite moved over to that yet
GavMurphy replied on at Permalink Reply 1 Attachment
GavMurphy
Sorry Seanom, didn't work.

It appears that the concrete5 output is putting all of the stuff that should be in the <head> section, in the <body>.

I've attached a screen grab of firebug showing both the head-tags in the body area, and the blank line being dynamically added immediately after the <body> that if I delete fixes the shift down of the upper page content (seen by the incorrectly positioned Volare logo in the upper section of the page).

It's not the space needed for the editing bar as this works correctly when logged in, but whether the editing bar is there or not, this blank text line is dynamically added and the elements in the page are all shifted down unless I remove it using Firebug after page load.

So 2 strange things:
1) This adding of empty string dynamically that is pushing the inline html down
2) The removal of all of the elements from the <head> and dynamically adding them to the start of the <body>

This is very odd....

Gav
Shotster replied on at Permalink Best Answer Reply 1 Attachment
Shotster
Hi Gavin,

I took a look at your files, and it turns out the problem was...are you ready?

GREMLINS!

Actually, I'm pretty sure it was just one gremlin in the footer.php file, but I cleaned all the files to be sure. I've attached the clean files.

Also, seanom is correct that the header_required stuff should come just before the closing </head> tag. And lastly, there were two <title> tags, which results in a validation error. C5 outputs a <title> tag in the "elements/header_required.php" file, so there's no need to add one to your theme's header.php file.

Hope that helps,

-Steve
Shotster replied on at Permalink Reply
Shotster
It occurred to me that what I mean by "gremlins" might not be understood by everyone. I'm referring to non-printable non-ASCII "funk-a-delic" characters that somehow find their way into a text document. It happens on rare occasion. They are invisible in most text editors and can cause bewildering problems because they can confuse parsers and might even "appear" in some contexts to be normal white space characters, but in fact, they are not.

It's amazing the havoc a few stray bits can wreak!

Anyway, just thought I'd clarify for others who might stumble upon this thread.

-Steve
GavMurphy replied on at Permalink Reply
GavMurphy
Sorry Shotster, but it hasn't addressed the issue.

It seems to be linked to my other problem of the whole of the Head section being dynamically added to the start of the Body section.

There is no white space or non-printable characters other than the tabs and returns I expect to see when viewing the hidden characters through notepad++

Thanks for the suggestions, very much appreciated.

Cheers,

Gav
Shotster replied on at Permalink Reply
Shotster
> Sorry Shotster, but it hasn't addressed the issue.

You tried the files I attached? I saw exactly what you were seeing, and zapping the gremlin fixed the layout issue. That "white space" you were deleting in Firefox was the gremlin. I'm absolutely positively 100% almost certain that's the problem with your layout.

> It seems to be linked to my other problem of the whole of the Head
> section being dynamically added to the start of the Body section.

No, that's a symptom. The problem is the gremlin causing the bogus layout. It's causing the HTML parser to flake out.

> There is no white space or non-printable characters other than the tabs and
> returns I expect to see when viewing the hidden characters through notepad++

There is in the files you attached to your message. After I zapped the gremlin, the layout issue was solved, and there was no more "white space" after the body tag in Firebug.

-Steve
Shotster replied on at Permalink Reply
Shotster
> There is no white space or non-printable characters other than the tabs and
> returns I expect to see when viewing the hidden characters through notepad++

Some text editors won't show them.

I would suggest simply dropping the entire theme I attached to my message into your themes folder and see if the problem persists. Don't open or save the files - just drop the folder in wholesale. You can temporarily rename your original folder.

Also, be sure to DISABLE AND CLEAR THE C5 CACHE if you're using it. It should be disabled for development. Let me know how it goes.

As I said, I saw EXACTLY what you described, and zapping the gremlin cured it.

-Steve
GavMurphy replied on at Permalink Reply
GavMurphy
Hey Shotster, had to leave my PC, but will try what you suggested in a few hours and get back to you. Man, I hope this is the issue, as I'm starting to give up on my first foray into C5...fingers crossed.
GavMurphy replied on at Permalink Reply
GavMurphy
Shotster, you're absolutely right - that did fix it.

I've been using Notepad++ for years doing simple web sites and never come across this before - thank you so very much. Really appreciated.

The invisible lines still don't show in Notepad++, but when I run your header.php and my header.php against winmerge the extra block of empty characters was there!

I'm wondering if it is because my editing mode in Notepad++ is set to UTF8 and not ASCII? Anyway...thank you again - very impressed.

Cheers,

Gav
Shotster replied on at Permalink Reply
Shotster
Glad you got it solved! Those kinds of problems can certainly send one barking up the wrong tree.

:-/

Regards,

-Steve