WordPress Upload HTTP Error Fix

Several versions of WordPress ago, I started sporadically encountering a problem while trying to use the Flash uploader in WordPress. Every time I tried to upload something using the Flash uploader, I would just get this HTTP Error message:

A Screenshot of the HTTP Error message when attempting to upload a files in WordPress

I searched for a solution to the problem and found that it was a bug in one of the older versions of WordPress. Now, several versions later, it’s still happening. I’ve seen it on both WordPress 2.7 and WordPress 2.8. More Googling revealed several tips about about adding directives to the .htaccess file. I tried each of them, but with no success.

The most puzzling part of this problem for me was that I have several different installations of WordPress on different servers and different versions, but this error was only happening on some of them. After I actually sat down and thought about the problem, I realized that the error was only occurring on the WordPress installations that I had set to be private through the authorization control using my .htaccess files. Those sites have an .htaccess file in the root directory which starts with something like this:

AuthName "private site"
AuthType Basic
AuthUserFile /home/private/.htpasswd
Require valid-user

This causes a dialog box to pop up when you try to go to the site. You have to specify a correct username and password, as specified in the .htpasswd file, in order to gain access to the site.

After realizing there might be a connection with this, I tested using the flash uploader on one of my sites with the htaccess authentication turned off. Sure enough, it worked like a charm. So after realizing that the HTTP Error was definitely related to this, a solution was easier to find.

The solution that worked for me was to create an .htaccess file in the wp-admin directory. The htaccess file should have the following rules in it:

AuthType Basic
AuthName share
Satisfy Any
Order deny,allow
Allow from all

<IfModule mod_security.c>
<Files async-upload.php>
SecFilterEngine Off
SecFilterScanPOST Off
</Files>
</IfModule>

Since adding this file, I’ve been using the image uploader on my protected sites without a problem.

Current Web Design Resources

I’ve been steadily working on a new web design project which will eventually become a custom WordPress template. In the design process I’ve slowly managed to amass several browser windows full of tabs of related things that I was looking at for inspiration on the site.

Safari is getting pretty slow with all of those tabs so I kind of needed to do a complete dump of the tabs. Without further ado, here are the links (for my benefit as much as yours).

Wireframes

CSS Galleries

WordPress Themes (Inspiration)

Photoshop and Illustrator Tutorials

Other Stuff

Getting Geeky With YSlow

I spent a good amount of time over the last couple of days attempting to make my site a little bit faster. I’ve been pretty negligent about it up until now, because I know that much of the slowness of my site can be directly attributed to my web hosting company. 1 Even so, I decided to spend some time doing what I could to speed things up.

The first thing that I did was run a test in YSlow to see how my site was doing. Yikes! I got an F right off the bat. After some further review and research, I realized that this wasn’t necessarily something that should have me freaking out. If you’re not entirely familiar with YSlow and what it does, Jeff Atwood’s article, “YSlow: Yahoo’s Problems Are Not Your Problems” on Coding Horror is a must-read. Basically, YSlow offers a lot of good advice that should be taken, but with a grain of salt.

With that said, here are the steps that I’ve taken to speed up my site.

Make Fewer HTTP Requests

The first time I ran YSlow, I discovered that all of my pages were making a ridiculous number of HTTP Requests for JavaScript and CSS files. I was requesting four CSS files: screen, print, IE hacks, and one for Lightbox 2. Unfortunately, the IE hacks stylesheet is still necessary. Obviously the screen an print ones are as well. After taking a look at the Lightbox 2 CSS file, I decided that it was small enough to simply tack on to the bottom on my existing screen stylesheet. That’s one down.

There were also quite a few JavaScript files being requested, including all of the files for Google Analytics, Mint, WP Stats and Lightbox. What can I say? I like my tracking software.

The first thing that I decided to do was to reduce the number of tracking utilities I was using to two. I love Mint and Google Analytics seems to be necessary, so I had to get rid of WP Stats. That wasn’t such a big deal for me. That’s another one down.

The next step was to take a long hard look at Lightbox 2. I originally installed this for my Gallery page, and then decided to include it on all my pages on the off chance that I might want to use it in a few posts. While it works and looks great, I’ve been decidedly unhappy about how much baggage Lightbox comes with. There are five JavaScript files that need to be included, just to have that neat little image trick. Even worse, the included Prototype JavaScript library weighs in at a staggering 124KB. What a waste.

