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.

[jmpp@…]

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@…]

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();
 }

[jmpp@…]

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@…]

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@…]

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@…]

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. :)

[jmpp@…]

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@…]

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@…]

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.