visnum

When you are on a shared server, you don’t need to pay attention to how much server resources your WordPress installation utilizes. Your hosting company pays attention to that and notifies you when some code go berserk and ends up eating too much cpu or something like that. However, on a cloud computing environment like media temple’s grid server, you have to be careful with how your WordPress installation uses server resources. Your hosting company won’t notify you until the resource consumption goes abnormally high. That’s not bad, so you don’t want to be notified everytime you use more cpu than normal because we are in the year 2008 and we may need server resources for many of the applications we use.

On the other hand, when time passes and your blog starts to get extraordinary attention, you may want to learn tips and tricks on how to optimize your wordpress installation and how to minimize resources it uses. Here are tips and tricks about just that.

First and foremost, you must use caching. WP-Super Cache is the best option for that. WP Super Cache caches your posts and pages as beautiful pure html files so your server doesn’t use resources for php output. Other caching plugins don’t do that (at least I don’t know of any other). Others usually just caches the content and continues to use php cycles to deliver output.

The second important thing you have to keep in mind is that WordPress’ custom 404 (page not found thingie) handler uses too much cpu cycles. This isn’t unique to WordPress. Any other CMS like Drupal, TextPattern, etc. who uses custom 404 handling also uses more cpu cycles than any normal, usual 404 page. What to do about that? Use Google Site Maps plugin in order to inform Google faster when you have deleted a post. This plugin automatically generates a Google compliant site map and submits that to Google everytime you make a change in your content. Apart from that, there are also urls that are seeked by robots and they also can generate 404 error codes when not found. One example in my mind now is the favicon.ico file. Favicons are used by many web sites for bookmarking urls. You have to place one in your root directory because every robot I know looks at your root directory for that file. Moreover, not only robots look for favicon.ico but also many browsers look for it when users want to bookmark your blog. Many modern browsers also look for it because they display it in the tab. The best practice is, go create one and place it in your root folder. Favicon.cc is my favorite place for creating favicons and downloading them into my computer and then put them on my host. It’s very practical and free.

Same holds true for your feeds. Use Feedburner for distributing your feeds. Since your feeds will be distributed by feedburner and not by your server, you will have this load minimized too. Your domain.com/feed will be checked (almost) only by Feedburner and this is at most once or twice a day.

There may be other examples for would be 404 files that don’t come with your WordPress installation. You can make up your own examples too. Either way, you have to find a way to create them or handle them. So far, I don’t know of any plugin which handles that issue. Maybe it’s a good idea to build one. It should check for common known urls on your blog which may be requested often by robots, search engines, and like, and maybe creates them for you.

Third, comment spam also puts another weight on your WordPress installation and that eats your valuable CPU cycles too. Akismet is NOT a solution for this because a comment or a trackback or a pingback will hit your server and be recorded for evaluation anyway. WP Spam Free solves this problem by not allowing comments from agents which are not a browser. Since many bots who works for dropping spam comments and trackbacks to WordPress blogs do not recognize and use JavaScript, this plugin checks whether comment owner’s agent can recognize javascript. It’s a wise solution. It also informs normal users who turned javascript off so that they don’t get surprised when they are not able to post comments.

Those three factors are what I have experienced so far with my grid server. I think this can be the first post in a series because as time goes by I would experience new cpu cycle hungry factors and find solutions about them. So I’ll post them too. One thing I am not sure about is wp-cron.php and admin-ajax.php files. It looks weird but it seems like they eat more cpu cycles when you don’t post frequently. But this is just a guess. I’ll post about that too when I am sure of them. So, please subscribe to my RSS feed if you find this post useful, there are more to come.

A couple of days ago, I had to transfer a post from one of my blogs to wordpress.com for mirroring purposes. This may be something you will rarely need but it happens. I had a post which became very popular and at the time I transferred the post there was 900 plus comments in that post. Handling huge amount of comments in WordPress is another issue, I’ll try to mention that later in this post but now I will move on to ‘how i did it’ section.

I created another user in my WordPress installation. That’s very easy, you just go to users on the right of the WordPress admin menu and add a new user, of course with a different name than yours. You can also set its password and other details there but that part is irrelevant with what we are going to do. Then go to post(s) you want to export exclusively and edit them by changing their author. You can do that in the post editing page below the editor.

Then go to ‘manage’ and select export. There, you will have the option of restricting posts you will export to a certain author. Select your newly created author for exporting his posts. Then click ‘download export file’ and you are done. You have an export file where your selected posts are included. Now you can use that file for importing them on any other WordPress blog provided that they have the proper version of WordPress, I mean supporting this export - import thing.

For more practical options, when you need a temporary place to export & import your posts, just use WordPress.com. Go to WordPress.com and create a new blog for just that. Don’t forget to set privacy options there so you don’t have duplicate content in case search engine robots hit your carrier blog at the time. It may be also proper to close the blog for normal visitors too, according to what you do with that blog.

Using a WordPress.com blog is especially a necessity when you transfer posts from Blogger (blogspot) to WordPress because self hosted WordPress still lacks that functionality. The option is there but it doesn’t work (taking about 2.6.2 at the time of this writing).