I made a mental note to do some research to find a more lightweight solution for my image gallery. Smashing Magazine has a good list of them, which I will inspect at a later point in time. For the time-being, I compressed the Javascript files and was able to bring the total size of the Javascript files down to about 125KB from 196KB. I also decided to only include the scripts on my actual Gallery page. It seems like too much of a waste to require all those files when I rarely use them.

Put CSS At the Top and JS at the Bottom

When I first set up Lightbox, I wanted to avoid using a WordPress plugin for it, so I cooked up my own method of including it. Most of the work was simply trying to find a way around hard-coding my template directory in it and also using a function to keep my header.php file clean and easy to read.

The first problem with my original method was that all of those JavaScript files were at the top of the page, meaning that almost 200KB of JavaScript had to be loaded before any of the content on my page started to load. That’s no good! The simplest thing to do was to move my function down to the bottom of the page, right before the scripts for Google Analytics and Mint. The only other problem was that the function included the CSS file as well. Since I had already decided to merge the Lightbox CSS with my main CSS, all I actually had to do was remove the call to load the CSS.

Use Google’s APIs

Unless you’ve been living under a rock (or just don’t care), you’ve probably heard that Google just released their AJAX Libraries API. This was pretty much perfect timing for me since I was already looking at how Lightbox used the Prototype Framework and Scriptaculous Effects Library. It makes a whole lot more sense to use a version hosted by Google than it does to require clients to download the same exact version of a standard library from my slow web host. Ajaxian has a good rundown of the features of this new API and why you would want to use it.

After doing a relatively quick setup, I was able to call the Prototype framework from the Google API. It came in from Google at only 29KB; that’s the same file that I was just complaining was 124KB. That’s a no-brainer. Scriptaculous was a bit more of a problem though, since it takes a modular approach. Lightbox 2 actually only uses two of the eight possible modules. As far as I can tell, there is no way to use the standard type of of script tag to only include the libraries you want like this:

<script type="text/javascript" src="https://blog.nerdstargamer.com/wp-content/themes/positiveGrey-v2.0/js/scriptaculous.js?load=effects,builder"></script>

One of the comments on Ajaxian by jdalton, addresses this:

Another issue google will need to work out is that MooTools, Scriptaculous, and Dojo are modular (meaning you don’t have to load the kitchen sink and can just load the parts you want). This can effect the file size footprint as well. This may be beyond the scope of a CDN though.

Because I couldn’t find a way to only include the modules I needed, I decided to continue serving them locally instead. So, my function to include Lightbox now looks like this:

function AKM_include_lightbox() {
    $templateDir = get_bloginfo('template_directory');

    $output = <<<EOT
<script src='http://www.google.com/jsapi'></script>
<script type="text/javascript">
    var tplDir = "${templateDir}/images/lightbox/";
    google.load('prototype', '1.6.0.2');
</script>
<script type="text/javascript" src="${templateDir}/js/scriptaculous.js?load=effects,builder"></script>
<script type="text/javascript" src="${templateDir}/js/lightbox.js"></script>
EOT;

echo $output;
}

Reorganize Template Directory

Although this doesn’t actually have anything to do with the speed of my website, it seemed appropriate to take this opportunity to reorganize my template directory a little bit. I was striving to create a more traditional web setup within my WordPress template that included all CSS in a CSS folder, JavaScript in a JS folder, and images in an image folder.

This first issue to address was the WordPress default style.css file. This file is necessary for WordPress template to function properly, as explained in the WordPress Theme Development Codex page. What I decided to do was to remove all of the actual styles from this file and simply leave the WordPress information:

/*
Theme Name:Positive Grey
Theme URI:http://nerdstargamer.com
Description:A simple theme using a fluid 2 column layout with green and grey
Version:2.0
Author:Alissa Miller
Author URI:http://nerdstargamer.com
*/

/* See css/screen-x.x.css for styles */

I then moved all of the styles to a new file called screen-x.x.css in the CSS folder. This allows me to have all stylesheets (with the exception of style.css) in the CSS folder. It also allows me to use versioning in the filename, which as we will see, will be important after I’ve implemented better caching and expires headers.

I previously put all of the Lightbox files in their own folder, to keep things neat. I’ve now decided to roll those files into the normal directory structure instead of keeping them separate. The CSS file got merged with screen.css and all of the Lightbox JavaScript files got moved into the js folder. Lightbox also includes several images, which I decided to put in images/lightbox/ so as not to confuse them with my own template images.

