Well, I've done much work over the last several days — no posting but much work nevertheless.

CSS (Cascading Style Sheet)

I finally got around to cleaning up the css for this site. For a long time, I had a style sheet in the header. I had put it there when I couldn't get MSIE and Firefox to see things the way Opera does otherwise. What Opera would obey from an external css, the others would not — at least not consistently.

Well, I consolidated the css into the external file, minified it by removing much white space (down from 14 pages to 4 — or 82 lines), alphabetized it, and put in some comments and removed others, etc. In addition, I cleaned up a number of css errors and added a few enhancements. I could still tweak it more, but the returns are diminishing and I have bigger fish to fry.

Now everything down the left column is much more consistent. Except for the dynamic widgets with their own style sheets, MSIE is now seeing all the links in white with mouseovers and borders. It was a challenge to style the OOIBC (Out of Iraq Bloggers Caucus) blogroll, since is called by Javascript and results in no classes. I wrapped the script in <div> tags in the text widget and gave the <div> its own class.

Updated Copyright

I updated the website copyright. I'm now allowing commercial use so long as there is attribution. I really wouldn't ask for that except it so easy for anyone to do and the idea is for the worthy cause that is the Christian Commons Project™.

Website Translation

Translation is now available in 23 languages; however, I see that the cache is filling with truncated pages. I've requested info from the plugin developer about that. I may change the translation service from Google.

Dynamic Widgets and Widget Caching

Except for the dynamic widgets, they are all being cached now. So the HTML rendering is being cached and the widgets are being cached. That should help speed up page loading. I'm flushing the buffer early too (right after the header). That seems to help.

Browser Cache

Nearly everything is being written to the browser cache on a longer term basis too. That should help people revisiting the site.

There's plenty more to do though. I'll keep pecking away at it.


The error pages finally work. That was a strange thing. I never did find the answer out there anywhere. I had to come up with it myself. I'll share: I added a simple line to the .htaccess file in my root directory so that 500 Internal Server Errors resolve to the 404.php template in the themes I'm using. There's text there to say that both 500 and 404 errors resolve there. Before that, the missing.html file with proper server config still kept given a 500 page with nothing (no links and a generic email address). Now at least all wrong URLs (from the domain up the full path) resolve to the 404.php file. I like that much better. The one line in case you're wondering is very simply: ErrorDocument 500 //index.php?error=404. Of course, one could create a 500.php just for that error, but I didn't do that, obviously. Frankly, 90+% of the Internal Server Errors are just "missing" pages. The line for 404 errors is: ErrorDocument 404 //index.php?error=404. (No period, of course)


I did a bunch of cleanup to the .htaccess file too. As with the css file, I added some helpful comments. .htaccess is a per directory/subdirectory configuration file for UNIX/Linux based servers.

Far Future Expires Headers

It's beyond the scope of this website right now to give tutorials on .htaccess. Besides, I still consider myself quite the novice. There's plenty of info out there on the Web though if you're interested. I will say that I added "future expires headers." I did not opt for what is term "far future expires headers." That's because I don't have control over the external services coming into the website. I can't rename there files to cache new content. If they change their scripts but keep the same name, the old will still be cached and the results could be nonfunctional for visitors. It's a tradeoff to have any such caching at all. It remains to be seen whether even having "expires headers" is a good idea. People who visit and experience problems usually just turn away without informing the webmaster. The stuff is all caching to my browser too, but I have to purge mine fairly often as part of the process of elimination when considering what is causing any errors. I've learned long ago that the last thing one ought to do is a full-system diagnostic and repair before doing some really basic things such as restarting the browser or restarting the computer and reinitializing the router/modem. It's amazing how many things just need that done sometimes twice. Well, emptying the various caches is also one of those easy steps to take. Now I have numerous caches to remember to clean. Each time I test a page to see if I've fixed it, I have to remember the sequence of cleaning those caches too.


I've also configured the ETags and moved the Google Analytics script back to the bottom of the footer. I had moved it up high so Analytics would catch the visitors who leave before the pages are finished. I'm not interested in that anymore. People who can't wait a bit for the overall message of this website aren't going to be the type who would help with the cause anyway. We bring forth in patience. People really seeking will wait to find out. That's how they come to know God better. The instant-gratification crowd never does learn. Short attention spans are the bane of the American consumerists society.


The site was already Gzip enabled.

Components to Subdomains

I don't have very many components loading from the RLCC server, but to get into the right habit, I'll be splitting those components across a few RLCC subdomains — 2 to 4 is recommended. Too many just causes more domain name lookups than any savings that might otherwise result.

Optimize Images

The images should also be optimized. They can be dropped to 256 colors and 8 bits.

Remove Inactive Plugins

Another thing I did that was helpful was move all of my "bad" deactivated plugins to a different directory. I could have killed them (sounds harsh doesn't it — kill it means delete in UNIX speak). I had a list, but it got stepped on (overwritten). I want the names of the plugins so I don't retry any of the same versions. I've tried dozens that just didn't work, so I'm not going to rely on my memory. It's easy to forget a plugin months later after having simply installed it, activated it, and deactivated it just as quickly.

Test on Multiple Browsers

I test on MSIE, Firefox, Opera, and Safari.

Internet Explorer

I can't for the life of me understand why MSIE doesn't redraw the screen at least once every 20 seconds. Waiting for the whole page to load, especially where there are scripts making lots of offsite calls, is a really poor strategy on Microsoft's part. They think redrawing will waste time, but at least people can see that things have happened and are happening still (maybe). Why Microsoft hasn't changed that policy is very strange. Also, MSIE can't scroll down a page to save its life. The others can fly down by comparison.

Firefox, Google Analytics, NoScript

Firefox takes forever to load. I suppose it's on account of all the "add-ons." It sometimes has trouble with Google Analytics and other scripts too. I don't like the popup that keeps saying a script may be hung and do I want to stop it or continue waiting. I ended up loading an add-on that allowed me to let all scripts continue to run but not have to wait for Google Analytics. I didn't bother to look into what the hang-up is.

The add-on is impressive. It's called NoScript.

Firefox does have a number of handy tools written for it. I find though that I can do as much or more with Opera.

Safari Develop

Safari is fast and simple. I haven't looked at all its features. I did turn on the Develop menu in the advanced options settings though (very nice only it doesn't like closing the <hr> tag — XHTML). When there some MS server blocking Opera (very common and deliberate), I use Safari first rather than MSIE. It's just faster.

