Website does not render properly in IE7

[wsiegrist@…]

IE7 does not render the xhtml/xml content, and instead treats the output of the site as static files to download.

[jmpalacios (Juan Manuel Palacios)]

I'm sure that's because of the echo "<?xml version=\"1.0\" encoding=\"$encoding\"?>\n"; declaration at the top of each of our pages, which I crafted to strictly adhere to the XHTML standard, not caring too much about how bad IE handles that particular line, I admit. I don't think it's a server level PHP issue or anything of the sort.

Personally I have no feeling about catering to such a broken browser as IE (there's always Firefox for Windows ;-), but I guess we could remove that line even if only for the purpose of giving MacPorts a wider net-surfing audience...

-jmpp

[raimue (Rainer Müller)]

I have a simple fix here. Just send the pages out as text/html for IE instead of application/xhtml+xml and it works for me.

Index: includes/common.inc
===================================================================
--- includes/common.inc (revision 33352)
+++ includes/common.inc (working copy)
@@ -42,8 +42,15 @@
 # Page header:
 function print_header($title, $encoding) {
     global $MPWEB, $trac_url, $svn_url, $downloads, $guide_url;
-    
-    header("Content-Type: application/xhtml+xml; charset=$encoding");
+
+    # If the User Agent is MSIE, answer as text/html
+    if (strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE') !== false) {
+        $contenttype = 'text/html';
+    } else {
+        $contenttype = 'application/xhtml+xml';
+    }
+
+    header("Content-Type: $contenttype; charset=$encoding");
     include("$MPWEB/includes/header.inc");
     print_warnings();
 }

[jmpalacios (Juan Manuel Palacios)]

The proposed patch looks fine to me too, but if I'm not mistaken the line that really makes IE choke is the xml declaration which I posted in my first comment, located in the trunk/www/includes/header.inc file, at the very end of the first PHP mode. I know this because I was advised to not put it if I wanted the site to work with IE, which... was not a top priority for me ;-)

So, all in all, I'd think the patch is a bit incomplete if we want the site to work with IE, though extending it to cover the xml declaration shouldn't be too hard.

-jmpp

[ryandesign (Ryan Carsten Schmidt)]

In the discussion on the mailing list, ​Mark Hattam said the pages work fine if saved to the local disk and then opened in IE 7. It's just the web server headers messing it up. And Rainer said above that the patch works for him. So let's just start by fixing the web server headers and see what happens. Maybe we still need to remove the XML declaration for IE 6 but let's deal with that later; this ticket is for IE 7.

Marco Battistella reminded me via personal email that we should be ​looking at browser capabilities, not user agent strings. So let's do it like this instead:

    if (isset($_SERVER['HTTP_ACCEPT']) && strpos($_SERVER['HTTP_ACCEPT'], 'application/xhtml+xml') !== false) {
        $contenttype = 'application/xhtml+xml';
    } else {
        $contenttype = 'text/html';
    }

[raimue (Rainer Müller)]

I agree, checking HTTP_ACCEPT is better than checking for user agent. Although it is not quite correct, as with this solution we ignore the fact, that text/html could be at a higher priority in HTTP_ACCEPT than application/xhtml+xml. But I think it is neglectable...

[ryandesign (Ryan Carsten Schmidt)]

I already wrote a complete HTTP_ACCEPT parser class in PHP some time ago; I can dig that out and we can use that instead, to be absolutely correct. :)

[jmpalacios (Juan Manuel Palacios)]

Replying to ryandesign@macports.org:

I already wrote a complete HTTP_ACCEPT parser class in PHP some time ago; I can dig that out and we can use that instead, to be absolutely correct. :)

Is that class open source...? :-) In any case, that would be a very nice addition to the website code, please do put together a patch we can look at. Thanks!

-jmpp

[ryandesign (Ryan Carsten Schmidt)]

Sure, my code is your code. :) Here are the classes. It looks like I never got around to implementing anything to deal with the specific case Rainer mentioned. All I currently have are methods to ask "What is the most preferred (MIME type)?" and "Is this (MIME type) acceptable?" A good addition might be a method that takes two (MIME types) and returns the one that's preferable.

I say "(MIME type)" because the classes handle not only MIME types but also languages, charsets and encodings.

I didn't yet try to integrate the classes into the MacPorts web site. I don't have IE handy right now so I can't really test it. Maybe I should try IEs4Linux again.

[raimue (Rainer Müller)]

Another patch, using Ryan's classes this time. I added all of them although currently we will only use AcceptMime, but that can be extended with AcceptLanguage to present our website automatically localized.

Please review, it works for me with IE 7.

[mark@…]

the website still doesn't work in IE7 ... just offers to download a file. This is maybe OK for people who can use other browsers, but in a corporate environment where IE is the only permissable browser, it is a real downer.

[ryandesign (Ryan Carsten Schmidt)]

Ok, I tested Rainer's patch​ locally and committed it in r43660. I made some changes:

• I included the AcceptMime class in the print_header() function where it's used instead of at the top of common.inc
• I put the new files into the existing includes directory instead of making a new lib directory
• I added lines for the modeline, Id and copyright statement to the new files
• I converted tabs to spaces in the new files
• I removed the closing PHP tag in the new files, which is unnecessary and would cause a problem if anyone were to add whitespace after the closing PHP tag

I verified on my local web server that the page now displays on IE 6 on Windows XP. I haven't tested with IE 7 or 8; can someone else with access please do that and report back?

[wsiegrist@…]

Works in IE8. Closing.

[(none)]

Milestone Website & Documentation deleted