Gzip Components, Improve Caching

One of the rules for YSlow includes Gziping components. Some of my scripts are for Mint and JavaScript, which I can’t really control. The others however, along with my CSS are fair game. I had a little bit of trouble figuring out how to do this since I did not want to use any of the more common php methods to compress my pages on the fly and was looking at just using either mod_gzip or mod_deflate. The YSlow page gives the following information:

Gzipping generally reduces the response size by about 70%. Approximately 90% of today’s Internet traffic travels through browsers that claim to support gzip. If you use Apache, the module configuring gzip depends on your version: Apache 1.3 uses mod_gzip while Apache 2.x uses mod_deflate.

After some research, I figured out that my website is hosted on Apache 2 (not earlier). I included this block in my root .htaccess file:

# GZIP CSS AND JS
<IfModule mod_deflate.c>
 <FilesMatch "\.(js|css)$">
  SetOutputFilter DEFLATE
 </FilesMatch>
</IfModule>

I also decided to make the move to using WP Super Cache instead of WP Cache. WP Super Cache is much like WP Cache but does offer some performance benefits. Once I got WP Super Cache configured and running, it seemed to have an immediate effect on the speed of my blog. Of course, that could have just been wishful thinking on my part.

Add an Expires Header

One of the last things I did was add an expires header in my root .htaccess file. This tells the client browsers not to look for a new version at all if the one in their cache hasn’t expired yet.

Now, I obviously don’t want to do this to the dynamic WordPress files (comments and posts would never update!), but that’s okay because WP Super Cache is taking care of those files already. What I do want to do is add the expires header to all of my images, JavaScript and CSS files. None of these will really change except for the CSS files. Fortunately, when I reorganized my template files, I gained the ability to append version numbers to my CSS files. So now I can go ahead and add that expires header to my CSS files, and then simply change the file name when I need to make changes in my CSS. The new file will download like normal, and it’s good practice to get some sort of versioning underway.

Here is the code that I put in my .htaccess file:

### ADD FAR OUT EXPIRES HEADDER TO STATIC CONTENT ###
<ifmodule mod_expires.c>
  <filesmatch "\.(jpg|gif|png|css|js)$">
       ExpiresActive on
       ExpiresDefault "access plus 1 month"
   </filesmatch>
</ifmodule>

After some thought I decided that one month was an appropriate length for my purposes. This depends entirely on what type of content it is, and how often you are going to change it.

After doing all of the previously mentioned fixes, I had improved the page load time quite a bit for most of my site. The only remaining bottleneck seemed to be my Gallery page. That wasn’t particularly surprising considering that the page includes 25 thumbnail images. The total size of all of the images, at full size, weighs in at a hefty 2MB. This page was also still using the Lightbox scripts.

One of the things I noticed while using YSlow was that some of my thumbnail images seemed to be unnecessarily large. Some of them were as big as 40KB for a 150×150 pixel image! Upon further inspection I decided that all of the thumbnails were too large. I had used WordPress’ feature to automatically create thumbnails of images to set this up. I’m not sure exactly how WordPress does this, but after taking a look at the file sizes I’m sure that it sucks. I recreated all of the thumbnails in Photoshop and the biggest one is now only 17.6KB.

I had also originally set up the gallery page in WordPress’ admin screen (using the file browser and things like that). Once I was no longer using the dynamically generated thumbnails, it didn’t make sense to lay out the page in WordPress’ page section. Instead I created a page template called gallery.php, which includes all of the images and code for the page.

I also copied all of the full size and thumbnail images into my template image folder. This way the links to the images are no longer being stored in my database.

Conclusion

After all of these changes my website does seem to be a little bit faster. These types of exercises are good practice for any web designer/developer. Having a slow web host is no excuse for not doing what you can on your end to make the site faster.

As always, any tips or improvements from more experienced developers in this area are greatly appreciated.

  1. You get what you pay for, right?

Gallery of Doodles in Lightbox 2

NerdStarGamer now has a new Gallery page that features my doodles:

Screenshot of Doodle Gallery

All of the images have been set up as a list of thumbnails which use Lightbox 2 to display large versions.

I spent a little extra time to set up Lightbox on this blog without using a plugin. I’ve been on a steady crusade to get rid of most of my plugins for quite some time. Setting up Lightbox in WordPress was fairly straightforward.

