Chris K Designs

I’ve updated the Better AdSense Targeting plugin to allow users to specify in-line post content that should be ignored using the and tags. An example would be like the following:

I would like this to not be ignored content. I think it’s relevant to my topic.

This however isn’t necessarily relevant, is an analogy, or contains some keywords I’d rather not have used when determining my ads

But this I would like to have included…

What the plugin will do is replace the tags with the proper HTML to notify Google’s AdSense to ignore it. The rest of the plugin works as it has been, this is the only update but will allow users to fine tune their ad results.

It’s available now via WordPress.org or your WordPress Admin area. Comments are closed on this post, however if you have any issues please comment over at the Better AdSense Targeting plugin page.

Recently I posted about how to clean house on your tag taxonomy in WordPress. I thought I might also suggest two plugins that will help you keep your WordPress MySQL database a little cleaner and a little faster. With the introduction of WordPress’ revision system, each time you edit a post or page, an entry is made into the database. While this can be helpful during the editing/revision process, after the post is live and no longer in review, the list of rows in the database can grow to the 100′s for each post depending on how many time it was edited. This leaves us with what is called ‘Overhead’.  Here’s what the fine people over at Stackoverflow had to say about overhead:

Every database will, over time, require some form of maintenance to keep it at an optimalperformance level. Purging deleted rows, resequencing, compressing, managing index paths, defragmenting, etc. is what is known as OPTIMIZATION in mysql and other terms in other databases. For example, IBM DB2/400 calls it REORGANIZE PHYSICAL FILE MEMBER.

It’s kind of like changing the oil in your car or getting a tune-up. You may think you really don’t have to, but by doing so your car runs much better, you get better gas mileage, etc. A car that gets lots of mileage requires tune-ups more often. A database that gets heavy use requires the same. If you are doing a lot of UPDATE and/or DELETE operations, and especially if your tables have variable length columns (VARCHAR, TEXT, etc), you need to keep ‘er tuned up.

So how can we keep this to a minimum? There two plugins I recommend and use to keep my overhead to a minimum.

Delete-Revision – Download

Alright, apart from a little translation issue in some of the buttons, this plugin has done it’s job for me. Heck, even in the less than 30 minutes I’ve spent writing this, I already have 2 revisions just for this post.

Delete Pesky and unwanted revisions from old posts.

I’m not going to delete these revisions just yet, I would never delete a revision from an article I’m currently working on. But just yesterday I removed about 100 revisions from the database. That’s 100 rows in the posts table I don’t have to worry about. I strongly recomend that if you are going to be deleting things from the database, that you make a backup. I use a Cron script to optimize and backup. If you are a multi-author blog with quite a few posts going on at the same time, I might suggest that you coordinate a time for this action, when no one is in the middle of authoring. Just setup a time of about 20 minutes each week that you can go in and clean house on revisions. After you delete them, I then recommend the next plugin.

Optimize DB – Download

This plugin shows up in your ‘Tools’ menu and gives you a snapshot of the size of your database, as well as the amount of overhead that currently exists. With the click of a button that says ‘Optimize’ you can reduce the overhead and clean up those nasty bits of data left over.

The main screen of Optimize DB

You might be saying at this point that 7.1 KB of overhead isn’t that bad right? Well keep in mind that I run a few automated Cron scripts to optimize my databases every Sunday evening. At times, depending on the work I’ve done throughout the week, this can be an overhead of up to 512kb which in the scheme of things, is about 1/3 of my total database in overhead. Yikes!

Hopefully these two plugins will give you a little more control over the mess that can become your WordPress database. I wish you happy optimization and low overheads .

Cheers!

The battle at hand (plugins versus performance) doesn’t usually become a concern until it’s too late. However, with a little preparation, research, and knowledge you can have the functionality you want out of your WordPress site, with as little impact to performance as possible. With the ability to extend the functionality of your WordPress site at a moment’s notice using plugins, it’s no mystery why WordPress and it’s plugins have become so popular. From the perspective of a publisher, using the platform is a dream come true. Unfortunately, as with all things, the more complexity you put into the mix, the greater possibility of complications.

How Does a WordPress Plugin Work?
You may have quite a few plugins already installed on your current WordPress site. But, do you know what exactly is happening for those plugins to work? Breaking it down into the simplest form, a plugin for WordPress works by taking advantage of what are called “Hooks.” A Hook is a predetermined point in the WordPress framework at which a plugin developer can add new functionality or modify and remove current WordPress functionality. Some WordPress plugins use settings to determine the output it creates. These settings are stored in the database table, containing all of the settings for WordPress, called wp_options (or in a multisite environment wp_sitenumber_options). As WordPress goes through it’s standard process to deliver content, it stops at each one of these Hooks and checks to see if a function has been associated with it, and if so, runs the function.
Continue reading “Plugins vs. Performance: Fight!” »

If you have been using WordPress for quite some time, no doubt that you have built up quite a collection of tags and categories. If you’ve ever wanted to clean a little house with your tags, you can do it quick and easy if given access to your MySQL command line interface. The following command will remove all tags that have a post count of “0″ (meaning no posts are using these tags).

DELETE t.*, tx.*
FROM wp_terms t, wp_term_taxonomy tx
WHERE t.term_id = tx.term_id
AND tx.taxonomy = "post_tag"
AND tx.count = "0";

Want to remove any tags that are only being used in 1 post or less? Simple, use the following:

DELETE t.*, tx.*
FROM wp_terms t, wp_term_taxonomy tx
WHERE t.term_id = tx.term_id
AND tx.taxonomy = "post_tag"
AND tx.count < "2";

Now go to your Post Tags management screen and look on in amazement as you now have a manageable number of tags. Keep in mind that this is irreversible, once you run this query...those tags are long gone and will have to be recreated.

When you are writing a WordPress plugin, you are more than likely going to have some sort of settings involved. These options are stored in the wp_options (or wp_blog id_options for multi site users) table of your database. Most of today’s WordPress users aren’t privy to the fact that every plugin they install, probably has something within their database taking up space. Some of the sites I’ve seen have over 50 plugins installed that, at one point or another, were activated. That’s 50+ possible rows in the database of options that may not be needed anymore if the plugin developer didn’t remove the options from the database upon deactivation.

The goal of every plugin should be optimal user experience without affecting the overall performance of the users site. In order to provide this experience you should have a set of ‘default’ settings for your plugin. These option settings should be set upon activation. This provides users with immediate gratification, and who doesn’t like instant gratification? Likewise, if someone chooses to deactivate your plugin and delete it, you should no longer be leaving an imprint on their configuration.
Continue reading “WordPress Dev 101: Setting Activation/Deactivation options [updated]” »