When I initially started out with using VPS, I had tons of problems with Apache but quickly switched to Nginx which has proven to be more than a boon, because it meant that I could do more with less. However, having used WordPress I have come to know that the system is not necessarily scalable in itself when it comes to self-hosted websites.

In the past, I have written about the architecture that powers Techie Buzz and several guides like Scaling WordPress Using MySQL Replication and HyperDB and setting up memcache with WordPress among others.

However, over time, I have learned quite a few things about managing WordPress for a website with heavy traffic and also sorted out several issues which had become a bottleneck for us.

One of the biggest issues I have faced over time with WordPress is the database. More often than not WordPress websites work slower than expected because of the MySQL database and heavy load on it. However, many a times a simple change in MySQL could speed up the website considerably.

The default engine (not forced by WordPress) while installing WordPress is MyISAM for most hosting companies. The problem with MyISAM is that it locks the entire table when it inserts or updates rows. This in turn locks other queries which are accessing the same table slowing down the entire website in the process.

For example, when you are updating a post, you will be updating the wp_posts table and during this update all other select, insert, update and delete queries will be queued till the insert/update query completes. This in itself should not be a big problem when you have a site with less traffic. However, it does make a big impact when you have a large website with multiple queries being run every minute or so.

So what is the solution for this? Well, the best I could implement was switching the tables with the frequent queries to InnoDB. InnoDB is a storage engine in MySQL which might become the default one in future MySQL versions. With an InnoDB table the queries don’t lock the entire table, but just lock a single row it is inserting/updating. This leaves the other queries to complete without having to wait in a queue.

Making this small change has definitely made life easier for us. Along with our other caching mechanisms we now have almost 0 load on our database, which is definitely a great thing.

While this has definitely been helpful for us, I would suggest that you spend some time reading up the differences between MyISAM and InnoDB and their advantages and disadvantages before you make the move. Once you are convinced that you are ready to migrate, head over to my earlier guide on how to safely and easily migrate tables from MyISAM to InnoDB Engine.

Since the time that I have run this site, I have had my fights with keeping the website running smoothly. However, over time, I have identified several areas we need to improve on and one of them has been MySQL.

The problem I have had with MySQL is whether to use the MyISAM engine or the InnoDB engine. I have more recently tilted towards using InnoDB more often than not because of the advantages it has for a high traffic website. Though, I won’t go over the advantages in detail here, I might ask you to read my article on why we switched to InnoDB.

Nevertheless, here is a quick and easy tutorial on how to switch from a MyISAM engine to a InnoDB engine safely and easily. You can run these queries on the command prompt or use a GUI like PHP MyAdmin as well. However, you must note that the data in your MyISAM table might not be similar to your new table due to frequent updates and you might want to plan downtime so that you don’t lose data or have to sync the tables again.

So without further ado, here are the steps:

Create a Replica Table

The first step is to create a replica table of the one you want to switch the engines for, for that run the query given below. Make sure to replace the table names as appropriate.

CREATE TABLE new_table LIKE old_table;

Once you have run this query you’ll have a new table which has the same schema as the older table and you are already on your way.

Drop FULLTEXT Indexes in New Table

The biggest difference, if you measure it that way is that InnoDB tables do not support FULLTEXT indexes. So before we do anything else you will have to drop the FULLTEXT indexes from the table you just created. To do that follow the steps given below.

Run the query:

SHOW INDEX from new_table where index_type=’FULLTEXT’;

Drop individual indexes from the query (rename indexname for the index you want to drop):

ALTER TABLE new_table DROP INDEX indexname;

Once you have done that, you are now ready to move your MyISAM table to the InnoDB engine. So lets get ahead with it.

Moving MyISAM Table to InnoDB Engine

The next move is to update the Engine of your MySQL table to InnoDB. For that, you will have to run the following query:

ALTER TABLE new_table ENGINE = InnoDB;

That’s it. You now have the new table in InnoDB format, now you just need to move the data.

Move Data From Old Table to New Table

You will need to move the data from the old table to the new table. To do that, run the following query:

INSERT new_table SELECT * FROM old_table;

And the data is finally there. The last but not the least step is to switch between your older MyISAM table to your new InnoDB table.

Rename Old Table to Backup and New Table to Old

Run the following queries to rename your tables:

