My WordPress Plugins 2013 – The Good, The Going, The Gone

Posted on by
Reply

Plugins are an ever-moving thing in WordPress. As the internet and WordPress core evolves and moves on, so WordPress plugins come and go. About 18 months ago I blogged about The Life And Times of WordPress Plugins. This is a follow up, of sorts, looking back at my plugin usage, and trying to predict my future use.

Those That Were

Media Tags – http://wordpress.org/extend/plugins/media-tags/

This was a real must-have for my work. We have to use cases for media items: being able to group them and attaching meta data to them. A trivial example would be a list of sponsor logos with links to their websites. It now doesn’t get used that much. WordPress core has added the ability to assign taxonomies to attachments. And our sponsors data has grown more complex and become a custom post type. It may continue to fill a niche, but I think that much like scissors it has done the best it can: inspired WordPress core to improve.

Those That Are

Posts 2 Posts – http://wordpress.org/extend/plugins/posts-to-posts/

I just can’t live without this plugin. I use it to create complex profiles for users. Lets say you want your speakers to be able to login and update their profile? Easy, use P2P to link a WordPress user to any number of speaker profiles. Now you have separation and control over the auth credentials and the profile data. Really useful. Now you want to assign your speaker profiles to a bunch of seminars. These relationship can be defined, built and controlled programmatically.

Gravity Forms – http://www.gravityforms.com/

Not a free plugin! But I lost count of how much time (and money!) this has saved me (and therefore those that pay me). There some things about it that rather rub me the wrong way, but life without it would be full of boring manual form building. I have used other form plugins in the past, but they broke too easily. Being able to export and import forms seamlessly is a must.

Those That Will Be

Meta Box – http://wordpress.org/extend/plugins/meta-box/

A great compliment plugin to posts 2 posts. Being able to easily add custom fields to custom post types quickly and easily is not only just plain useful, but really speeds up development time. It is still quite clunky in places. I foresee that it will become slicker. And is possibly even a contender for being considered for absorption into WordPress core. With the emphasis on post formats in WordPress 3.6, and the implied requirement of different input fields based on type of some sort, I can see the attachment of meta data to varying post types being standardised.

 

WordPress – how to get the slug of your post or page?

Posted on by
1

Finding out the slug for a page or post is one of the most popular search terms on this blog. I find it a little bizarre that my little function generates so much interest, but that’s just one of the unexpected joys of blogging.

I have decided to follow-up my first post on getting the post slug, taking in to consideration the comments and main use of the function. Hopefully, though a small change, it is an improvement.

I’ve split it into two functions. The first forming the base for the second.

Function: get_the_slug()

/**
 * The the post or page slug from post ID
 */
function get_the_slug( $id=null ){
  if( empty($id) ):
    global $post;
    if( empty($post) )
      return ''; // No global $post var available.
    $id = $post->ID;
  endif;

  $slug = basename( get_permalink($id) );
  return $slug;
}

WordPress appears to be adopting the style of having get_ and the_ function prefixes to get or display content. So here is the complimentary function. I’ve removed some hooks that I don’t think anyone used, instead just applying one (well named) filter.

Function: the_slug()

/**
 * Display the page or post slug
 *
 * Uses get_the_slug() and applies 'the_slug' filter.
 */
function the_slug( $id=null ){
  echo apply_filters( 'the_slug', get_the_slug($id) );
}

Example use of the_slug() and get_the_slug() functions:

<div id="some-post-container-<?php echo get_the_slug(); ?>">
  The post slug is <strong><?php the_slug(); ?></strong>.
  Lorem whatsit here
</div>

How to get a list of all your Gravity Forms

Posted on by
Reply

Forms, forms, forms. Probably the primary way for website visitors to submit information to website owners. They let us capture data for all sorts of things. So, unsurprisingly, I’ve doing a lot with forms recently. My go-to WordPress form manager is Gravity Forms.

Sometimes I add functionality that isn’t really an extension of Gravity Forms, but does relate to specific form. All I need is a simple dropdown of the forms, with their ID and title.

$select = '<select>';
$forms = RGFormsModel::get_forms( null, 'title' );
foreach( $forms as $form ):
  $select .= '<option id="' . $form->id . '">' . $form->title . '</option>';
endforeach;
$select .= '</select>';

echo "GF dropdown: $select";

Above is a trivial example to create a dropdown select field.

Theme (or Plugin) Development – Attach hook to version change (flush rewrite rules)

Posted on by

The rewrite rules for WordPress control which pages and posts to display based on the URL. These are normally updated via the Permalinks setting. When you hit ‘save changes’  all the rules for which URL maps to which page are saved to the database.

When developing plugins and themes it is common to add some custom post types, or custom taxonomies. These both add to the rewrite rules. Rather than constantly clicking to save the permalinks button, we can use the flush_rewrite_rules() function call. It is expensive to do (calculating the rules and writing to the database uses lots of server resources). However, you don’t want to make your end-user have update their permalinks manually every time you release an update. This is why the codex recommends hooking into the activation hook, as this will get fired when the plugin is installed or updated from wordpress.org.

I am often faced with two scenarios that are not covered by the activation hook. Firstly, whilst developing I don’t update my plugin like that – I just change the code. And secondly I mostly write bespoke code for clients not hosted on wordpress.org, and updated using version control, not from inside WordPress admin.

So I need some other trigger. Something that happens automatically, but not all the time. I decided to hook into the theme version changing.

add_action( 'admin_init', 'tcb_version_update_check' );
function tcb_version_update_check(){
  $theme           = wp_get_theme();
  $in_file_version = $theme->Version;
  $slug            = $theme->stylesheet;
  $optionkey       = "tcb_vesion_check_{$slug}";
  $in_db_version   = get_option( $optionkey, 0 );

  $version_diff    = version_compare( $in_db_version, $in_file_version );
  if( !$version_diff ) return;

  error_log( "Theme version has changed: $in_db_version -> $in_file_version" );
  if( $version_diff == 1 ) :
    error_log( "Theme version has gone down. Doesn't compute. Not running update hook." );
    return;
  endif;

  do_action( 'tcb_theme_version_update', $in_file_version, $in_db_version );

  update_option( $optionkey, $in_file_version );
}

add_action( 'tcb_theme_version_update', 'tcb_update_flush_rewrite_rules', 10, 2 );
function tcb_update_flush_rewrite_rules( $new_version, $old_version ){
  error_log( "Flushing rewrite rules" );
  flush_rewrite_rules( false );
}

What I’ve done is hooked into admin_init to check whether the theme version has changed. Added a little sanity check to see if it has gone down!?! And invoked my own hook to let myself expand on the version change trigger.