Well, it’s that easy. Now let’s discuss the scalability of WordPress when it comes to hundreds of comments. In my case, WordPress was not able to handle them for me. Both the amount of comments (900 plus) and the traffic was heavy on that single page. There wasn’t any issue with the server. The traffic and the server load this page created was equal to any page that would receive the same amount of traffic and attention. Pagination of comments is a solution but it didn’t work for me because I find existing plugins immature. The only solution to this in the future might be that WordPress have built-in, nature pagination feature for comments, like in Drupal. Most probably that was why Dooce made the switch to Drupal from WordPress. She opens her posts to discussion rarely (only every four or five posts) and she receives thousands of comments under those posts.

If your receive less than 100 comments on your posts than WordPress is scalable for your in termes of comment load handling. But if your receive hundreds of comments on each of your post than WordPress may not be the best option for you. Of course there are ways for handling this however a naked WordPress installation is just not sufficient to handle 1000 comments effectively.

Let’s go back to our transfer business. That’s how I did it. I mirrored the post with all the comments to a WordPress.com blog and everybody looks happy now. Don’t forget to close comments and pings while you start exporting those posts because it is very possible to receive comments after you have started the export process and those comments will get lost.

Another tip: I copied everything for that post. The text, the url and the exact date and time. Then I have recreated the same post with the same url with the same date and time. Then I closed the post for comments and only opened them for pings. I also stated in a single comment that discussion is now going on in another address, in a mirror. Now, things are fine. Everybody is happy, including me.

One last thing that I have learned from this experience: It is a wise thing to close comments after a period of time you have published a post. I think one month is convenient. Otherwise, the post’s comments turn into a forum instead of a discussion of what you have written.

I am very upset about this sad realization. For the last couple of days, I was working on the design & development of a new blog. I will not name it now, it is still full of test posts and therefore it would be really meaningless to link to it right now. Anyway, I had a couple of options. To look for a nice wp-theme and fiddle it, to play with the default or classic themes and create a new look and functionality out of them or, finally, write one from scratch. The last option is the wisest option however it has been nearly 1 year that I haven’t been interested in any piece of wordpress code. So, I was also not familiar with versions newer than 2.0.x. Therefore I first opted for the second solution and started tweaking the default theme.

The default wordpress theme is a great failure. It is of course very famous because it is the default wordpress theme. First off all, it is not standards compliant. Especially the order and usage of CSS selectors are catastrophic. I will only name one for now. There is this header part, then there is this blog name section which correctly marked as h1. But then there is this description section marked as a div. This is the most common failure among amateur “web masters” who are just introduced to web standards. The description section should have been coded as a p class=”description” or p id=”description”. There is no need for a div. This is a big error but this is maybe the smallest semantic error in the whole wordpress default theme.

The CSS file is exactly a turmoil. There are many classes identified more than once and that makes it very confusing to work with them. The use of ems are a complete failure. So much that when you change an h2’s em value, it shows up in different sizes gradually. No, of course I am talking about the same class of h2! It is in the commentlist section. Go see it for yourself. Change the em value there, for instance change the em of h2 from 1.2em into 1.6em, it ends up showing growing sizes as comments continue.

And no, I am not using Internet Explorer. I am testing everything on Firefox 3, Internet Explorer 7, Konqueror (Safari), Internet Explorer 6, respectively. I can’t waste my time to tell all the errors in this default themes CSS file. I want to go into some other catastrophe that the web suffers because of those default and classic wordpress themes.

Many advanced wordpress themes are built by tweaking the default one or the classic one. And that’s a good thing, because once they put those two templates into wordpress core and ship them together, there is no reason as not to be sure about they are the right thing to go from. However, unless you strip all the CSS at once and start writing CSS from scratch by using selectors and classes from the template source, it is impossible to produce a coherent design. It’s awful. Look at the CSS file of the theme “White as Milk”. The author clearly state it in the CSS file as a comment:

THE FOLLOWING CODE IS DERIVED FROM THE DEFAULT “KUBRICK” THEME.

THE STRUCTURE AND LAYOUT IS IN MY OPINION, NOT THE WAY CSS SHOULD

BE ORGANIZED, BUT FOR NOW I AM LEAVING IT THE WAY IT IS TO KEEP

IT CONSISTENT.

As a matter of fact, since almost all themes are derived from the classic or default layouts, it is almost impossible to change and tweak them for the majority. It’s not sufficient to know CSS, you have to master it to a degree where you can find some other people’s errors in it and fix them.

The classic template is not as faulty as the default template but it is also very deceiving. For instance, it doesn’t have a real footer where stands below all the content and sidebar. Instead, the footer stands just under the content. It is not compatible with the widget functionality of a standard wordpress installation. Even not with the latest version shipped!

Briefly, this is a shame. Many wordpress users just think that they don’t know enough CSS. They are wrong. CSS is in fact quite easy but it depends on good mark-up on the template side, and clearly written CSS files. The beauty of CSS and web standards is in their usability, easiness, practicality.

I don’t think that those faulty history of the default and classic templates of wordpress is going to end here. They couldn’t fix it for years right now. It looks like they are even not aware of what is wrong. The turmoil still continues with K2.

I had to heavily tweak the default template files on a very detailed level. This was meaningless. This can be a whole lot better.

I hope somebody pays attention to work on a such important issue.