Subscribe via

3 Web Design Mistakes That You May Need to Fix NOW

In this post I will discuss some of the web design mistakes that I have done on this blog, and what I did to fix them.

A few months ago, I was fortunate enough to get free advice from a friend of mine, Emily Luong, who happens to be a professional graphics designer.  Aside from being a graphics design geek, she’s put in good work on nice sites like Edelbio Skin Care Blog so I do not take her advice lightly.  I asked her to review my blog and what do you know?  It needs improving!

Read on…

Weekend Links #1

Weekend Links for the week ending on 07-11-08

  • WordPress Template Tags Reference Guide: This is the best consolidated WordPress functions reference guide I’ve ever seen. Not only does it have a slick interface, the page shows available functions, its parameters descriptions, and example usage. This is a golden bookmark for anybody who works on WordPress, WordPress Themes, or WordPress plugins.
  • How to Stop Being Invisible: Writing is a difficult task for most, but getting readers for your articles is even more difficult. This post gives insight on why readers read blogs and gives advice on how to make your content more noticeable.
  • 7 Ways To Stay Informed And Up-To-Date Online: Do you ever run out of things to talk about on your blog? I’ve found that I get a lot of blogging inspirations from staying informed. These are a list of tools that you can use to help you stay informed of the latest happenings in your niche.
  • PHP Speedy Turns WordPress Into Speed Demon: Looking for another way to uberize (read as optimize) your WordPress blog? This post talks about the benefits of PHP Speedy and also links you to other how-to-optimize-WordPress posts.
  • Read on…

WP-Super-Cache Released!

What more can I say but “GPL FTW”. This is what happens when you release something under GPL and do not put in much effort in supporting it. Someone else takes it over and releases a better version of your own code leaving the consumers to benefit! Donncha O Chaoimh from Holy Shmoly! released WP-Super-Cache, a WordPress caching plugin built on top of WP-Cache. From Holy Shmoly!, here are the differences between WP-Super-Cache and WP-Cache:

  1. A plugin and hooks system. A common complaint with WP Cache was that hacking was required to make it work nicely with other plugins. Now you can take advantage of the simple plugin system built in to change how or when pages are cached. Use do_cacheaction() and add_cacheaction() like you would with WordPress hooks. Plugins can add their own options to the admin page too.
  2. Works well with WordPress MU in VHOST or non-VHOST configuration. Each blog’s cache files are identified to improve performance.
  3. Normal WP-Cache files are now split in two. Meta files go in their own directory making it much faster to scan and update the cache.
  4. Includes this WP-Cache and protected posts fix.
  5. Automatically disable gzip compression in WordPress instead of dying.
  6. As Akismet and other spam fighting tools have improved, the cache will only be invalidated if a comment is definitely not spam.
  7. Version 0.2 supports gzip compression

Did you see that? Supports gzip compression! Finally, an easy way to enable gzip and WP-Cache. The best part of all of this is that the automatic WP-Cache enabling method still works for this plugin since it was built on top of WP-Cache. I encourage everybody to upgrade!

Make Your WordPress 10X faster During Traffic Storms


This tutorial will augment the technique of automatically enabling WP-Cache during heavy load with the ability to switch to a low-bandwidth WordPress theme at the same time.

Few reasons to do this

1. WP-Cache messes with your site statistics, so you do not want to leave it on when your site is not being hammered.
2. You don’t want to use a bandwidth efficient theme all the time because it’s not pretty-lookin’.
3. During traffic storms (e.g. Digg Effect), every 1/100 second optimization tweak counts.
4. If you host your site on a shared host, you will most likely have a bandwidth quota. Switching to a leaner theme conserves your bandwidth (duh!)
5. If you host your site on a home connection, your upload is not up to par with most hosting services, so you need to use that small pipe efficiently.
6. Each “IMG” tag, even if it’s a 1×1 pixel gif, requires an HTTP request to your web server. If you have 10 images on your page, and 10 users are loading your page, that’s 100 simultaneous calls to your server already. Leaner themes usually means less/no images, giving Apache some break.
7. If you’re server is non-uber, you don’t deserve to administer it.
Read on…

