View Full Version : IE8 makes a mess out of my menus... :(

01-07-2011, 08:22 PM
1) Script Title: Glossy Accordion Menu

2) Script URL (on DD): http://www.dynamicdrive.com/dynamicindex17/ddaccordionmenu-glossy.htm

3) Describe problem:

the menus i put in my site: www.cannabook.net looks well in Chrome And FF but it's a mess in IE8.

how can i solve this problem ?

01-08-2011, 08:41 AM
It looks like something is forcing the page into IE 7 compatibility mode. If I force the browser to do it in IE 8 standards mode, it looks fine.

There's no compatibility meta tag on the page, so it's probably a header being sent by the server. Did you do anything like that? If not, then you'd have to ask your host if they are.

It may have to do with the directionality of the text.

See also:


01-08-2011, 09:02 AM
when i moved to site from its old domain to the new one, couple of days ago, i got this error message:
"Warning: Cannot modify header information - headers already sent by....custom_functions.php:1...."
so i took the original custom_functions.php file from the original theme folder and copied the content to it. it solved the problem with error message.
you think that's what causing it ?
i don't thing it's a text-direction problem because the menus works well on other pages in the same language..
what do you think i can do ?
how can i check and solve this problem ?

p.s - do you mean that the site looks well on IE7 ? is the problem is only with IE8 ?

01-08-2011, 12:22 PM
I mean the site would look fine in IE 8, if it were rendering in IE 8 standards mode.

The problem is that the page is being served with a header that forces IE 8 to use IE 7 standards mode.

You can override this in your browser using the IE 8's Developer Tools. Doing so will not fix the problem. It will allow you to see that, if the page were rendered in IE 8 standards mode, it would look just fine.

What we need to do is find out what is causing this header to be sent by the server and change that. It should probably be set to IE 8 standards mode. But simply removing the header should allow the page to default to IE 8 standards mode in most cases.

Instead of messing with the custom_functions.php file, you probably should have just removed the headers from the file that was giving you the error.

What does custom_functions.php look like now? Does it have this in it:

header('X-UA-Compatible: IE=7');

If so, just change that to:

header('X-UA-Compatible: IE=100');

That will force the IE browser to use its highest rendering mode. For IE 8 that will be IE 8. For 9 it will be 9, and so on.

01-08-2011, 01:24 PM
wow man !
i didn't have this line : header('X-UA-Compatible: IE=7'); in my custom_functions.php.
but i added the: header('X-UA-Compatible: IE=100'); in the file anyway and it solved the problem like magic :)
only problem now the search box went down a bit.. not sure why, and again - only in IE..
thanks :)

01-08-2011, 09:02 PM
well, it worked for half a day and suddenly i started getting this error message:
"Warning:Cannot modify header information.."
and it's because of this code...
what should i do ?
thanks :)

01-09-2011, 03:58 AM
I seem to recall you saying that other pages were working for you in IE 8 with this menu. So this might be something you changed for just this one page. If it is, we need to figure out what that was and revert.

If not, that error generally means that the file with:

header('X-UA-Compatible: IE=100');

in it now has something else in it that writes to the page before that. Something presumably added by the server. The PHP header directive cannot come after the page has been written to.

Another possibility is that there is another include added before this file. If that other include writes to the page, headers in this file cannot be used.

Or code that writes to the page got added to the page that includes this file before this file gets included.

Did you make any changes that could have resulted in anything like that happening?

If not, is this a free host?

If so, they may be inserting code at the top of all .php and .htm(l) pages. There's probably nothing you can do about that other than finding a different host that doesn't do that. Some free hosts add stuff only at the end, that can be dealt with. Most paid hosts will not add anything anywhere, or can tell you how to exempt certain pages from - say, tracking code they might insert.

One other thing you can try is using the meta tag version:

<meta http-equiv="X-UA-Compatible" content="IE=100" >

This must come in the head of the served document (what you see when you are viewing the page in the browser and use the browser's 'view source'). And:

The X-UA-compatible header is not case sensitive; however, it must appear in the Web page's header (the HEAD section) before all other elements, except for the title element and other meta elements.

- from: http://msdn.microsoft.com/en-us/library/cc288325(v=vs.85).aspx

But, if the server is already sending an IE 7 header, as I suspected from the beginning, this probably will not override that. Again, contact your host for that answer. Ask them why they are sending a X-UA-Compatible header with a value of IE=7.

01-09-2011, 08:33 AM
thank you for this response :)
i tried taking the original 'custom_functions.php' file and upload it to the server instead of the one in use and rewrite the whole code in it.
it worked.. the site works now in IE and FF except the fact that the search box is moving down in IE..

i will ask the host which code they are using.

this error message is appearing when i try to edit 'comments.php' in order to change the text for the comment-form. you think it can be for the same reason ? this code that the host sends ?

thanks :)

01-09-2011, 02:35 PM
Not that you're asking, but to fully diagnose this for you I would need ftp access to your host account and perhaps even the ability to communicate with them on your behalf.

That's really beyond what's normally done in these forums as far as time involved for me, and the security risk to you.

However, the guidelines for you to diagnose this are as mentioned in my previous post and can be summed up as:

If anything writes to the page before the header directive is executed, the header directive will throw an error and not be performed.

I might add that there might be a few other things that cause this error. Writing to the page before it is the most likely, and will always cause an error.

By "writing to the page" I mean any echo directives or anything where it drops out of PHP to ordinary HTML, even just for a DOCTYPE, everything that writes to the page's source code must come after the header directive(s). Using print_r() and other things like that can also do this (write to the page).