Helen Hou-Sandi, the lead for WordPress 4.7, has posed an interesting question – what would we like to see in the next release of WordPress?

Initially, I echoed a number of other people with calls for two-factor authentication to be added (I use it for this site) but, after some thought, suggested something a bit more specific whilst, somehow, remaining a little vague. So, unable to get my thoughts out via a short comment, I thought I’d detail it a little more.

And, this time, I can give some very specific examples.

For some time I’ve added a small piece of code to my sites that allows me to specify shortcodes in blog posts without them being actioned – great for writing instructions on plugins that I might actually be using. Here’s the code…

function noin_shortcode( $paras = '', $content = '' ) { return $content; }
add_shortcode( 'noin', 'noin_shortcode' );

It’s two lines long so never felt it was worth publishing. However, after seeing some articles with useful “one line” tweaks and seeing how difficult some people found implementing these I realised that assuming that everyone can just modify their functions.php was wrong and actually, yeah, a published plugin would be useful.

My issue, though, is just how big that final plugin ended up, without any further functionality being added. Here it is, minus the header and comments..

function noin_plugin_init() {

	$language_dir = plugin_basename( dirname( __FILE__ ) ) . '/languages/';

	load_plugin_textdomain( 'suppress-shortcodes', false, $language_dir );

}

add_action( 'init', 'noin_plugin_init' );

if ( is_admin() && !( defined( 'DOING_AJAX' ) && DOING_AJAX ) ) {

	function noin_set_plugin_meta( $links, $file ) {

		if ( strpos( $file, 'suppress-shortcodes.php' ) !== false ) {
			$links = array_merge( $links, array( '<a href="http://wordpress.org/support/plugin/suppress-shortcodes">' . __( 'Support', 'suppress-shortcodes' ) . '</a>' ) );
			$links = array_merge( $links, array( '<a href="https://artiss.blog/donate">' . __( 'Donate', 'suppress-shortcodes' ) . '</a>' ) );
		}

		return $links;
	}

	add_filter( 'plugin_row_meta', 'noin_set_plugin_meta', 10, 2 );

} else {

	function noin_shortcode( $paras = '', $content = '' ) {
		return $content;
	}

	add_shortcode( 'noin', 'noin_shortcode' );
}

As you can see that’s a lot bigger than it started out! This is because I’ve added lots more coding around non-functional plugin additions. And they’re pretty standard functions too. Now, okay, they don’t need to be added but add a lot of useful features – featured I’d want to add to any of my plugins. Wouldn’t it be great if I could achieve the same without all that extra code? If the final plugin could just be the same lines that I originally showed above?

So, let’s look at what I’ve added. The first function is loading the text domain for translation. Now, this has already been sorted because, as of 4.6, you no longer need to add this. That’s some of the code now gone.

However, the rest is adding meta data to the plugin. You know when you list your plugins in the admin screen you get links to activate or deactivate the plugin as well as to view details in a modal window about the plugin (basically a link to the wordpress.org page for the plugin)? Well, this adds some more. For this plugin I’m adding a donation link and a link to the support page. One’s good for me and the other is useful for users to go straight to getting help. For those plugins with settings pages I also add a link to that – particularly useful as these pages can often get lost in a long list of options under the Settings menu. I use all 3 for my YouTube Embed plugin and this is how it looks…

Nice, isn’t it? Other plugin developers do the same thing.

Now, all this code could be done any with by simply allowing this information to be added via the plugin header. This header is already used for the other information shown above – name, description, version, etc. If they could add this extra information all this code could go, replaced by 3 lines of header information. Sweet.

And that’s it. With the above change, along with what’s already been implemented in 4.6, my plugin would indeed be the couple of lines I started with.

I’m sure there is other code such as this, which again adds no actual functionality, which could also be simplified too. Off the top of my head I can think of the feature pointer. This is the box that pops up in the admin area after you install a plugin and points to various areas, such as menu options, to highlight key functionality. It provides a useful, initial way of introducing how a plugin works.

Unfortunately, unlike, say, adding to the shortcut bar or help tab, this isn’t just a case of calling some functions but is actually quite involved, including adding JavaScript. I’m very sure this could be simplified, as with those other capabilities. Of course it’s not going to be something you can just add to a header – code will be required but I’m sure it can be made a lot easier.

And that’s my suggestion – simplifying non-functional (and often helpful to the user) plugin additions. What do you think? Worthwhile?