Rename Table old_table TO old_table_backup;

Rename Table new_table TO old_table;

That’s it. You have now successfully migrated your MyISAM table to the InnoDB engine while having a backup which you can quickly switch to by renaming the backup table again.

Google Everywhere

It is hard to go online today without touching one or more Google products or services. If it is not search, it may be email, YouTube, Blogger, Picasa, Docs, or Calendar. Google has truly blanketed us with their web-based app offerings. Heck, even the Google Doodle is a conversation topic!

In this editorial, I shall discuss how you can kick the Google habit, what I am using now as alternatives and why you probably won’t be able to replace certain Google products today. Ready to move away from Google? First, some background.

Why un-Google?

Some of the reasons I personally decided to look for alternatives:

• Google became a part of virtually everything I did online. I used GMail, Google Reader, Google Finance, Blogger, Picasa, Picasa Web, Google Docs, Google Search, Google Calendar and Google Maps. I felt uncomfortable putting such a large portion of my online life in Google’s hands.
• Google morphed from the cool little startup building fun stuff for consumers, to a dominant public company whose revenues essentially came from just one product. That’s the key most (96%) of its revenues (and profits) came from search advertising. In other words, it needed other ways to make money. The most obvious way to do so would be to extend the arm of advertising, their main revenue-generating product, into other products. I realized I was the merchandise.
• Google seemed to get Apple and Facebook envy. Apple was growing rapidly across all their product lines and at very high profit margins, and Facebook was taking eyeballs and key talent away from Google. This led to some bad attempts to mock Apple and Facebook publicly, which of course delighted the Google developer and enthusiast community but came off as being negative to me. If you make a great product, you don’t need a negative campaign.
• Aside from philosophy, some of the competing products started becoming better, and Google’s products started getting worse (more on that within my descriptions) prompting me to start Project Un-Google which was an effort to use fewer and fewer Google products, hopefully reaching a point where I did not depend on any Google product at all.

Whether it is for philosophy, or hedging your web app bets, it is good to know there is life outside Google when it comes to products and services online and offline. There is usually a strong resistance to change, especially if you have a long history with a product. There is a high cost for transferring the old stuff, and learning your way around a new product/service. However, these challenges are not insurmountable, and I hope you take a look at some or all of the products I list here as an alternative to Google. If you have ideas of other products I may not have mentioned, please let me know!

Popular Google products

Here are some of the Google products/services I will be comparing to competition:

• Search
• Picasa
• GMail
• Calendar
• Documents
• Groups
• Finance
• Blogger
• Chrome
• Maps/Directions
• Talk/Chat/Voice

I realize Google has many more products, appsand services, but I did not look at products like Book Search which are very niche. My attempt here is to look at the commonly used products and services only.

I have always been in awe of WordPress and have come to love it since I started using it few years back. However, one of the biggest problems I have had with WordPress is their search; both in the frontend as well as in the backend.

While you can always improve your frontend search and add relevancy to it by either using Google Custom Search or a plugin like Better Search, there are not many options for the backend, or at-least my searches led me to few or none.

My dislike for the WordPress backend search grew more when I wanted to search for some articles which had a particular title but could never see them in the results for my queries. However, I did find a really good alternative after spending a decent amount of time searching for it on Google.

The extension called Search Regex is quite a life saver and is definitely better than the default WordPress backend search for posts. The plugin allows you to search only titles, within posts and comments, post meta values, post excerpts, post URLs and more.

One of the first things I noticed with the plugin was that it works really well and does it’s job. However, as always humans are usually never satisfied with what they get and so was I. I would have loved the plugin to integrate and replace the default backend search in WordPress and would like to have it on the WordPress Edit posts page itself. The reason for this is that, the way the plugin currently works, you can only edit a single post at a time.

On the other hand, WordPress backend search allows users to edit multiple posts at once. Other than this, the plugin also allows you to Search and Replace text within your posts. This can come in very handy if you want to update a link or text in a post. Best of all, the plugin supports regex (Regular Expression). However, I would avoid using that because it could really create problems if something goes wrong or you use a bad regex, in-fact the plugin itself advices you about it.

Rest assured, Search Regex is an excellent plugin to address the annoyance called "WordPress Search". Go ahead and download it from here, you won’t be disappointed at all.

