• What I want from a restaurant website

Perch costs about $55 per website but sounds intriguing. Mostly just a small customizable solution. It sounds like it might be nice for some basic websites where other CMS solutions would be overkill.

First Impressions

The typical nerd response to this has been laughing and pointing. Now, I have to admit, that was my first response as well. But, after I stopped laughing and shaking my head (well, actually I’m still shaking my head), I started thinking of all of the crazy things that I’ve seen people do in the last 5+ years I’ve spent working in computer support. While I find this whole thing rather amusing, I can’t say that I’m actually surprised. I have witnessed someone physically lift a mouse into the air when asked to “move the mouse up”.

I think the biggest difference between developers (or nerds) and normal people, is that normal people don’t want to know how a computer or the internet work. They don’t care. They don’t want to learn. I’ve never really gotten over this because it’s something that I find terribly disappointing about working in computer support. I can watch a person do the same thing over an over again knowing that there is a better way to do it, but they don’t care. They don’t want to understand. They don’t want me to teach them how to understand why something works a certain way. They just want to get the result they need.

I still have yet to decide the which angle of this attitude is the more important one. Is it an indication that a certain population of people will always be lagging behind because they refuse to adapt to a quickly changing world that requires them to understand certain aspects of technology? Or perhaps is it an indication that technology (and the people who develop it) simply hasn’t evolved enough to adapt to “real people” who do not “need” to understand black box in order to use it?

The Wider Debate

Much has been written in regard to the Facebook login fiasco, and quite a controversy has been sparked in the development community about what this really means, and whose “fault” it is. First, check out some of these articles which highlight very interesting points for both sides of the debate.

• We’re the Stupid Ones: Facebook, Google, and Our Failure as Developers
• Reply to Funkatron’s Analysis of the RWW/Facebook Debaucle of 2010
• No, We’re Not The Stupid Ones
• Really? Are we the idiots?
• Some People Can’t Read URLs
• Why It’s Not A Google Failure

On Whether Or Not Google Got It Wrong

I guess this really depends on how far exactly the RWW article made it up the search rankings. I’d say that it’s an entirely different debate depending on whether the search result was first or fifth. I thought originally the result was first, but Stratton claims it never made it to number one. I don’t see any reason why that RWW article should not reach a high rank on the search term “facebook login” since that is what the article is about. It’s a popular blog and presumably the article was popular as well.

A number one search result is another matter though. I agree with the camp that says it would be impossible for Google (or any other search engine) to always know what a person meant. But seriously, isn’t that what Google is always trying to do? It just doesn’t sit right to me that an article about a website as huge as Facebook would ever be a more popular search intention that the site itself.

The search “facebook login” seems to clearly indicate a search for the login page itself. That seems fairly intuitive. In fact, substitute facebook for most major web apps and I think it’s the same. However, if the search changes slightly to something like “facebook changes login”, it’s now an entirely different issue.

Perhaps the artificial intelligence of search algorithms just isn’t sophisticated enough to parse nuances of language that seem so obvious to humans. Then again, perhaps they are and that’s why the RWW page never made it to the number one spot for the “facebook login” search. In that case, I really think this whole debate about whether or not Google got it wrong is really a non issue.

On The Users Themselves

Moving past the whole Google question, there are a couple of things that really baffle me about this entire fiasco. First of all, it’s clear that these users have no idea what a URL is. Both because they are using Google Search to find a URL like facebook.com and also (and more importantly) because they did not realize that the RWW URL bears absolutely no resemblance to any Facebook URL, and therefore cannot possible be the Facebook website.

How is it that these users who have to most superficial understanding of what a website is and how the internet works, are also capable of writing comments to the RWW page? They are baffled about how to log in to a site that’s not the Facebook site they’re used to (and in fact bears absolutely no resemblance to it). But they still can use the comment form in order to voice their disapproval of the perceived redesign.

Okay so, maybe typing into a comment form is no big deal. Even people that think the entire internet is just Google/Facebook/YouTube can figure out a comment form. What about using Facebook itself? It’s not like Facebook is that simple to use. This isn’t a slam on Facebook user interface, it’s just that Facebook is huge, and there are a lot of things that you can do on it. How can these people figure out how to use Facebook?