Opera and Microsoft HTTP Servers

As for Opera, the only problem is with certain Microsoft servers I run into. The advanced developer tools in Opera are going to come in really handy as I work on speeding up the page loading of this site. Opera is just fantastic for testing site changes too. There's nothing faster that I've ever seen. Being able to apply temporary changes via the source code is great. Of course, if you have paid-for software, you might be able to do things WYSIWYG in real time. I use only the free stuff and work only with the raw code.


I'm also using Entrecard now. I've been working with Entrecard behind the scenes a bit trying to help them make it work better with the Opera browser. There are cookie issues.

Link Exchange Program, Link Market

I've also instituted a Link Exchange Program. [I canceled link farming. It's counterproductive these days.] That seems to be working okay. I intend on looking into others as well. I automated it a bit by having using php print the particular link category in the post. It's easier and faster to add to the list that way than it is to open the post editor each time. Little by little, I'm learning more about PHP. It helps.

RSS Subscription to Comments on a Post-by-Post Basis

I created and I added a "Subscribe via RSS to comments for this post only" feature. That should come in handy for people who would rather not give out their email address and who like RSS feed readers better than email for such things. I use both but mostly I see that co.mments has started showing ads. I was wondering when they'd start doing that to help cover overhead. It's a good little system. I'd like to see the ability for users to set cron jobs. If they limited rechecking posts to once a day, that would be fine with me. Some post only need checking once a week or even once a month. The older they get, the less often they might be checked as a rule.

Theme Switcher WP-Cache Problem

(Note: Due to caching conflicts, I've temporarily disabled the WordPress Classic Theme.)

Well, I have it back on again. First let me explain the feature. Then I'll explain the fix.

I just finished adding a new feature (mentioned above):

Select Theme:
RLCC Full-Featured
WordPress Classic

You'll find those words in at the top of the left column. I'll be changing from the WordPress Classic theme to something "proprietary" when I take some extra time to do it. There are just so many things on my To-Do list. Some of them are much more important than that, although I don't want everyone opting for the lite (light) version. Some people though are on slow dialups services and are using old equipment that can't handle all the bells and whistles. It's not their fault. Internet and computers aren't cheap. I know there are plenty of times that I just give up on videos on sites for those reasons (speed and CPU).

The fix:
//wp-content/plugins/wp-cache/wp-cache-phase1.php has to be modified.

// Tom Usher modified /^wordpress|^comment_author_email_/
// to /^wordpress|^wptheme|^comment_author_email_/ to work with Theme Switcher cookie
if (preg_match("/^wordpress|^wptheme|^comment_author_email_/", $key)) {

Note that the double slashes make the lines comment lines. They aren't executed. The third line is executed. So open your wp-cache-phase1.php and search for /^wordpress|^comment_author_email_/

Change that to /^wordpress|^wptheme|^comment_author_email_/

I'd give you the whole PHP file but I'm using one that is just for GoDaddy (the domain name and hosting people). If you're on GoDaddy and receive an Internal Server Error when using WP-Cache, visit givveronline to get the version of WP-Cache that works on GoDaddy. I had patched together the same thing earlier, but it got over written. When I went to find the info again scattered around, I ran into the version already to go (nice).

Technorati Favorites Widget

The Technorati favorites widget was hanging a little (a good 5 to 6 seconds, which can seem like an eternity to people in a hurry for info), so I put the image on our server and just linked to Technorati rather being served via Javascript.

WordPress Dashboard Incoming Links Back to Technorati

I also want to put in a little plug for the people at Technorati. They've been clobbered all over the place. They started sending confirmation emails about tech support tickets. That was a good idea. Why they didn't have those ages ago, I don't know. However, they do respond. I requested a fix for my WordPress (2.6.2) dashboard Incoming Links. I asked them to fix it so my feed from them was based upon freshness. They did it right away.

If you want to use Technorati Incoming Links on your WordPress dashboard, just click the edit button and enter your feed from them. Mine is , so you would just change to your domain. I think it would work without // in there for me, but it works with it so why mess with it? My wordpress is installed in the subdirectory //. Yours may be installed in your http root. Using gets you to my WordPress regardless. I've left it all the way it is even though if I had it to do over again, I probably would install WordPress in a subdomain like However, WordPress is developing so quickly that terming it just a blog may soon be passé, if it isn't already.

  • Subscribe
  • Tom Usher

    About Tom Usher

    Employment: 2008 - present, website developer and writer. 2015 - present, insurance broker. Education: Arizona State University, Bachelor of Science in Political Science. City University of Seattle, graduate studies in Public Administration. Volunteerism: 2007 - present, president of the Real Liberal Christian Church and Christian Commons Project.
    This entry was posted in Uncategorized. Bookmark the permalink.