If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

Just when the talk of dropping IE6 support heats up again, Unit Interactive has a new PNG Fix solution for IE6.

In this new version of their PNG fix for IE6, they’ve fixed page element functionality issues with background PNG’s.  Something that’s plagued nearly every PNG fix for IE6 that I’ve come across (more on this in a bit).  Thanks to Jeff Leombruno, they’ve also taken out the requirement to have a width and height definition on the IMG tag.  Last but not least, thanks to Marcos Fernández they’ve cached the regexp and optimized the loop to speed things up quite a bit - especially for pages with a lot of elements.

Although they’ve got the background images working so that it will work with the CSS background-repeat attribute, it’s not working like it should.  Unfortunately this is due to IE6’s filter property which doesn’t allow it too.  What it does is read the element’s CSS and if background-repeat is in use, the image is stretched to fill the element background.  It’s not ideal, but what more can you ask for from an IE6 PNG fix?

Head on over to Unit Interactive Labs now to get the Unit PNG Fix for IE6.

Recently there has been a renewed interest in the discussion in regards to dropping support for IE6. The question is: Is it Time to Drop IE6 Support?

Search the web and you’ll surely find answers as to why or why we shouldn’t stop supporting IE6 as developers.

I, for one, don’t think it’s a singular choice of either supporting IE6 or not.

This decision could - and should - be made on a site-by-site basis with the answer being determined by the demographics of your audience and the traffic logs of your site.

With traffic logs, you can evaluate the number of visitors that would be inconvenienced if you suddenly dropped support for IE6. If you have a decent share of visitors still using IE6, then the answer to support or not support should be quite obvious.

Great! That works fine for sites that are established already.

What about new sites?

The ease of answer drops dramatically when you bring an entirely new site into the equation. Supporting or not supporting IE6 on your site becomes a much more complex question.

Some data that can help is both geographic and demographic data of your sites intended audience. Depending upon your message, and who you’re directing it at, you can generally answer the question as to whether or not to support IE6.

If your demographics say that IE6 support is worthwhile the question then becomes, does it fit in your budget?

IE6 Budget Friendly?

Developing with IE6 support can, at times, take two-times the amount of work. In turn, your overall cost is going to go up. If you have a low budget, taking IE6 support out may just enable you to do some of the other functional things that you wanted.

So What Do We Do?

As for me, I’ll continue implementing IE6 support for the meantime. I honestly believe that the best answer is providing a stripped down version of the site for visitors using IE6 with a friendly message encouraging them to switch to Firefox - the preferred method - and/or upgrade IE6 to, at the least, IE7.

This would still provide visitors with a functional site but let them know that they could have a better experience on the site if they just upgraded their browser. This would fall under the “sticks and carrots” method, I suppose.

I’ve been setting up WordPress MU on a Plesk server and I have to tell you that getting the subdomains (e.g. blog2.domain.com) to work was driving me crazy.  It took a combination of multiple sites before I got it working, so I wanted to post what I did here hoping that it might help someone else.

First and foremost, you need to create the vhost.conf file for the domain itself.  The vhost.conf and vhost_ssl.conf file needs to be created in the conf directory of the domain.  On Plesk it should be similar to: /var/www/vhosts/domain.com/conf/vhost.conf.

You can create the file from within the Plesk panel itself or using an SSH client like Putty (my preference).

Within the vhost.conf file you need to include the following line:

ServerAlias *.domain.com

Replacing “domain.com” with your domain.

Once you’ve done that you’ll need to run the following from your SSH client (there’s other ways to do this but this worked fine for me):

/usr/local/psa/admin/sbin/websrvmng –reconfigure-vhost –vhost-name=domain.com

Then restart apache and go try it out.  Guess what?  It’s supposed to work but it still doesn’t!

This is where the final magical step comes in.  Log in to your Plesk panel, go to domains, and select the domain that you are trying to set this up on.  Once the page loads, select DNS Settings.

From there, click the Add Record button from the top.

The Record Type should be CNAME.  In the “Enter domain name” field enter a *.  Then in the canonical name field enter your domain (without a www, just a plain domain.com).

Click Ok to save the record and try again.  You should now see your WordPress MU Subdomains on Plesk working!

Tags: plesk, wordpress mu subdomains, plesk wordpress mu