Perhaps this is an issue of normal people realizing that they want to use Facebook enough to spend time learning about friend networks, walls, how to upload photos in the little snazzy uploader. Why is it that they deem it important enough to figure out how to use websites like Facebook, but at the same time don’t care to understand what a web address is? I think I just fail to understand why someone would not care about that kind of stuff because I am so interested in it myself.

Is It Actually a Facebook Problem?

I logged on to Facebook for the first time in several weeks today. I don’t find myself doing this too much these days because I often either don’t look at Facebook at all or only look at it through the Facebook iPhone app. Much to my surprise, Facebook looked quite a bit different than the last time I saw it. I started thinking about how often I have to do what Steve Krug calls “muddling through” when I’m using Facebook. I know what I can do on Facebook, it just usually takes me a couple of tries to figure it out.

Why is this? Well, when I think about it, the Facebook website changes quite a bit. They’ve made several large and small changes to the website in recent years (or less?). Compare this to something like the Google home page which has changed very little since it’s inception.

Perhaps Facebook users have come to expect over time, and through personal experience, that the Facebook website will change, and sometimes change dramatically. They expect this because it has happened. Perhaps it wasn’t so far fetched after all to believe that the RWW page was simply just the newest reiteration of a Facebook design.

Now, I know this is a stretch, but perhaps it’s not too much of a stretch. Has Facebook changed its pages so much that users are now willing to accept that a complete makeover, such as the RWW page being a new Facebook design, is a real possibility? Does Facebook redesign too often? Has Facebook unwittingly trained it’s users to expect this?

One Last Only Slightly Related Thought

Anyone like me (aka: nerd, developer, gamer, general computer enthusiast) who thinks that the iPad is stupid and going to be a flop is not seeing the big picture. The iPad is designed for exactly the type of people commenting on the RWW website. Both Mike Rundle and Fraser Speirs are dead on (along with some other smart people as well). I think that most people will love the iPad. I think the iPad is going to revolutionize the netbook/eReader market just like the iPhone revolutionized the mobile phone market. Will the iPad be as successful a device as the iPhone? I don’t know. But I guarantee that it will change the game.

• Pure CSS3 AT-AT Walker

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.

View Larger Map

Pros

• Avoids any extra HTTP requests for files with IE-only hacks
• Slicker than including that monstrosity inside the head tag
• Allows for easier reading and maintenance of stylesheets. The IE hacks can be placed where they’re relevant in the stylesheet.

Cons

• Doesn’t this defeat the entire idea of separating out hacks from standard CSS?

Does anyone else have opinions on the matter?

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

• Building a Website Wireframe in Illustrator
• Why You Should Create a Wireframe First
• Wireframing With InDesign and Illustrator
• Wireframing Part II: Illustrator Basics

CSS Galleries

• CSSelite.com
• CSS Drive (This site appears to be down as of writing this)

WordPress Themes (Inspiration)

• ThemeForest
• WP Glamour
• Cellar Heat: A Free WordPress Theme

Photoshop and Illustrator Tutorials

• Create a Vibrant Modern Blog Design in Photoshop
• Grunge Border
• Quickly Add Grunge To Text
• Illustrator Tutorials

Other Stuff

• Adobe Kuler
• 960 Grid System
• How to: CSS Large Background
• WordPress Developer’s Toolbox
• Removing Category Base from WordPress URLs

Parallax turns a selected element into a ‘window’, or viewport, and all its children into absolutely positioned layers that can be seen through the viewport. These layers move in response to the mouse, and, depending on their dimensions (and options for layer initialisation), they move by different amounts, in a parallaxy kind of way.

This is pretty neat stuff. I’m racking my brain trying to think of gratuitous ways to use this in my next design project. So far I’m only thinking of running dogs…

After the final list came out, I implemented any changes to the rules, tested it in my default browser (Safari) and called it good. Several days later however, I tried to pull up this site on my home PC using Firefox and was greeted with a big fat 403. Uh oh. I switched over to IE and got the same results. After some cursory checking, I switched over to using my laptop and Safari and noticed that there was no problem there. Weird. Even weirder because I’m using Version DSL with router, so as far as my server is concerned, both computers have the same IP.

Most weird: when I actually checked my access.log, I could see my own requests that had been served 403 errors. But instead of the normal 403, the requests actually showed a single request with a 200 status for each time I tried to load a page.

IP - - [30/May/2008:10:20:02 -0700] "GET /about/ HTTP/1.1" 200 363 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7" 
IP - - [30/May/2008:10:20:07 -0700] "GET / HTTP/1.1" 200 364 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7" 