Automatically Turn on WP-Cache During Traffic Storms


I am a semi-fan of WP-Cache. On the good side, it reduces strain on apache by staticising WordPress pages. On the bad side, it messes with my site statistics and makes development hard (I always forget that the page I’m working on is being cached). I like my statistics, but what if I suddenly get a traffic storm? If my site gets dugg, there is no time to worry about statistics. I would need all the help I can get to serve pages efficiently. This is why WP-Cache should be off by default and automatically turned on during traffic storms. Read on…

WP-Cache, the Untold Way to Set It Up

WP-Cache is a WordPress plugin that improves your WordPress speed by caching a static version of each dynamic page request and deliverying that static version for subsequent requests to that page. This in combination with WordPress internal cache, Apache cache, eAccelerator op code cache, and Varnish proxy cache provides the ultimate setup to combat traffic storms if your article gets dugg. *Note* that there is also a method that helps you turn on WP-Cache on demand (only during traffic storms), but I will discuss that in a later article.

If you’ve ever tried to install the WP-Cache plugin for WordPress just by uploading to the wp-content/plugins directory and activating it via WordPress Plugins administration, then you know that 99% of the time that method will not work because of some file permission problems.

Here is the proper way to do it: Read on…

Recapping: Setting up a FreeBSD 6.2 Web Server

I hope I can get some part-time consulting jobs to do this optimization for small businesses. All in all, it doesn’t seem too hard to do and I enjoyed doing it. If you run into a problem just google it for the answer. Anyway, here is the recap of the steps I took to set up my FreeBSD 6.2 Web Server.

  1. Installing OS
  2. Setting Up Apache, MySQL, and Other Services
  3. Migrating WordPress from WinXP to FreeBSD
  4. Optimizing Apache
  5. Optimizing MySQL
  6. Optimizing PHP
  7. Proxy Caching
  8. Optimizing WordPress with WP-Cache
  9. Keeping Your FreeBSD Ports Up-to-Date Effortlessly
  10. Setting Up Sendmail on FreeBSD 6.2

Setting up a FreeBSD 6.2 Web Server: Proxy Caching (Part 7)

Okay I lied, eAccelerator gives a pretty darn high ROI, but setting up a proxy cache gives a comparable or higher ROI. I chose to use Varnish as my proxy cache.

Once installed, Varnish will keep a cache of all objects requested by internet users (e.g. post-generated PHP pages, CSS, javascripts, images) with the goal of off-loading some work from your web server (remember: we won’t want big Apache to do the work only if it has to). Also Varnish takes full advantage of the OS’s virtual memory and advanced I/O features on FreeBSD 6.x making it the optimal choice for my setup.

There were many confusing instructions on the web about how to configure Varnish. Here are the steps I took to setting up Varnish for a signal machine running both Varnish and the web server: Read on…

Setting up a FreeBSD 6.2 Web Server: Optimizing PHP (Part 6)

Comments Off on Setting up a FreeBSD 6.2 Web Server: Optimizing PHP (Part 6)

This was by far the easiest step in my optimization process. To optimize PHP, I used the software called eAccelerator. Compared to all of the other steps, this one had the best ROI for me.

When a PHP script is executed, the PHP interpreter will spend some time interpreting the script then compile the interpretations into opcodes for execution. eAccelerator will precompile your PHP code into ready executable opcodes and manage that opcode cache for you. If your PHP script does not change, Apache will directly call the precompiled opcodes (saving interpretation and compilation time).

This is what I did to set it up: Read on…

Setting up a FreeBSD 6.2 Web Server: Optimizing MySQL (Part 5)

Similar to Apache, you do not want MySQL to start hogging all the memory in your system. To configure your MySQL settings, open your /etc/my.cnf file for editing. Under the [mysqld] section of the file modify the following variables: Read on…