New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #14062 (closed defect: fixed)

Opened 6 years ago

Last modified 5 years ago

Website does not render properly in IE7

Reported by: wsiegrist@… Owned by: jmpp@…
Priority: Normal Milestone:
Component: website Version:
Keywords: ie7 windows content-type Cc: mark@…, raimue@…, ryandesign@…, marco@…
Port:

Description

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

Attachments

accept.tar.bz2 (1.8 KB) - added by ryandesign@… 6 years ago.
patch-macports-www-ie-mime.diff (5.4 KB) - added by raimue@… 6 years ago.

Change History

comment:1 Changed 6 years ago by jmpp@…

  • Owner changed from wsiegrist@… to jmpp@…
  • Cc jmpp@… added
  • Component changed from server/hosting to website

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

comment:2 Changed 6 years ago by jmpp@…

  • Cc jmpp@… removed

comment:3 Changed 6 years ago by 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();
 }

comment:4 Changed 6 years ago by raimue@…

  • Cc raimue@… added

comment:5 Changed 6 years ago by 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

comment:6 Changed 6 years ago by ryandesign@…

  • Cc ryandesign@…, marco@… added

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';
    }

comment:7 Changed 6 years ago by 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...

comment:8 follow-up: ↓ 9 Changed 6 years ago by 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. :)

comment:9 in reply to: ↑ 8 Changed 6 years ago by 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

comment:10 Changed 6 years ago by 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.

Changed 6 years ago by ryandesign@…

Changed 6 years ago by raimue@…

comment:11 Changed 6 years ago by 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.

comment:12 Changed 6 years ago by 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.

comment:13 Changed 5 years ago by ryandesign@…

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?

comment:14 Changed 5 years ago by wsiegrist@…

  • Status changed from new to closed
  • Resolution set to fixed

Works in IE8. Closing.

comment:15 Changed 5 years ago by anonymous

  • Milestone Website & Documentation deleted

Milestone Website & Documentation deleted

Note: See TracTickets for help on using tickets.