I Am Blogie

The 13th major update of WordPress is finally here! A little late coming, but more than welcome to all WordPress lovers. As I’ve mentioned before, it’s the merger of the two branches of WordPress and now it’s multi-site enabled.

I’m working on a Web project that’s built on WordPress 3.0 and that will take advantage of its multi-site functionality. It’s already live but not yet completed, and it’s on MINDANAW.net. It’ll be a site that will let dedicated bloggers of Mindanao have their own subdomained blogs. I’m still working on which plugins to deploy, as well as collecting WordPress themes (so far I’ve included free themes from Woothemes.com).

There’s going to be a catch, though: only blogs that commit to helping Mindanao, in one way or another, will be accepted. The service will be offered free of charge — just as long as the bloggers on board join the community in the advocacy of promoting peace & development in the Philippine South. I’ll announce the site’s launch once it’s ready via the Mindanao Bloggers Community site.

Kudos to Matt and his Automattic team for Thelonious (click the link to see a video of WP3.0).

A few days ago I changed the permalink structure on my Davao Delicious blog from /%category%/%postname%/ to /%year%/%category%/%postname%/. As of this writing, that blog has a PageRank of 4 and a lot of the posts and pages are indexed by Google. Some might say my move was risky because it would cause my blog to lose some Google love juice… But, there’s a documented case against having the %category% slug as the first part of your blog URL (after the domain name, that is).

DavaoDeli.com

You see, I wanted my food blog to have a logical URL system, wherein my readers would know right away what type of food establishment they were reading about just by looking at the URL. For example, when I’d write about a coffee establishment, the resulting URL would be http://www.davaodeli.com/coffee-shop/name-of-the-cafe/. But, the WordPress experts have said that using the category name as the first part of the permalink is a bad idea.

WordPress stores URL rewrite rules in the site’s database (is this a good idea?) — the instructions to form the pretty URLs your blog gets for your posts, pages and attachments (i.e., the dedicated page displaying an image attached to a post). In a nutshell, the problem is a performance issue: when %category% is used at the start of the permalink structure, the database table containing the above-mentioned rewrite rules get overloaded with hundreds of lines of instructions. The cause is the way WordPress interprets each post’s, page’s and attachment’s URL. Here’s something from the WP Codex:

For performance reasons, it is not a good idea to start your permalink structure with the category, tag, author, or postname fields. The reason is that these are text fields, and using them at the beginning of your permalink structure it takes more time for WordPress to distinguish your Post URLs from Page URLs (which always use the text “page slug” as the URL), and to compensate, WordPress stores a lot of extra information in its database (so much that sites with lots of Pages have experienced difficulties). So, it is best to start your permalink structure with a numeric field, such as the year or post ID. See wp-testers discussion of this topic.

So, in order to optimize my blog’s performance, what I did was to change DavaoDeli.com’s permalink structure to include %year% at the beginning, but still retaining the category name. For example:

http://www.davaodeli.com/2010/general/attention-davao-caterers/

When updating permalinks, WordPress automatically redirects old URLs to the new ones. If, for example, another site has a link to one of my blog posts using the old URL, click-throughs will correctly resolve to the new URL. The question is, how will Google treat my blog now?

Hopefully, having a well-maintained sitemap (c/o the Google XML Sitemap plugin) will ensure that my blog’s posts and pages will remain in Google’s index. I wonder, though, if I need to declare 301 redirects for all my blog’s posts and pages in the .htaccess file…?

Some of my blogs were recently hacked into, so I decided to implement this particular security measure that I’d long heard of but never really bothered to get around doing. The hacking attempts are what’s termed as zero-day SQL injection attacks. Basically, two things happened:

• In several blogs of mine, users with admin access were inserted without my knowledge.
• In one blog, a number of my latest posts were deleted at the application level (not the database level) — meaning, the posts were erased manually, presumably because they were able to gain access to my dashboard with admin rights. (Good thing WP has a recycle bin!)

What I did was to change all my database tables’ prefix from wp_ to something else (for our purposes, let’s use “somethingelse_“). According to some WordPress plugin developers, having your database tables named with a prefix other than wp_ increases your site’s security by preventing malicious insertions. Simply put, hackers out there know that WordPress db tables are prefixed by “wp_” by default, so that it’s fairly easy for them to create scripts that can wreak havoc in your database.

So then, this is what I did for all my blogs. I renamed all my databases’ tables (wp_options, wp_users, wp_posts, etc.) so that they would all have a new prefix. I even went as far as using a different prefix for each database. Then, so that WordPress would know what the new prefix was, I redeclared it in wp-config.php. Like so:

[php num=51 highlight_lines="58" toolbar="false"] /**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each a
* unique prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = 'somethingelse_';
?>[/php]

I made a rather serious mistake, though. What I actually did was to download the database from phpMyAdmin (using the prescribed db backup procedure) and modify the downloaded .sql file. I used a text editor to rename all references to wp_ to somethingelse_. Then, I dropped the tables from the database and inserted new ones using the modified backup. Problem was, I also inadvertently renamed some database meta keys in the somethingelse_postmeta table, which caused some rather alarming changes to my blogs. For example, the meta keys _wp_attachment_file and _wp_attachment_metadata were also renamed to “_somethingelse_attachment_file” and “_somethingelse_attachment_metadata”. That caused all my images to lose their meta information and resulted in WordPress not knowing which thumbnails were associated with which images anymore! Solution: I renamed all instances of _somethingelse_ back to “_wp_” in the somethingelse_postmeta table.

Something else happened that confirmed to me that the hacking was a zero-day SQL injection attack. Just when I completed the renaming of my database tables for all my WordPress installations, one of the databases suddenly acquired a new set of tables!! There they were, new tables prefixed by wp_ alongside the real db tables. The wp_users table contained an admin user with a bogus email address — imagine what those hackers could’ve done to my blog if I hadn’t implemented this security measure. How my databases were intruded upon, however, still remains a mystery as of press time…

N.B.: While you should be aware that the meta keys in the somethingelse_postmeta table should remain with their _wp_ prefixes, the meta keys in the somethingelse_usermeta table should be prefixed by whatever new prefix name you’ve chosen. And, there is an entry in the somethingelse_options table that’s originally called wp_user_roles. If you do change your table prefix to something else, make sure that that entry is also renamed to somethingelse_user_roles.

The process is quite involved, I know. But this security measure is urgently recommended if you mean to keep your WordPress installation(s) safe from hacking attempts.

And then, there it was! WordPress 2.9 is now officially released and available for upgrade (and first-time installation).

I’m posting this on v2.9, and I must say, it feels like the purr of a well-oiled machine. The “Move to Trash” link and the fact that WordPress now has a global trash bin make for more peace of mind. The media-handling capabilities, as well, give the new version an even cooler CMS experience.

WP2.9 ships with quite a number of under-the-hood enhancements, or improvements to the code, in other words. It’s exciting to see how plugin developers and theme authors will take advantage of these new tools at their disposal. I’m especially eager to see what my favorite theme developers, WooThemes, will dish out in the next couple of weeks.

Upgrade to WordPress 2.9 now!

WordPress 2.9 is now on RC-1 status, and it’s been announced that the brand-new version will most likely be released to the world by the end of the week.

As expected, we’ll see major enhancements to the way WordPress handles media files. Beta-testing v2.9 RC-1, I’ve seen those cool new features, such as on-the-fly image editing (crop, rotate, flip, resize), and more meta data (separate alt caption texts), among others.

What I’ve been wanting for the longest time, which will now be available in v2.9, is a gallery option that lets you exclude images from being displayed when using the [gallery] shortcode. Sometimes it’s necessary to display a post’s gallery of images, but with one or a few images left out. For example, you have a restaurant review post with a number of foodnographic shots, plus the logo of the restaurant. You might want to display the food photos as thumbnails (gallery-style), but without the resto logo, which you’ll probably place at the top of the post.

For this purpose, WP2.9 will let you use the exclude switch inside the shortcode. Problem is — and I hope they fix this — this is to be inserted manually into the [gallery] shortcode; no menu item for this yet in the gallery’s user interface. And, the usage is still rather cryptic. After a brief hit-and-miss session, I finally figured out that the value that the exclude option accepts is the post ID of the image (not the post’s ID where the image is attached). To wit:

[gallery exclude="##"]
(For excluding multiple images: separate ## values with a comma.)

WordPress stores images’ meta data in the wp_posts database table (assuming you didn’t change the WP prefix in wp-config.php), so that each uploaded image gets its own unique ID. There is as yet no way to see images’ IDs within WordPress — I had to browse the database table via PHPMyAdmin to check for them.

(There is also an include switch, and I suppose this is for manually including images attached to other posts.)

What’s more, v2.9 will now have a recycle bin for posts, pages, attachments and comments. How many times have you deleted a post or a comment and regretted it?

There are a host of enhancements and additions to this awesomest of content management systems, some major and some cosmetic (including a much-improved default first post upon installation). RC-1 is pretty stable already, so if you’re feeling adventurous, why don’t you download and play around with it now?

Kudos to Automattic for an exciting new version!

Related posts:

1. Shortlinks for posts
2. Permalinks and SEO
3. Zero-day SQL injection attacks