I for one would love to work on an office with other Austin WordPress professional. I’ve made 90% of my living these past 10 months working on WordPress client project and do not intend to stop anytime soon.

A WordPress professional office could be something like the co-working locations that are now springing up in cities all across the nation. This would be somewhat different in that instead of everyone working on a broad range of projects, everyone would be working on WordPress client projects. From a collaboration perspective this could be huge.

I’ve had a chance to roll this around in my head a few time and have started thinking about some of the downside issue for me.

• Considering the current state of real estate in general, finding a short-term lease location in central Austin might be an issue.
• what will be the user cost of this venture? Will I be locked into a lease commitment for space in the office?
• Why would I want to consider this option if I can work for free out of my house already? Meaning I’d need to drive to an office to do basically the same think I can do at home. I do realize the upside is the potential collaboration with Andy and other Austin WordPress professionals. Question is if it’s enough of a consistent gain. Can the same or similar collaboration be gained from the wp-hackers mailing list?
• What will be the price of gasoline by the time this concept is realized? Considering gas in Austin is now $4.00/gallon what is my added (if any) cost for driving into an office 3-5 days a week?

In case you’ve not seen the story, it’s about Minister Joe Barron, from a very large church in Dallas who drove nearly 200 miles to meet a 13-year-old girl supposedly for sex. The girl was fake. She was setup as part of a sting operation. For the past few months the minister and girl have exchanged messages about sex and other topics. The minister solicited her to meet in person. He was picked up last week.

My problem is not the article as a whole nor the actual alleged crime. I’m well aware what people are capable of be it a religions figure or your next door neighbor. What really upset me was a comment made in the article by Rev. Jack Graham, pastor of Prestonwood Baptist Church. The same church where Minister Joe Barron was also employed. Upon reading this part of the story I almost feel sorry for the fallen minister.

The quote is

“you need to know that we are appalled and we are disgraced by this terrible action, an unacceptable action, by a minister on our staff.”

I consider myself a well rounded person in the area of general religion and faith. I’m under the impression that most faiths offer some resolution for things done wrong no matter what. Sure attempting to sleep with an underaged girl it dead wrong, no question. But so are many other things like adultery and stealing. The tone of the Reverend’s comment is such it makes me think he has totally written off Joe Barron as if he is never to be heard from again. I would expect to see a little more compassion and faith from the leader of the church flock.

Maybe is was just his words to the press to enforce that the church also thinks the act is wrong. Something like a moral cover. I’m sorry it just disgusts me.

Architectural Improvements

On the architectural side one big improvement was made in the way the plugin created new Revisions of content. In the old version of the plugin a revision was made too late on the post update process after the user clicked the Save/Publish buttons. Effectively the updated post content and the latest revision were the same. In the newer version of the plugin the revision is generated earlier in the WP core processing. This mean we can take a copy of the post content before it is updated by WP core. This means the latest revision is the real previous version of the content.

UI Improvements

For the UI changes there are quite a few.

1. Above the revision listing I added two new checkboxes, Minor Edit and a Revisions Status. The Minor Edit checkbox is a single-use option to tell the plugin NOT to generate a new revision when you save the post item. This functions like most wikis. The Revisions Status allow you to totally disable revision generation for the post. This is handy if you just don’t want to use revisions on certain post items. Or if you are like me trying to make some complex edits and just want to disable new revisions because you will be making a dozen or so minor edits. So you can turn it off make you changes then turn it back on.
2. I’ve added logic to limit the display of revisions to the last 5 items. Below the list of revisions is a link. When you click this link the page will slide to reveal the older revisions.
3. Added checkboxes at each revision to allow deletions. This is pretty handy is you just want to clean house. Not that if you delete revision 5 of 8 the numbering will NOT re sequence itself. But if you delete the latest revision then the revision number will be reused.
4. On WP 2.5 and higher I added the Minor Edit and Revision Status checkboxes to the sidebar. This will make it easier to set the checkboxes to keep from scrolling to the bottom of the editor form. And with some jQuery magic when the sidebar checkboxes are set the lower checkboxes are also set.

Future Changes

I still have a long list of changes I’m reviewing for possible inclusionin future releases.

1. One change was submitted that included actual changes to plugin to support versioning categories and tags. This was great. But I’m still holding on the change. In my view categories and tags are not as volatile as text content. Beside if a revision used a category that had since been deleted what should the action be?
2. How to handle delete of the main post/page. Currently the plugin will delete all revisions when the parent post/page is deleted. I don’t like this. I want to build an interface to allow recreation of a post from a revision.

I also have some other small items on the list but they are not work mentioning. If you have any other suggestions please feel free to send them my way.

Download

You can download version 1.8 of the Revisions plugin from the WordPress.org plugin repository.

Over the past year I’ve worked on twenty different client projects. Each one a little similar yet each one a little different. On most the client wanted only a certain category listed on the front page. After many checks on the different versions of WordPress, I’ve not found a ’standard’ way of doing this via the default WordPress admin interface. Sure on the Options -> Reading page you can select a Page or Latest Posts to display. But if you need to limit the display on the Front page to say just the News category you are out of luck.