After downloading the Lightbox 2 files, I created a new directory in my template directory called lightbox and dropped all of the lightbox files into it. I then put a function call into the header.php file right before the line that reads <?php wp_head(); ?>.

<head profile="http://gmpg.org/xfn/11">
    ...some other tags...

    <?php AKM_include_lightbox(); ?>
    <?php wp_head(); ?>
</head>

The AKM_includ_lightbox(); function is just a short little function that I wrote and put in the functions.php file of my template. Here is the function:

function AKM_include_lightbox() {
    $lbDir = get_bloginfo('template_directory') . "/lightbox";

    // Echo out some file path variables for images used lightbox JS
    $output = '<script type="text/javascript">' . "\n";
    $output .= "\t" . 'var tplDir = "' . $lbDir . '";' . "\n";
    $output .= '</script>' . "\n";

    // Echo links to js and css for lightbox
    $output .= '<script type="text/javascript" src="' . $lbDir . '/js/prototype.js"></script>' . "\n";
    $output .= '<script type="text/javascript" src="' . $lbDir . '/js/scriptaculous.js?load=effects,builder"></script>' . "\n";
    $output .= '<script type="text/javascript" src="' . $lbDir . '/js/lightbox.js"></script>' . "\n";
    $output .= '<link rel="stylesheet" href="' . $lbDir . '/css/lightbox.css" type="text/css" media="screen" />' . "\n";

    echo $output;   
}

This first line of the function sets up a variable that includes the path to the Lightbox files inside my template directory. This is necessary because the lightbox.js file needs to reference the images included in the Lightbox folder. Without this part, the previous, next and close images will not show up because the link will be going to your WordPress uploads directory.

That second chunk of text in the function echos out a small bit of JavaScript into your header that simply declares the variable tplDir and sets it to the path to your LightBox installation. The last chunk of text inserts all of the necessary Lightbox JavaScript and CSS links into your header. I could have written all of this directly into the header.php file, of course, however I felt that my file was getting a bit messy and that this approach was much more clear.

We also need to make a small edit to the lightbox.js file which is going to use that tplDir variable we set. Find the line in the beginning of the file like this (around line 49):

fileLoadingImage:        'images/loading.gif',     
fileBottomNavCloseImage: 'images/closelabel.gif',

Simply change those two lines to this:

fileLoadingImage:        tplDir+'/images/loading.gif',     
fileBottomNavCloseImage: tplDir+'/images/closelabel.gif',

That completes the Lightbox 2 setup in WordPress without using a plugin. Now all you have to do is add the rel="lightbox" tag to any link you want to use Lightbox. For example, if you have a thumbnail image that links to a larger image like this:

<a href="images/full-size-image.jpg"><img src="images/thumbnail" /></a>

To add the Lightbox effect, just add in the attribute like this:

<a rel="lightbox" href="images/full-size-image.jpg"><img src="images/thumbnail" /></a>

Be sure to check out the Lightbox 2 page for more information on what you can do with it.

Finding a Good CMS Solution

There is a pretty good discussion going on over at 456 Berea Street about “Looking for open source CMS and portal software options“.

I’ve been thinking a lot about this for the last couple of months. I’ve worked extensively with WordPress (for this blog and a few others) and I really feel comfortable with it. I am confident that I can work with it and bend it to do most things I want with a little effort.

Currently I’m using WordPress for a contract job to create a smallish website managed by a CMS. The client wanted to use WordPress, and I am reasonably confident that it will achieve their goals. That said, I think they’re getting uncomfortably close to WordPress’s limits. There’s always a point when you are extending software that you have to stop and consider, “Am I really using the right tool for this job?”

I’d really like to branch out and learn some other content management systems that are more powerful than WordPress and also more geared towards CMS rather than blogging out of the box. I tried using Drupal a few months ago, and like many of the peopling commenting on 456 Berea Street, I found the admin interface to be absolutly overwhelming. It’s definitely designed with the mentality that more is better. I had a very clear vision in mind for what I wanted to accomplish with my Drupal site, but I ended up stumbling on some key things that felt like they should be very easy. Primarily dealing with attachment links.

That said, I was very impressed in general with Drupal. It seemed liked the sky was the limit as far what could be accomplished with it. The user roles were also a welcome departure from more restrictive systems like WordPress.

In the end, I was left with the impression that given a lot of time and energy (to learn Drupal) I could make some very cool sites. I wonder, are there other solutions that are better?



appointive
appointive
appointive
appointive