If your WordPress theme uses a TimThumb library or you are manually using the TimThumb script on your site’s template, stop reading this article and remove the script right now. Your website is in a state of serious security risk, as anyone can upload and execute arbitrary PHP code in your TimThumb cache directory.

About TimThumb:   TimThumb is a PHP script used for cropping, zooming and dynamically resizing images on websites. While TimThumb can be used on any website, it is ideal for blogs and other websites who use templates and themes (self hosted WordPress blogs, for example). Using TimThumb, you can dynamically fetch a cached copy of an image and proportionally resize it to fit in your blog template. Thumbnails, profile picture of users and signature images are typical examples where TimThumb script is used. Whilst TimThumb has found a home in WordPress themes, it is by no means limited to them – TimThumb can be used on any website to resize almost any image.

Here is how the TimThumb script works under normal conditions:

You get the TimThumb script from Google Code, upload it to a directory of your webserver, specify a cache directory and call the code from the source of your template. There are a lot of parameters which can be used with TimThumb, it depends on the requirements of your website and how you want to scale internal as well as external images.

Once your script is in place, it will continue to work in the background and store a copy of the original image in the cache folder. So if you are scaling a really large image to 100 X 100 using TimThumb, an exact match copy of the image will be saved in the cache folder. This image will be shown to your website visitors.

And here is how the recent TimThumb vulnerability goes to work.

Since the cache directory is public and is accessible to anyone visiting the website, an attacker can compromise your site by figuring out a way to get TimThumb to fetch a PHP file and put that file in the same directory. Now since the cache directory is preconfigured to execute any file ending with a .PHP extension, you are trapped.

The only way this security vulnerability can be avoided is to explicitly modify the permissions of the cache directory and tell your web server not to execute .PHP files from TimThumb’s cache directory. But in case of WordPress blogs and other websites, almost every web server is preconfigured to execute .PHP files on any directory.

Mark Maunder, discovered the problem when his own blog got hacked due to this TimThumb exploit. The hacker uploaded a file in the cache folder of Mark’s web server and added a malicious code with a base64_decode. Suddenly ads were popping out on every page of Mark’s website, the results could have been more alarmic. Some common possibilities are – serving malicious content, redirecting to a random website, loading advertisements or putting up a fake login page for users.

How To Keep Your Website Safe From TimThumb’s Security Exploit

There are quite a number of ways you can avoid such situations on your website.

1. Don’t use the script at all: This is probably the best and recommended option for anyone who don’t know how to tweak the WordPress theme of his site. Ask your theme developer to permanently remove TimThumb script from your WordPress theme or find the files which are calling that TimThumb script. Delete those codes and don’t forget to delete the TimThumb directory as well (be careful, take a backup of your theme first).

2. TimThumb is not exclusive: There are quite a number of alternatives to consider. For example: you can use jquery plugins to resize internal images on your website.

3. Patch it: If You must use the TimThumb Script, first patch the script to it’s latest version. Before using the script, open the timthumb.php file for editing, jump to line number 27 and remove the options for $allowedSites. The array should have no elements and it should look something like this:

//external domains that are allowed to be displayed on your website
$allowedSites = array();

Save the file and upload it back. This will disable timthumb.php’s ability to load images from external sites and the attacker wont be able to compromise your site using an external image

4. HTACCESS: Open up Notepad and dump the following code in it:

Options -ExecCGI
AddHandler cgi-script .php .pl .py .jsp .asp .htm .shtml .sh .cgi

Save the file as .HTACCESS and upload it to TimThumb’s cache folder (remember to save as All Files and not as a text file). This HTACCESS file will prevent PHP and other scripting languages from being executed and anyone trying to access the files will get a 403 forbidden access denied message.

5. Why not WordPress? WordPress already has a very decent image handling system and there is a chance that you might not need TimThumb in the first place. The way WordPress handles images is far more secure, never creates cached files or writes them to a directory and keeps the images in the same place where they were uploaded by default. And since WordPress releases security and feature enhancements on a time to time basis, your WordPress powered functions will automatically stay secure as you update WordPress.

Ben Gillbanks, the developer of TimThumb is working on a fix and a more secured version of TimThumb should be released soon. [changelog is here]

