CMS Made Simple Forums

Hello everyone,

we talked about this a while ago here:

http://dev.cmsmadesimple.org/bug/view?id=3920

It isn't too bad an issue so I left it at that point since I didn't have the time, but now I thought I'd further investigate it.

In short, the problem is this:

Whenever changes are made to any page in my cmsms installation, the FIRST output of any page when pulled in a browser is different from any further output.

As an example, after any changes made, the FIRST time accessed the page looks like this (example page, refresh won't work here):
http://www.prostore-mainz.de/files/bug/kontakt.htm

the second and any further time accessed it looks like this.
http://www.prostore-mainz.de/files/bug/kontakt_1.htm

The second one is the correct output, notice the different position of the header graphic ("teaser") on the top right.

I will also attach screenshots showing the difference as viewed in my browser, as viewed in notepad++ and as viewed in a hex editor.


Does anyone have any idea where this oddity might result from? The teaser graphic is a oneline=true wysiwyg=off content block.
I can't spot anything in the template, and it would be odd if I could, because then it should appear every time I access the page, not just the first time after a change, right?

Here are the pictures:

website as viewed in my browsers (first time access after a change):
http://www.prostore-mainz.de/files/bug/odd.png

website as viewed in my browsers (second and any further access or page refresh):
http://www.prostore-mainz.de/files/bug/normal.png

website in notepad++ (first time access, difference to second time access highlighted):
http://www.prostore-mainz.de/files/bug/np-odd.png

website in notepad++ (second and any further access):
http://www.prostore-mainz.de/files/bug/np-normal.png

(and yes, once the highlighted character is removed (even manually) the page displays correctly.

website in hex edit (first time access, highlighted)
http://www.prostore-mainz.de/files/bug/hex_odd.png

website in hex edit (second and any further access)
http://www.prostore-mainz.de/files/bug/hex-normal.png


Thanks so much!

Max

Oh I forgot, CMSMS version is 1.7.1 as of today, still the same problem though.

Oh and this is what the important bit of the template looks like:



{content block="teaser" wysiwyg="false" oneline="true"}

appears it might be browser related.. cannot reproduce on ie8; can on firefox 3.6.3 (but not with absolute consistency).

you could try using smarty's strip to help troubleshoot or come up with a workable fix.

Thanks for your reply. This is true for me too, Opera does show the layout correctly everytime it seems.
But I reckon this just means that opera (and IE8 for that matter) "Ignore" that weird character, that is visible in notepad++ and the hex editor.

It's still weird that this additional character is there, and after a refresh of the cmsms powered site (the examples I posted are static html) disappears....

Max1 wrote:"Ignore" that weird character, that is visible in notepad++ and the hex editor.

is that mysterious character truly a 'space' (0x20)?

Don't think so actually , the hex editor says it's 0xEF 0xBB 0xBF , notepad++ displays it as a dot at the top end of the line, it's not symboling a space in that case. Haven't found any other editor that would display it. If I copy paste it into something (from notepad++) it normally just displays the empty rectangle you get with unknown characters....

Was the content typed entirely in the admin panel?  Or copied out of another program?

Maybe apps add a Unicode encoding thing (called a BOM) at the top of their files in order to say it's Unicode.  Unfortunately, it's not consisten in it's handling at all to the point that some things totally ignore it and some don't.

None of the WYSIWYGs do it, but plenty of text editors do.  See: http://www.stanford.edu/~laurik/fsmbook/errata/BOM.html

Ted wrote: Was the content typed entirely in the admin panel?  Or copied out of another program?

Maybe apps add a Unicode encoding thing (called a BOM) at the top of their files in order to say it's Unicode.  Unfortunately, it's not consisten in it's handling at all to the point that some things totally ignore it and some don't.

None of the WYSIWYGs do it, but plenty of text editors do.  See: http://www.stanford.edu/~laurik/fsmbook/errata/BOM.html

yup.. i suppose it never occurred to OP to google those hex values (0xEF 0xBB 0xBF)?

___

bob: so, tell us johnny.. what does our lucky winner get today?

johnny: how about a beautiful european vacation? all...

bob & ted together: sounds great!

johnny: ...expenses to be paid by our 'lucky' winner!  

(have a good time, but not tooooo good a time. )

shit I should've recognised this... my apologies, I only looked into it in a hex editor today, and indeed didn't google the hex codes....

I'll try and find out whether the BOM is in the template or the content, I typed the template in gedit and copy pasted it, I'm not responsible for the content so beats me where that was copy pasted from...

Thanks you guys for shedding some light on this, while granted, I should've easily figured it out myself...

Edit: Oh and, I dunno if that matters anyway, but is it worth looking into why the BOM only appears when first loading the page after clearing the cache (making a change) and doesn't afterwards?

The first time it is displayed as it is stored in the db.
The second time it is displayed from the cache.
Maybe smarty removes BOMs when creating the cached file?

NaN wrote: Maybe smarty removes BOMs when creating the cached file?

Yeah, that would be my guess too.  PHP's handling to BOM's is also varied, so it might be possible that since it's now at the top of an included cache file instead of a field in a database, it's throwing it away.

Ok great, thanks so much you guys

Sorry to bug you again, I was hoping maybe one of you had another tip on how to find the hiding BOM.

I removed the content block that the BOM was in from one of the templates, and after purging the cache the BOM is still there (at a slightly different position), so I assumed the BOM has to me somewhere in the template. Only I can't find it.

I checked the template on my computer with a hex editor, no BOM there. I copied the template from the admin menu onto my computer, checked it with a hex, no BOM, then nulled the content of the template in phpmyadmin and pasted the (checked, no BOMs) template again into the admin menu. saved, same BOM, same place.

Any other idea on how I might handle this? When I access a template in the admin menu, there's definitely no BOM (page viewed in iso charset, page saved and checke with hex editor), but that might just be cuz PHP strips it. But the same goes if I view the template content in phpmyadmin.

Then again, if I don't see the BOM in the admin menu (even if php strips it), and then save the template, shouldn't the BOM be gone even if it was there at first and PHP stripped it?

Cheers so much!

Max

Edit: Oh also I checked the cmsms installation for BOMs (maybe I edited a file or something), nothing apart from 3 language files in ./lib/filemanager/imagemanager and in ./modules/FCKEditorX and ./modules/TrueTypeText...

FML I don't believe it.

I uninstalled the module TrueTypeText, and the BOM is gone... just gone! I hadn't even used the plugin oO