Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo

problem with UTF8 files (bug?)


Go to End


2 Posts   1846 Views

Avatar
xammmax

Community Member, 1 Post

8 November 2008 at 12:11pm

hi,

i'm now working a few days with silverstripe, i love it. many thanks for this great cms!

today i run into troubles, because here in switzerland use "umlaut" characters like the ä, ö, ü. as i'm lazy too (don't like to write ä etc. all the time), i'm used to save the files in UTF8.

on the module i'm working on, i created several "core" files (.php) and..
IE wasen't able to display the styled page, only text without any images / css etc.

tracing back the problem, i could figure out the following:
if the rendered page uses two or more .php files saved as UTF8, then the problem occur. with only one .php it's working fine.
tech: for each file more then two the UTF8 BOM (byte order mark) is rendered out to the html.

the work-a-round for me, i changed all my files to iso8859-1 and now it's working as expected.

please note: the problem is only visible in IE, firefox does work with the "malformed" html.
i tried with with silverstripe 2.2.2 and the new 2.2.3, the same behavior.

(please see the attached pdf showing screenshots of the above)

best, xammmax

Avatar
Ingo

Forum Moderator, 801 Posts

29 November 2008 at 8:41pm

Hey xammmax, what HTTP Content-Type is the response given (you can find this out in Firefox Page Information for example)? Do you have any Content-Type <meta> tags? SilverStripe consistenly works with UTF-8 both in code- and database-storage, usually this doesn't make any problems (apart from specific logic like searchforms).