Bonus tip: Unless you know the code and their corresponding output, never use free WordPress themes  for your site. A lot of them contain base_64 decoded codes embedded within the source, which can hurt in more ways than one.

WordPress.com has finally joined the Kill Internet Explorerbandwagon.

I don’t remember when was the last time I used Internet Explorer 6, which is surely the most ugly browser built till date. If you read blogs, keep an eye on emerging technologies and trends, chances are that you hate Internet Explorer 6 as much as we do. On the flip side, if you’re reading this page from a never to upgradecomputer running Windows 98 or Windows XP, there is a high chance that you’re using Internet Explorer 6.

In recent months, a lot of sites (e.g YouTube) have been dropping support for Internet Explorer 6. The fact of the matter is that IE6′s rendering engine is half blind and it’s such a pain for developers and designers to fix browser compatibility of their websites, just because a portion of their users are still on IE6 and god knows whether they will upgrade to Windows 7 or use a different browser anytime soon.

WordPress.com has recently announced that they are ending support for Internet Explorer 6 with their slight redesign and performance improvements implemented on WordPress.com’s dashboard. The blogging platform says that it has required increasingly complex code trickery to make WordPress.com’s backend work in Internet Explorer 6, which does not support current web standards.

If you try to login to your blog’s administration area using Internet explorer 6, WordPress.com will let you in. It’s just that the features will appear broken and all the links won’t work the way they used to work before. Oh and you will also see a big red alert box, begging you to upgrade Internet Explorer 6 to it’s latest version.

Additionally, WordPress.com has introduced some new features as well as dropping older ones. The new dashboard loads faster and feels better, distracting icons are gone while a new distraction free write post panel being introduced.

According to the data from Microsoft’s own IE6 countdown website, 11.4% of web users are still using Internet Explorer 6, the highest user density being recorded near China, South Korea and Japan. The following chart shows a brief usage graph of IE6 from around the world:

It’s good to see more and more websites joining hands to drop support for Internet Explorer 6.   This helps everyone if you consider the bigger picture users can enjoy all the rich features of a modern browser while the devs can sleep well and avoid coding nightmares.

The WordPress team started planning for WordPress 3.2 back in March and released WordPress 3.2 beta last week. I spend some time playing around with the next generation of WordPress to see what is new with it.

Here is a review of WordPress 3.2 and a list of the new features that you will be using when the final version comes out. Please note that WordPress 3.2 will require PHP 5.2.4 and  MySQL 5.0, so you might have to upgrade your server software or ask your hosting provider to do it for you.

Important Note: This is a beta version of WordPress, don’t install it on a production server.

New Admin Interface

WordPress 3.2 has a refreshed admin interface which does away with the curved corners and cuts down on the space used between the menus.

The last major version of WordPress; WordPress 3.1  was released back in February and the team had already begun planning for  WordPress 3.2 back in March.

It looks like most of those plans are now finally beginning to take shape with the release of WordPress 3.2 Beta 1. WordPress 3.2 will contain several new changes including dropping support for older technologies like PHP4 and MySQL4 among other things. WordPress 3.2 requires PHP 5.2.4 and MySQL 5.0 to run.

In addition to that, WordPress 3.2 will also stop supporting Internet Explorer 6. Users browsing the site through IE6 will be shown a message to switch their browsers.

WordPress 3.2 also includes several performance improvements which make it faster than the earlier version. One more new addition that will be liked by users is the inclusion of Distraction-free Writing in the visual editor. Additionally, WordPress 3.2 includes a refresh to the Admin UI and a new default theme called Twenty Eleven. It will also include more links in the admin bar, however, you can always disable or hide the Admin bar in WordPress if you don’t like it.

Overall the changes look pretty decent and should make the next generation of WordPress better than its predecessor. I will be doing a full review of WordPress 3.2 shortly, so stay tuned for it.

Here are some of the major changes that are included in WordPress 3.2:

• Performance improvements like you wouldn’t believe. What’s that mean? Things are faster!
• Distraction-free Writing. The visual editor’s full-screen composing experience has gotten a major overhaul, and is now available from HTML mode, too. More than ever, WordPress allows you to focus on what matters most — your content.
• Admin UI Refresh. The last major redesign of the WordPress admin was in 2008. This isn’t a major redesign, just a little facelift to keep us feeling young. WordPress turns 8 later this month, you know.
• New Default Theme. Introducing Twenty Eleven, based on the popular Duster theme. Rotating header images, post format support, and more.
• Browse Happy. WordPress is made to work with modern browsers. If you visit your Dashboard using an outdated web browser, we’ll let you know there’s a newer version available.
• Admin Bar. We’ve added more links to the admin bar to make it even more useful.
• WordPress has new minimum system requirements: PHP 5.2.4 and MySQL 5.0.
• Internet Explorer 6 will no longer be supported.
• The favorites menu has been removed. If you’ve written any plugins that use this menu, it’s time to switch over to an admin bar placement.

You can download WordPress 3.2 Beta 1 from here.

A few days ago, I spoke about the architecture that powers Techie Buzz. In that post, I had mentioned that memcached was one of our key ingredients.

Memcache is a powerful tool to share objects across servers and it is used by several big sites including Facebook, Yahoo and many more. The best part about using memcached on your server is that you can cut down on your database queries significantly and store commonly used objects in memory and share it across multiple servers.

If you use WordPress on a multi-server setup, you can easily cut down on DB queries by up-to 50% by implementing memcached. If you are interested in knowing how to implement memcached on your server, here is a tutorial. The assumption is that you are using Ubuntu, if not, the installation steps might change.

How To Install Memcached And Configure It

Step 1: Install memcached using the command given below

sudo apt-get install memcached

Step 2: After you have installed memcached you will have to configure it through a .conf file, to do that use the command given below

vi /etc/memcached.conf

Step 3: In the configuration file you will find few parameters, you can ignore the -d, -u and logfile parameters and leave it as default. However, change the -m, -p and -i parameters to suit your servers. The -m parameter specifies the memory that will be allocated to memcache. The -p parameter specifies the port that memcached will run on and the -l (ell) parameter specifies the IP address the memcached server will run on. You will need to change the -l (ell) parameter value from 127.0.0.1 to a local or global IP address of your server. This is necessary because your memcached server will be accessed by outside servers and using 127.0.0.1 will not work then.

Once you have done that run the following command.

service memcached restart or /etc/init.d/memcached restart

Using Memcached With WordPress

Once you have setup your memcached server, it is time to now setup WordPress to use memcached to store your objects. To do that, head over to http://wordpress.org/extend/plugins/memcached/ and install the memcached plugin for WordPress. Unlike other plugins, you will have to drop this file into the wp-content directory and not the plugins directory.

You will have to install additional plugins for your server to make use of this plugin, namely PECL memcache extension which can be downloaded from http://pecl.php.net/package/memcache.

Now comes the part where you will actually tell WordPress to use memcached as an object storing mechanism. To do that, open the wp-config file and add the line below to it.

global $memcached_servers;
$memcached_servers = array(‘default’ => array(‘memcache-server-ip-or-name:11211′));

The array is used to define multiple memcached servers which can be used for your site. Please make sure to edit the name/ip of the server and the port before you save the file.

That’s it. Now just refresh your cache and WordPress should start storing the objects in memcache and will access your database very sparsely.  Do let me know if you have any problems or difficulties in setting this up through your comments.

Bonus Note: You can browse and manage your memcache server through a WordPress plugin called WP Memcached Manager which can be downloaded at http://wordpress.org/extend/plugins/wp-memcached-manager/.

Earlier today, WordPress.com had a low-level (root) access break-in on several of their servers which hosted WordPress.com websites. According, to a note posted on the WordPress blog, some user data on those servers might have been revealed.

In the post, the founder of WordPress; Matt Mullenweg said that the extent of data breach is not known yet, but they are actively investigating the logs to determine the extent of the breach.

We have been diligently reviewing logs and records about the break-in to determine the extent of the information exposed, and re-securing avenues used to gain access. We presume our source code was exposed and copied. While much of our code is Open Source, there are sensitive bits of our and our partners’ code. Beyond that, however, it appears information disclosed was limited.

Matt did not clearly mention whether user data was compromised, however, he did post suggestions on creating secure passwords (Read our guide on creating secure passwords, creating strong passwords to avoid getting hacked or unique tools to create secure passwords). As an advice, just make sure to changed your WordPress.com password though.

The WordPress developers have already patched the problem, however, the damage might already have been done. We’ll keep you updated with further information on this.