Site icon WP Smith

Extending or Modifying a Plugin

Many times, I extend plugins with additional functionality or customize plugins with specific needs of the theme or the site. You may do the same, but where does this code need to go? Should it go in functions.php or should it reside in its own plugin?

Before I answer this question, let's consider these questions.

  1. How do you handle troubleshooting on plugin updates if the theme or site breaks?
  2. Since the original functionality exists in a theme, what happens to that functionality if the user switches themes? Or, in other words, is this customization truly theme specific?
  3. What happens to the code if the extended plugin is deactivated?

Depending on how you answer these questions, I would say whether the extension should be in either it's own plugin or in the theme's functions.php though one could easily argue that regardless, it is plugin territory, especially in light of Thomas Griffin's Plugin Activation class.

For example, there are times when plugins release an update and this update either breaks your theme or breaks your extension. The former is going to happen periodically with some plugins, but if the latter happens and your extended code resides in functions.php, then your theme may break. Regardless, it becomes an effort to determine where the breakdown occurs: is it the theme or the extension? So, if it resides in functions.php, we go and comment the extension to see if it was the problem.

However, if the extension lives within a plugin, then it is just a simple test by deactivating the plugin to determine whether it was the problem. Also, having it reside in a plugin keeps the functions.php file cleaner.

Now, if you extend a plugin that contains a shortcode, like Display Posts Shortcode. So for example, let's say we add an attribute to the display posts shortcode.

<?php
add_filter( 'display_posts_shortcode_args', 'dpse_shortcode_exclude_posts', 10, 2 );
/**
* Add "not_in" arg to Display Posts Shortcode
*
* @since 1.0.0
*
* @param array $args Default Display Posts Shortcode args.
* @param array $atts Original shortcode attributes.
* @return array $args Modified Display Posts Shortcode args.
*/
function dpse_shortcode_exclude_posts( $args, $atts ) {
if( isset( $atts['not_in'] ) ) {
$args['post__not_in'] = explode( ',', $atts['not_in'] );
}
return $args;
}

Now should this be made into a plugin or not? In my opinion, it should. Many would argue by default this should reside in a plugin simply because now you are immediately impacting content. If a user or the client were to switch themes, then in places that use the [ display-posts] shortcode, only the shortcode appears without the modification.
To make it into a plugin, we just need to add the file header. Below you will see the file header and the plugin header comments, which WordPress reads and uses for the plugins page.

<?php
/**
* Display Posts Shortcode Extension Plugin
*
* @package DT_Display_Posts
* @author Travis Smith <t@wpsmith.net>
* @license GPL-2.0+
* @link http://wpsmith.net
* @link http://wordpress.org/plugins/display-posts-shortcode/
* @copyright 2014 Travis Smith
*
* @wordpress-plugin
* Plugin Name: Display Posts Shortcode - My Extension
* Plugin URI: http://www.wpsmith.net
* Description: Extends Display Posts Shortcode
* Version: 1.0.0
* Author: Travis Smith
* Author URI: http://www.wpsmith.net
* Text Domain: displayposts-ext
* License: GPL-2.0+
* License URI: http://www.gnu.org/licenses/gpl-2.0.txt
* Domain Path: /languages
*/
add_filter( 'display_posts_shortcode_args', 'dpse_shortcode_exclude_posts', 10, 2 );
/**
* Add "not_in" arg to Display Posts Shortcode
*
* @since 1.0.0
*
* @param array $args Default Display Posts Shortcode args.
* @param array $atts Original shortcode attributes.
* @return array $args Modified Display Posts Shortcode args.
*/
function dpse_shortcode_exclude_posts( $args, $atts ) {
if( isset( $atts['not_in'] ) ) {
$args['post__not_in'] = explode( ',', $atts['not_in'] );
}
return $args;
}

Yet, this brings up another issue. How do I deactivate my plugin if the extended plugin was deactivated? We will discuss this in the next post on Tuesday.