Author: James

Post revisions in WordPress are a great idea in principle, but I can’t stand them and the fact you can’t disable or change the save interval via the Settings page is a real oversight. Not only do they take up unnecessary space in the database they also slow down your site because of it. How many times have you spent a fair amount of time editing a new post because of a spelling error or changing a sentence?

If you’re like me, more than a few.

Having revisions save every single time you you do something may not be your cup of tea so here are a couple of things you can do to change their behavior or disable them altogether.

Disable WordPress Post Revisions

Add this line to your wp-config.php file, located in the WordPress root directory, to disable revisions.

define('WP_POST_REVISIONS', false );

Limit WordPress Post Revision Count

If you just prefer to just limit how many revisions WordPress maintains add the following to your wp-config.php file, located in the WordPress root directory. Just change the value to the number you want to maintain.

define('WP_POST_REVISIONS', 10 );

Delete Existing WordPress Post Revisions

To delete any past revisions you will need to delete those directly from the database. To do this you will need to access your database via phpMyAdmin or a SQL Editor and running the following query.

This is a fairly old video but whilst playing Black Ops II last night I was reminded of it because a lobby I was playing in was lagging so bad the game was almost unplayable. It’s stupid I know, that a game can get you so worked up that you want to throw your controller at the TV but seriously, when you’ve got a guy dead to rights only to have him disappear and reappear a split second later in a different position that allows him to kill you instead… well, yeah… makes you want to suck his heart out through the internet…

I spent a fair amount of time today hunting for a decent way to force Zend Framework 1.11 to use SSL. Sadly, there was no simple answer that completely worked, so after scamming pieces parts from a number of Google searches I came up with my own solution.

The task, to force all HTTP calls to HTTPS, however, I might only want to secure selected modules/controllers in the future. My solution.

I’m forever trying to remember command line commands for Linux or Mac OS X. I picked up this list a while ago and keep around in a text file but decided to post it here so I can get to it whenever I don’t have my laptop with me. Some of the commands are bash built-in commands but most will work on either OS. Feel free to add to the list.

I’ll admit, I’m about as lazy a blogger as they come and when it comes to scheduling posts to be published in the future I really despise having to decide on what day and at what time the post should appear. After hacking a few other scripts to do something very similar I ran across a plugin called Date/Time Now Button created by someone named radiok. After checking it out I found it was pretty close to what I wanted but didn’t perform a random set. Since radiok already had the javascript worked out I just “adapted” that code to work the way I wanted it to.

Schedule Random Post Time adds a button to the post, page and comments that allows you to generate a random publish date. This plugin is useful for us lazy people that would rather not take the time trying to decide what date and time in the future to schedule a post for. Simply click the button and let it decide for you. It’s pretty simple really. Simply set the maximum number of hours into the future you want posts scheduled for in the settings, then just click the button and a random date between current time and your future time will be generated for you. Easy Peasy.

All three of the major search engines offer some kind of website service. The most popular being Google Webmaster Tools. Yahoo offers Site Explorer and Bing has Webmaster Center. All three require that you verify your site and offer various methods to do so. This plugin uses the meta option and inserts a meta tag in your sites section of your site.

If you’ve used WordPress.com then this will look familiar since it’s based on that tool.

What do I do with the code once I have it?
All you need is the actual content= code, the plugin will automatically format the meta tag when it inserts it.
Ex.: Google will give you a piece of code like this: <meta name='google-site-verification' content='dBw5CvburAxi537Rp9qi5uG2174Vb6JwHwIRwPSLIK8'>
You want to copy the code: dBw5CvburAxi537Rp9qi5uG2174Vb6JwHwIRwPSLIK8 and paste it in the input box for Google.

I’m using WPMU but I don’t want the plugin automatically activated for each site. Can I just put it in the wp-content/plugins directory so each blog owner can choose whether or not they want it activated?
WPMU is no longer supported but the plugin should work fine with WordPress in network mode.

Support
If you like this plugin and want to support me, leave a comment or check out my donations and support page!

One of the primary tasks my new J.O.B. requires is determining the development direction for a new SaaS product. On the surface it’s a relatively simple concept, capture client information send it off to a vendor via EDI formatted message and receive a result via the same. Process that result and do it again. On paper, it sounds simple. Why then has it been made to be so blasted complicated that several developers have worked on it and gotten nowhere?

Now that this puppy is mine to deal with I’m look at starting over from scratch. One thing I detest is picking up where someone else left off. Since we are primarily a PHP shop for our web development I’m comfortable staying in that arena, but like anything else, I don’t want to waste a bunch of time having to create what ultimately amounts to a framework to manage all the tedious things every app has to deal with (user management, security, session management, templating).

So I’ve spent a good deal of time looking at the various PHP frameworks out there but I’ve decided that only two are really worth the effort. Zend or Code Igniter. Zend is the obvious choice, because it’s less a framework than it is a collection of libraries. The major downside to Zend is obviously the learning curve and while CI that’s still an issue with CI, from what I can tell the curve isn’t quite as long as it is with Zend.

That said, Zend is most likely overkill for what I’m looking to build at the moment, but I also foresee a near term future that includes rebuilding some current fat client applications to be more web based thus requiring the need of multiple PHP programmers, as well as, I’m sure some requirement that the app I’m currently working on be able to integrate to some degree with that future.

