The life and times of WordPress plugins

Alternative title: Three great plugins I no longer use

Part of the WordPress strategy is to use popular plugins as an indicator for future core features. Sometimes this happens, and sometimes it doesn’t. WordPress has been around for long enough now that it is possible to look back at how things have evolved. How once-great plugins have succumbed to the passages of time…

Gone without replacement – Register Plus

At first, all my WordPress installations came with this plugin. I couldn’t imagine building without it. The feature I wanted it for most was the ability to force email verification on user registration. The author stopped developing the plugin. WordPress core updates meant it broke. There were some attempts to fork it and continue, but none gained any traction. The plugin is now completely missing from wordpress.org.

Partially absorbed into core and abandoned – Scissors

Everyone I knew used this plugin! It had two main features. The first allowed images to be edited and this was pulled into WordPress core. The second let you watermark your images (automatically). It was common knowledge that the core team wanted to use the plugin code and the author assisted them and then publicly abandoned his now (partly) defunct master piece. The water marking was a great feature, I miss it a little and I hope someone has created a plugin to replace it.

Thought I couldn’t live without it and losing momentum – Capsman

This little beauty is a powerful plugin with a simple UI that allows you to view and manage your roles and capabilities. I used it a lot before I learnt about the add_role() and add_cap() functions. I prefer to set thing up programmatically rather than configure a plugin. But I have still been using it. It has been a great way to check and debug my code. However, it has not been updated over a year and will surely soon fall foul of the ever-moving WordPress core. I think this is an ideal candidate for the core team to pull in. With the fast growth in use of custom post types with custom roles (mapping the post capabilities onto role-specific capabilities) , I think there are many freelancers out there who would benefit from this.

jQuery AJAX enable your WordPress forms

I’m often building forms for client projects, and they nearly always prefer them have some AJAX goodness. To this end I’ve built a small jQuery file that gets added to all my projects. It depends on Malsup’s AjaxForm and Bassistance’s Form Validation.

/**
 * Generic *SIMPLE* Ajax Form handling
 */
jQuery(document).ready(function($){
 $('.simpleajaxform').each(function(){
  $(this).attr('method', 'post');
  var target = $(this).attr('target');
  var func   = $(this).attr('function');
  options    = {};
  if( target || func ){
   if( target ) $('#'+target).html('').hide();
   options = {
    success:      simpleajaxform_success,
    beforeSubmit: simpleajaxform_submit
   };
  }

  $(this).ajaxForm(options);
 });
});

/**
 * On submit: clear any previous update and tell the user
 *  that we're trying to update
 */
function simpleajaxform_submit(formData, jqForm, options) {
 if( !jqForm.valid() ) return false;
 target = jqForm.attr('target');

 if( target )
  jQuery('#'+target).html('Updating, please wait...').removeClass('updated').addClass('updating').show();
 return true;
}

/**
 * Response: show message in target div.
 */
function simpleajaxform_success(responseText, statusText, xhr, jQForm){
 if( jQForm === undefined )
  jQForm = xhr;
 if( jQForm === undefined ){
  alert('Cannot handle response properly');
  return;
 }
 target = jQForm.attr('target');
 if( target )
  jQuery('#'+target).removeClass('updating').addClass('updated').html(responseText);

 hide = jQForm.attr('hide');
 if( hide )
  jQuery('#'+hide).hide();

 handler = jQForm.attr('function');
 if( handler )
  eval( handler+'(responseText, jQForm)' );
}

Take any form that submits to an AJAX handler (see below for notes on WordPress and ‘action’), add the ‘simpleajaxform‘ class and either a ‘target‘ or ‘function‘ property. Job done.

Here’s a stripped down example using it:

<form class="simpleajaxform" action="<?php echo admin_url('admin-ajax.php');?>" target="targetdiv">
 <input type="hidden" name="action" value="my_wp_action" />
 <input class="required" type="text" name="message" value="" />
 <input type="submit" name="submit" value="DO STUFF" />
</form>

WordPress, Javascript (jQuery) and ACTION

If you add a field named ‘action‘ in a form, then jQuery can get a bit confused by the syntax ‘jQuery(‘#someformid’).attr(‘action’,ajaxurl)‘. I’ll leave figuring that out as an exercise for the reader (or for a later post).

Download showcase plugin here: simple-ajax-form

Remove gravity forms capabilities

The Gravity Forms plugin adds capabilities at the same level as roles (as opposed to adding capabilities to roles). This means that your users (subscribers, contributors e.t.c) may end up with access to your forms in the back end. This is because the plugin checks for that capability, rather than examine the user’s role’s capabilities.

I wrote a filter to check for and strip away this capability on authentication:

/**
 * Removes the capablity, added by Gravity Forms, from all
 *  non administrators when they log in
 *
 * This hook removes that access on login. To trigger it,
 *  the member must log out first, then back in.
 */
add_action('wp_authenticate', 'tcbarrett_authentication');
function tcbarrett_authentication($username){
  remove_gravityform_caps_from_non_admin($username);
}
function remove_gravityform_caps_from_non_admin($username){
  global $wpdb;
  $user_id = username_exists($username);
  if(!$user_id) return;

  $userinfo = get_userdatabylogin($username);
  $property = $wpdb->prefix."capabilities";
  $caps     = $userinfo->$property;
  if( $caps['administrator'] ) return;
  if( $caps['gform_full_access'] ){
    $member = new WP_User($user_id);
    $member->remove_cap("gform_full_access");
  }
}