One solution that works very well is to hook into the WP query object to intercept the ‘action’ in WordPress. All it takes is a simple function and filter added to your theme’s function.php file. Something like the following.


// Used to limit the categories displayed on the home page. Simple
function myHomePostsFilter($query)
{
if ($query->is_home)
{
$query->set('cat','1');
}
return $query;
}
add_filter('pre_get_posts','myHomePostsFilter');


If you are not familiar with WordPress filters let me provide some overview. The function takes a single parameter, This is the reference to the WP Query object (see /includes/query.php from the WordPress engine code). Don’t worry about the details as you will not be calling this function directly. This function will be called when WordPress is preparing a query for some display of information via another function call. Inside the function you will see the ‘if ($query->is_home)’. The ‘is_home’ is a built-in WordPress action. for Categories there are 5 total. They are ‘is_home’, ‘is_list’, ‘is_search’, ‘is_feed’ and ‘is_archive’. In our example above I’m only concerned with the ‘is_home’. So if the query is being built for the Home/Front page the if is true so the next line is executed. The next line ‘$query->set(’cat’,'1′);’ sets the query category to the one cat_id I’m interested in. For the example this is cat_id=1. If needed I could have added more than one category as in ‘$query->set(’cat’,'1,5,15,36,285′);’. I could also exclude categories from the category list simply by preceding the cat_id with a minus as in ‘$query->set(’cat’,'-1, -16, -32′);’. The next line returns the query back to the calling function. Then end of function. So far this is just a standalone function. Now we have to tell WordPress we want it to hit our function. This is the last line. A filter in WordPress can be thought of as a ’subscribe’ action. The first parameter of the filter. Tells WordPress you want to subscribe to a certain action. In our case this is ‘pre_get_posts’. See this Codex page on Custom Queries. Scroll down to the section header ‘Category Exclusion’. Our filter basically tells WordPress ‘before you run the query hit our function first’. This give our function to massage the parameters to adjust the query. Done. This works for most versions of WordPress 2.x up to the latest and greatest (2.3.1 as of this entry). Pretty simple.

But sadly this cat_id is hard-coded into the functions.php file. So if this is your blog and you have control of the admin keys to the kingdom you can stop reading. I mean it takes all of two seconds to adjust the value of the cat_ids you wish to include/exclude. But what if you are knocking out a project for a client. A client you don’t really want to hit you up every time they need to exclude/include a category from some WordPress action like ‘keep the category X from showing on the Home page’. You have a choice. You can document for the user how to make edits to the functions.php file and hope they don’t somehow screw the code up.

Or you can look for some plugin that will do this or you. I can tell you I’ve looked through various plugins. Only really found one that came close to making this somewhat automated. And that plugin stopped working at WordPress 2.1. Something about the very complicate queries it was building. After reading through 300 line of it’s code just for the query logic I dropped it. I mean the 8 lines of code I provided above are really all you need for the logic portion to include/exclude cat_ids. Why go through the twisted query logic that didn’t run until after the page was loaded. This in effect caused two queries to be executed.

So I started writing my own. Something simple. I just wanted a list of the categories and the available options or WordPress ‘actions’. Let the user select the action for the category and go. I’ve produced something functional. It’s in the very early stages of work. I’ve also included a section for Pages. for Pages I’ve only worked through the logic for the ‘is_search’ action. For both Categories and Pages the user has the option of including or excluding for the actions.

Here is a screenshot of the SimplyExclude Category admin page. It’s the same for the Pages but just for search action.

So download the SimplyExclude Plugin for WordPress v0.1. It’s version 0.1 0.2 but I plan adding more bling soon. I’ve tested this on the latest 2.3.1 engine only. If you are running this and have trouble please feel free to contact me for help.

Update

After entering this post and sending a similar response to someone on the wp-hackers list it occurred to me that for Pages there should be an option on the Page editor that allows the exclusion of the page from the Search actions. So took some time this evening to update the plugin to version 0.2 (W00t!). So not only will the Pages be listed under the plugin’s options. But along the right sidebar on the Page editor look for the ‘Exclude from Search’ dropdown option. Both options update the same information.
See the screenshot below for what it appears like.

Download SimplyExclude Plugin for WordPress v0.2

Update 2008-04-27

After some comment I took another look at the plugin code. Seems I provided the version for WordPress before 2.3. The new version now works all the way up to WordPress 2.5.1. Also, I’ve relabeled ‘List’ to ‘Archive’. I’ve also added logic for tags inclusion/exclusion. This works the same way as Categories. The tags admin menu only works under WordPress 2.3 and higher.

Download SimplyExclude Plugin for WordPress

Also upcoming is a better Category and Tags display listing. I’ve received some comments that users want to see the display nested similar to other parts of the WordPress admin interface.

Update 2008-07-16

Seems some of the WordPress 2.6 changes do in fact effect the way the plugin stores it’s options. I have a fixed version but due to technical (or accounting) I’m having trouble updating the plugin into the main repository. You can download version 1.7.1 here. I’ll update the plugin into the repository when WordPress gets things worked out.

simply-exclude-v171

Introducing a new plugin, Revisions

Design

The Revisions plugin is based on a very old plugin, Bliki (Blog + Wiki), written by the fine folks at Automattic. There are a few other good versioning plugins out there. But in my opinion they all offer too many admin bells and whistles like Version Diff-ing, Funky rollback schemes, Complicated admin interfaces, etc.

Sticking with my ‘Simple’ philosophy, I’ve opted to cut the functionality to the necessities. The Revisions plugin provides the user with three specific types of integrated functionality.

1. The ability to create a backup of the edited Post/Page. This is built-in once the plugin is activated.
2. The ability to view a Revision just as you would preview a Post in the Theme.
3. The ability to reset or rollback a version into the admin editor

Below is a screen capture of the Revision section that is added to the Admin editor screens. This is a screen of 2.5 but looks just the same under pre-2.5 versions of WordPress.

From the screen image you can see there are 3 Revisions to this one Post. Each Revision notes the version number, the time of the Revision and by what author. Below each Revision items is a link ‘View Revision’. This will display a themed version of Revision. There is also a second link that will load the Revision content into the Post/Page editor. Once reloaded the author can Save or make changes to the content. This reload and save will generate a new Revision. In other words the original Revision will remain intact.

Installation

Download the Revisions plugin. Unzip it. Upload the ‘Revisions’ folder to the plugins folder of your WordPress site. Once uploaded go to Manage -> Plugins and activate the plugin. That is it. Now when you make a change to any Post or Page the version is saved. A suggestion is to perform a Save on an existing Post or Page first before starting to make changes. I’ve tested this plugin on WordPress 2.5 down to 2.0.3.

Future Plans

As I mentioned this plugin is basic on purpose. One feature I might be adding in the near future is the ability to delete individual Revisions. Sometime while you are in the Edit & Save cycle you can build up a few unnecessary Revisions. Another possible option will be to define a threshold for comparing the new version to the next previous Revision. If the amount change is below the threshold the Revision is not saved. This would prevent some very minor Revisions.

Enjoy.

One thing I noticed along with my friend Rick Benavidez. Considering the massive gathering or designer and developer talent during SXSWi and that 90% (my estimate) of attendees as well as panelist use MacBooks or MacBookPro laptops. We have to ask “Where the hell is Apple?”

Why are they not a major sponsor in the conference? Maybe they supporting but for some reason just not advertised. Yeah right.

Do you have any proof of Apple at SXSWi? Pass it on Please

In more recent projects I’m been hired to make changes to an existing client WordPress site. Many of these project involve upgrading WordPress from some version 2 years ago to the most current. Not knowing the previous developer’s changes this has always been a concern of mine since a flat upgrade would mean potentially killing custom changes to some of the core files. So going in I will normally zip the entire tree of files. And pull a dump of the database just to be safe. Then perform the upgrade and do some visual and functional checks on the site to see if I can find things before the client sees the site.

At best this process is haphazard. Without doing a full diff on each and every file it would be near impossible to find file differences. Until now.

Announcing a new plugin Hash Checker

This plugin will help you determine changed file in your WordPress core before you upgrade.

Installation

Download the plugin from the link above. Unzip this into the plugin directory. This should create a folder named ‘hashchecker’. Open your browser to your WordPress Admin interface. Go to the Plugins page and activate.

Checking your site

To check your WordPress installation, find ‘Hash Checker’ on your Options menu. The plugin will automatically determine your current WordPress version and start comparing files. In this version there are two types of errors reported.

• Errors reported because the hash values do not match.
• Errors because the code file from the hash config are not found on your site

Customizing the Hash config files

Let’s say for example you like to secure your WordPress installation by removing the wp-admin/upgrade.php file or some other file. And you don’t want to see this error all the time when running the check.

Simple enough. Under the plugin install directory is a sub-folder ‘wp_version_cfg’. This folder contains a cfg file for many of the latest WordPress version. Each config file is a full set of files distributed for that release. To get the error off the screen simply edit the config file, find the line for the file and remove it.

Want to add files to the config? Well this can be done but it’s all manual at this point. The config file format is your basic format

Filename=hash value.

The filename is the path relative to where WordPress is installed. This is not your site root in all cases. The hash is a simple md5 hash of the file. The filename part is pretty easy. But how do you generate an md5 for a file? If you are lucky enough to run OS X or Linus you can easily do this from the command line:

md5

The returned alphanumeric value returned is the md5 hash. This goes on the right of the equal sign in the config.

Testing and Problems

I’ve tested this plugin under versions 2.3.3, 2.2.2 and 2.1. I’ve not been able to test this fully under all WordPress version. so please if you run into problems please give me a note using the comment form below. Will be glad to on this with you.

Also, this plugin assumes you are using the core WordPress files as downloaded from http://wordpress.org/download/. If you are running some SVN version or some ISP’s one-click custom installed version this plugin may not work. My apologies.

Future Plans

I’ve already started thinking about other options to put into the next release. Some of these are:

• Adding the output to the Dashboard
• Having the checker run on a cron at selectable intervals and emailing the admin on erros
• Adding the ability to generate hash for non-core file via an interface.

If you think of anything please tell me below.