That’s a request for my about page, and then my main page. Both recieved a “Forbiden” in my browser, but both show a status of OK in my log. Additionally, if the request had actually been successful, a bunch of other files would have been requested as well.

I quickly decided that it was more important to get the site up and running again rather than spend a bunch of time trying to figure out what the problem was and how to fix it. After some selective commenting in my .htaccess file, I discovered that the culprit rule was the following one from the 3G Blacklist:

RedirectMatch 403 \/\/

I commented out the rule for the time-being so that I could test further at a later point in time.

This particular rule redirects all requests that contain a double slash after the http:// section. I thought that this was very odd that this rule should break my site because I can’t see any reason why a legitimate request would need to utilize a double slash. I also was concerned, because judging from my access.log, this is the rule that does the bulk of the work concerning 403 errors.

I did some more scanning of my .htaccess folder and arrived at the conclusion that the culprit must be within the rules for the WP Super Cache plugin I had recently installed. This plugin creates a static html page to serve instead of the normal WordPress PHP pages. Here’s an explanation from their site:

When a visitor who is not logged in, or who has not left a comment, visits they will be served a static HTML page out of the supercache subdirectory within the WordPress cache directory. If you navigate to that directory you can view an exact replica of your permalink structure as well as the HTML files within the directories. To determine if a page has been served out of the Super Cache, view the source and the last line on the page should read or .

Hmm, I’d say we’re getting closer now. The section that WP Super Cache adds to my .htaccess file looks like this:

# WP SUPER CACHE
<IfModule mod_rewrite.c>
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
</IfModule>
# END WPSuperCache

Now, perhaps a mod_rewrite ninja can see immediately what the problem is, but I was having trouble actually figuring out what was going on. Since I’m using a shared host, I don’t have access to an httpd.conf and therefor cannot use the RewriteLog directive to actually see what’s going on in the rewrites.

After some research I discovered that by adding an R flag to each of WP Super Caches RewriteRule directives, it would force a temporary redirect and therefore allow me to see in the browser what was actually being requested. I changed each RewriteRule to the following:

RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [R,L]
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [R,L]

Now after running the same tests again, I could see in my browser how things were getting screwed up. I typed the address http://blog.nerdstargamer.com into Firefox and sure enough, got the 403 error. This time though, when I looked at the URL it showed the following redirect:

http://blog.nerdstargamer.com/wp-content/cache/supercache/blog.nerdstargamer.com//index.html

There’s the culprit right there. The double-slash right before index.html. So, basically, every time WP Super Cache serves a cached page, it’s serving a URL with a double slash before the file name. I did a quick check by deleting the cache folders of WP Super Cache and confirmed that pages not cached loaded fine while cached pages always got redirected to a 403 error. Bingo.

So, now to fix the problem. Why on earth the .htaccess code for WP Super Cache does this in the first place, I’m not sure. It seems wrong to me, but I’ll defer to the experts on this one. Basically what’s happing is that the variable $1 is being replaced with the path name that was requested which includes a trailing slash. The next part of the rewrite starts with a slash, thus the double slash problem.

I was able to fix the conflict in the WP Super Cache code by removing one of the slashes like so:

# WP SUPER CACHE
<IfModule mod_rewrite.c>
AddDefaultCharset UTF-8
# not post
RewriteCond %{REQUEST_METHOD} !=POST
# not a search
RewriteCond %{QUERY_STRING} !.*s=.*
# not an attachment page
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1index.html.gz [L]

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{QUERY_STRING} !.*attachment_id=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1index.html [L]
</IfModule>
# END WPSuperCache

This certainly looks funny but at least it works. I’m sure there is a more elegant way to do this, like say, rewriting the original request to remove the trailing slash and then applying the cache rules. Perhaps this is really a problem with the way WordPress is doing its permalinks (I’m on 2.5.1 by the way). Who knows? Ninjas chime in.

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="http://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.

Rework the Gallery Page for Better Performance

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?↩

It makes me snicker every time I look at it.

Via Design Shack.

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.

The Superest is a continually running game of My Team, Your Team. The rules are simple: Player 1 draws a character with a power. Player 2 then draws a character whose power cancels the power of that previous character. Repeat.

The design of the site itself is is quite elegant and simple. Most of the display type on the site is done in a very nice typeface:

Start from the beginning get the the feeling for the way the superest heros flow one after another.