The whole thought process here is the fact that I really am not a fan of any of the frameworks. However I also despise continually creating functions that do the same things over and over again. I also do not want to have to worry with maintaining a core framework myself. I’d much rather be able to just drop-in a module to update some functionality and not worry about having to build it myself. Plus, I like the idea of having a coding standard enforced on all developers, something else I despised from past endeavors. There’s also some concern over licensing, etc., with Zend there’s a high confidence that we’ll not run into any future legal issues, some of the other frameworks don’t give me that same warm and fuzzy.

So there’s my dilemma. Any thoughts on one vs the other? Rolling your own?

I’ve seen this one around the net many times but it’s funny every time I read it. Parent’s this is why you get gray hair.

The boss of a big company needed to call one of his employees about an urgent problem with one of the main computers. He dialed the employee’s home phone number and was greeted with a child’s whispered, “Hello?”

Feeling put out at the inconvenience of having to talk to a youngster the boss asked, “Is your Daddy home?”

“Yes”, whispered the small voice.

“May I talk with him?” the man asked.

To the surprise of the boss, the small voice whispered, “No.”

Wanting to talk with an adult, the boss asked, “Is your Mommy there?”

“Yes”, came the answer. “May I talk with her?”

Again the small voice whispered, “No”.

Knowing that it was not likely that a young child would be left home alone, the boss decided he would just leave a message with the person who should be there watching over the child. “Is there anyone there besides you?”, the boss asked the child.

“Yes” whispered the child, “A policeman.”

Wondering what a cop would be doing at his employee’s home, the boss asked, “May I speak with the policeman”?

“No, he’s busy”, whispered the child.

“Busy doing what?, asked the boss.

“Talking to Daddy and Mommy and the Fireman,” came the whispered answer.

Growing concerned and even worried as he heard what sounded like a helicopter through the ear piece on the phone the boss asked, “What is that noise?”

“A hello-copper”, answered the whispering voice.

“What is going on there?”, asked the boss, now alarmed.

In an awed whispering voice the child answered, “The search team just landed the hello-copper.”

Alarmed, concerned and more than just a little frustrated the boss asked, “Why are they there”?

Still whispering, the young voice replied along with a muffled giggle….

Thank you for requesting to have a discussion with me about this topic. Discussions are a dialog between people in which the participants are willing to alter their position if it makes sense to do so. Sometimes, people confuse “discussion” with “sermon” or “lecture”. These non-discussions are a waste of time since all parties are intractable in the their existing views.

So that our time is not wasted please use this guide to determine whether we can actually have a discussion about this topic.

On of the most annoying things I find about WordPress Plugins is that once you decide you no longer want to use one, simply deactivating the plugin, in most cases, still leaves behind a bunch of garbage in your database. Maybe you like to test a plugin to see what it does or maybe it sounded great but in reality it wasn’t quite what you were after. So you deactivate it and/or delete it thinking it’s gone right? Usually not. You might be left with altered database tables, indexes which now make your database inefficient, various settings and options that are now orphaned.

I recently decided I didn’t want to be part of this crowd. I wanted to give a reasonable option to my plugin users to 100% completely uninstall a plugin if they so chose. After a little research and some tweaking here’s what I came up with. It’s really rather simple.

There are 3 parts.
1. The uninstall form
2. The check for the uninstall submission
3. The uninstall itself

So here we go. First you need to create an uninstall form in your plugin. As you can see in the picture, I include a check box the user must check to confirm they want to uninstall the plugin. The form should look something like:

<form method="post">
<input id="plugin" name="plugin" type="hidden" value="plugin/plugin.php" />
if ( isset( $_POST['uninstall'] ) && ! isset( $_POST['uninstall_confirm'] ) ) {
You must check the confirm box before continuing.
}
The options for this plugin are not removed on deactivation to ensure that no data is lost unintentionally.
If you wish to remove all plugin information for your database be sure to run this uninstall utility first.
<input name="uninstall_confirm" type="checkbox" value="1" />Please confirm before proceeding
<input class="button-secondary" name="uninstall" type="submit" value="Uninstall" />
</form>

I like to wrap this in a function called pluginname_form_uninstall() to prevent conflicts then add that to the plugin options screen. Next we need to check to see if the form was submitted.

Somewhere near the top of the plugin or before execution starts add a check of the $_POST vars to see if our uninstall option was submitted. If it was we call the third piece of this puzzle, the uninstall function itself.

function pluginname_uninstall() {
delete_option( 'plugin_version' );
delete_option( 'plugin_options' );
// This is where you would remove and tables, indexes or fields you added when your plugin was first activated. Also anything else that caused modification to the database should be undone here.
// Do not change (this deactivates the plugin)
$current = get_settings('active_plugins');
array_splice($current, array_search( $_POST['plugin'], $current), 1 ); // Array-function!
update_option('active_plugins', $current);
header('Location: plugins.php?deactivate=true');
}

This is pretty simple but it depends on what you’ve added to the database.

First use the delete_option function to remove any settings added to the wp_options table.

Next undo any SQL modification you made when your plugin was created. Any tables, fields or indexes added need to be removed or changed like your plugin was never there.

The final part deactivates the plugin and switches the user to the plugins management screen.

At this point the plugin can be activated again or deleted.

As you can this this really is fairly simple, I’m not why more developers don’t use something similar to this. I for one can’t stand to have a cluttered up database of things I don’t need.