How the IE6 beast was tamed
There is no immunity to the folly of Internet Explorer 6. You can even find a website devoted to the demise of IE6. JBS Partner’s first Drupal project fell victim to IE6. After the brand new website went live, we learned that the majority of the client’s visitors use IE6 and were seeing a blank white browser page. We also learned that they are located in rural areas and use dial-up to connect to the Internet. I was told upgrading the browser could take over 30 minutes to just download the files. So, we fixed the problem. Here’s how.
The Server Config
On a dedicated server, we were running Drupal 5.1.5 on Apache 2.2.20 Unix, PHP 5.2.6, MySQL 5.0.67 and JQuery 1.2.6
I wanted desperately to fix this issue. There is no shortage of articles on www.drupal.org about IE6, the WSOD and blank pages in IE6. Rob over at Mustard Seed Media and I searched and searched for an answer to no avail. Marc Ray over at Right Sprocket volunteered a strong effort. And my old co-worker Bob Caslin looked for a solution as well.
Initially it was discovered that visiting the Performance page and disabling Caching and CSS Aggregation stopped the IE6 blank white page problem. However, that did not feel like a solution to me. The site would have run just fine, but we hadn’t found the root cause of the issue.
CSS Aggregation Solution
One of the requirements of the project was a backup of the database that emailed the .gz file to the site owner. The 5.2 dev version of Backup and Migrate offers this capability.
It was also discovered that the dev version of Backup and Migrate was causing frequent PHP errors.
Moving to the stable version ( http://ftp.drupal.org/files/projects/backup_migrate-5.x-1.2.tar.gz ) did not eliminate these problems.
The Backup and Migrate module was removed. Instead a combination of Mutt, Chron and a little scripting enabled the database backups to be emailed out and then deleted from the server so that they don’t accumulate over time.
Caching Problem Solution
It was also discovered that during the Drupal install file permissions were effected which prevented the web server from caching files to the temporary directory. The group and owner was set to an account that is not the account that the web server runs as.
Server Performance Bonus
I also asked Andy to review the server’s overall performance. He found that it was quick and responsive. Music to my ears. The server load through testing remained at .4 and MySql performed up to standard.
The memory_limit in the php.ini file was increased from 32MB to 96MB which was a good idea. Also zlib compression was enabled. The following was added to the Drupal site’s /etc/httpd/conf/sites/www.xyadomain.com conf file.
# Enable file compression by MIME type
AddOutputFilterByType DEFLATE text/html text/plain text/xml
AddOutputFilterByType DEFLATE text/css
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0 no-gzip
BrowserMatch bMSI[E] !no-gzip !gzip-only-text/html
I truly hope that this is helpful to someone else as they troubleshoot IE6 issues in Drupal 5.1x.
Each server (hardware), OS, software, security patch level and configuration is different. We are hired to get the site working where it is hosted, rather than proving that it works on a developer’s machine. I can certainly understand why some developers find it faster and more economical to only do projects if the client will host on their server, an environment that they are familiar with. As in this case, getting to the root of the problem in an unfamiliar server environment is not always meaningful or affordable, while getting things to work is always meaningful.
By the way. I met all the guys listed above through Twitter. Very good guys. I can recommend them all.
What have you tried to solve your IE6 issue?