The type really looks elegant and nice. This is all done with CSS styles and no images. It’s a great example of what can be done with web typography.

Via Daring Firebal.

Early on in the project, after the design mockup had been approved, I knew there were going to be some difficulties implementing it. One of the things that I knew would be a problem was the fact that I had designed a rather prominent section on the home page of the site which called for an article to be split into multiple columns. This being a content managed site, I also knew it wasn’t really going to be an option to ask the end users to break up their articles into two even sections so that it would make nice and pretty columns. Also, CSS3 really wasn’t an option, since this site would have to work on all current browsers. Something else would have to be done.

The solution I ended up using was a very elegant JavaScript program written by Randy Simons. The script is called Multi-Column Text and is pretty easy to implement. It automatically splits the text into multiple columns (you chose how many), and includes support for liquid layouts. This means that the content and columns aren’t static; they will automatically adjust as the page is resized. Check out the demonstration page to see what I mean. This script is also works on enough old browsers to actually be usable.

What impressed me most about the script was that it requires very little extra markup. Assuming all of your markup is in some sort of standards compliant state, all that is required is one (or possibly two) extra div tags. Say you wanted to make the following code segment use the multicolumn script:

<h2>Maecenas</h2>
<p>Pellentesque mi. In lacinia iaculis ante.</p>
<h1>Ut dapibus</h1>
<p><em>Nunc non dui.</em> Maecenas quis lacus sed dui commodo elementum.</p>
<p><strong>Pellentesque rhoncus sollicitudin libero. Phasellus nunc risus, tincidunt vel, bibendum eu, molestie ac, tortor. Etiam in felis.</strong></p>
<p><strong><em>Pellentesque id erat. Mauris condimentum pharetra nibh. Fusce sollicitudin auctor tortor. Aliquam placerat,</em></strong></p>

All that needs to be added are two div tags to wrap the content. The first div must also include an id or class name for the JavaScript to hook to. You can use whatever class or id name you want when you implement it. I chose to use id=multicolumn. The finished markup would look like this:

<div class="multicolumn">
  <div>
    <h2>Maecenas</h2>
    <p>Pellentesque mi. In lacinia iaculis ante.</p>
    <h1>Ut dapibus</h1>
    <p><em>Nunc non dui.</em> Maecenas quis lacus sed dui commodo elementum.</p>
    <p><strong>Pellentesque rhoncus sollicitudin libero. Phasellus nunc risus, tincidunt vel, bibendum eu, molestie ac, tortor. Etiam in felis.</strong></p>
    <p><strong><em>Pellentesque id erat. Mauris condimentum pharetra nibh. Fusce sollicitudin auctor tortor. Aliquam placerat,</em></strong></p>
  </div>
</div>

I like the way that looks: clean and simple. You can even use this in in a WordPress template with PHP tags included and everything still works. This is what is actually coded into one of my WordPress template files:

<div class="multicolumn">
  <div>
    <?php ggc_the_long_excerpt(); ?>
    <p class="readmore"><a href="<?php the_permalink() ?>" rel="bookmark" title="Continue Reading <?php the_title_attribute(); ?>">Read More &raquo;</a></p>
  </div>
</div>

My favorite part is what happens when Javascript is not available. In my case, the page still works fine and no content is lost. Sure, there are some rather long line lengths, but everything still works.

<div class="mulitcolumn">
    <p>Some text...</p>
    <p>Some more text</p>
<div>

I wanted to get the div element by searching for the class name multicolulmn. Without thinking, I began writing the code to grab the div using the getElementByClassName function. Then I remembered that getElementByClassName isn’t actually a built-in function. Oh well, Google to the rescue.

I was able to quickly find Robert Nyman’s elegant getElementsByClassName function in The Ultimate GetElementsByClassName.

Using this function, you can get elements like so (examples pulled from Nyman’s site):

// To get all a elements in the document with a “info-links” class.
getElementsByClassName(document, "a", "info-links");

// To get all div elements within the element named “container”, with a “col” and a “left” class.
getElementsByClassName(document.getElementById("container"), "div", ["col", "left"]);

I love it when I don’t have to write my own JavaScript.

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?

After doing some research, I discovered that the bug has been well documented as the “Doubled Float-Margin Bug.” Position Is Everything has a good explanation:

This bug only occurs when the float margin goes in the same direction as the float and is trapped directly between the float and the inside edge of the container box. Any following floats with a similar margin won’t show the doubled margin. Only the first float in any given float row will suffer from the bug. Also, the doubled margin displays symmetry, working the same way to the right as it does to the left.

As it turns out, I didn’t even need to use their recommended fix for the bug. I was able to ax it by just adjusting which elements had the float and margins.

Position Is Everything also contains an entire section IE only bugs. I know this is going to be an invaluable reference for me when I’m trying to track down odd behavior that I’m sure is a bug and need an easy fix.

The second item pertains to Safari 3. Starting with this update, Safari 3 will be the default browser. Now, this is really great, but it introduces some problems with my workflow. If I install this update, how am I going to be able to continue to test my designs in Safari 2.x?

As it turns out, Michel Fortin has gone through the trouble of creating standalone versions of every Safari installment. So go ahead, jump on that update from Apple, then grab a standalone copy of Safari 2.

I particularly like their notebook-style links. The subscribe link is a good example of this (although I can’t actually click on it):

Their site footer also demonstrates a nice use of the “crusty notebook page” style:

It’s a very nice looking site all around.

These is also a section on one way to get customized titles. They use this example:

<title>
    <?php
    if (is_home()) {
        echo bloginfo('name');
    } elseif (is_404()) {
        echo '404 Not Found';
    } elseif (is_category()) {
echo 'Category:'; wp_title('');
} elseif (is_search()) {
    echo 'Search Results';
} elseif ( is_day() || is_month() || is_year() ) {
    echo 'Archives:'; wp_title('');
} else {
    echo wp_title('');
}
?>
</title>

I personally use something similar for this page:

<title>
<?php /* Title for homepage is "blogtitle | blogdescription", all other pages get "pagetitle | blogtitle" */
    if (is_single() || is_page() || is_archive()) { wp_title('',true); echo ' | '; bloginfo('name'); } 
    else { bloginfo('name'); echo ': '; bloginfo('description'); } ?>
</title>

I noticed a couple of days ago that when I tried to post to the site using the Textmate blogging bundle, I was getting the following error at the top of the window.

Received exception:Missing return value!

Normally when you post successfully from TextMate, all sorts of metadata is appended to the top of you post in TextMate, including the permalink for the post. It also automatically opens a new tab to the post in your web browser.

When I started getting this error both the permalink appending and web browser page opening functions stopped working. Oddly enough, the entry was still actually posted to my blog. I immediately assumed that this error had something to do with the new tagging features and that maybe the TextMate blogging bundle wasn’t quite up to snuff. No problem, Google to the rescue.

Amazingly, my Google searches turned up almost nothing useful on the subject. Eventually, I recovered one tiny little detail using “wordpress 2.3 xmlrpc error” as my search term.

The solution appears in a comment by Daniel Jalkut on the Red Sweater Blog.

…my first reaction when I see that kind of vague error is that a plugin in your WordPress installation is incompatible with WP 2.3. By any chance are you running the Google Sitemap Generator plugin? It’s one that has been identified by a few users as needing update after going to 2.3. See:

http://www.red-sweater.com/forums/viewtopic.php?id=424

If you’re not running that, it could be another plugin. Generally the “XML-RPC Response Parsing Failed” happens when some plugin causes the entire fetch to fail, so WordPress just returns a blank response instead of an XML document.

While the error in question was actually somewhat different than mine, I do in fact use the Google Sitemap plugin. I disabled the plugin and tried posting again. Bingo, problem solved.

UPDATE: The version of the Google Sitemap plugin that was giving me this problem was 2.7.1. My WordPress install indicated that there wasn’t an update for this plugin, but when I actually went to the site I found that there was one. The new version is 3.0.1 and seems to work fine. The admin interface also looks much better.

Visual integration with Windows and OS X is our primary objective for the Firefox 3 refresh.

This is great news for Firefox, because as I have mentioned before, its user interface has really been the achilles’ heel of the browser, especially on the Mac.

Mozilla’s user experience team literally wants to do a better job of visually integrating with Windows than IE, and a better job of visually integrating with OS X than Safari. I don’t know if we will be able to pull that off, but that’s the goal.

I’m glad that they’ve recognized this as an issue and I can’t wait to see what they come up with. If Firefox actually did look as good or better than Safari on a Mac, I might use it as my primary browser.

Via Beauty And The Geek: Firefox 3′s Visual Makeover.