Tag: essay

Someone pinged me on slack about this. Bear in mind, I tell people “If you got an email from plugins, please press reply and email back, don’t slack me.” because it allows me to keep track of the whole history of a conversation, but also because if I’m sick, someone else can reply to you and you’ll wait less. While, in this case, the answer should have been very short, it grew to be a lot longer than he’d expected because he didn’t quite understand what I meant.

Unique Prefixes

One of the requirements of the Plugin Directory is that all plugins have unique function names, defines, and classnames. This is for a pretty obvious reason: it will prevent your plugin from conflicting with other plugins or themes.

• For plugins, use a function or classname that matches the plugin name: class ThisPluginName{} or function ThisPluginName_FUNCTION()
• For specific specific sites, use a function class for the domain: class HalfElfOrg{} or class HELF{} or function helf_FUNCTION

This extends to all things, including defines, namespaces, enqueue’d handles, and on and on. As I tell people, “A namespace or class of MyPlugin is not actually all that unique…” Defines are extra tricky since sometimes you want to define them and allow them to be replaced. But more on that in a minute. No matter what, this is bad: define( 'PLUGIN_PATH', plugins_url( __FILE__ ) );

Since it’s 2016, I have to tell people that they shouldn’t use two letter slugs anymore as all the good ones are taken. I also tell them not to use wp_ or __ as a prefix.

And then I say this:

If those are intended to be in shared libraries, please detect IF the code is already included and not re-include it, as doing so will cause conflicts if two people call the same defines and functions.

Yeah. It’s messy.

If Define Exists…

This is used a lot. Let’s say you know you need the plugin basename (the folder name) in multiple sub folders of you plugin, and it’s a pain in the ass to do plugins_urls( 'foo.css' , dirname( dirname( __FILE__ )) ); to go up two folders. That’s a case where a global define starts to make sense and it’s a case where rarely would you want to bother checking if it exists.

The code is just this: define( 'MY_PLUGIN_BASENAME', plugin_basename( __FILE__ ) );

But what if you want to have a default value for an API Key and allow people to override it? Then you can one of these:

// Option 1:
if ( ! defined( 'MY_PLUGIN_APIKEY' ) )
    define( 'MY_PLUGIN_APIKEY', 'default key value' );

// Option 2:
defined('MY_PLUGIN_APIKEY') or define('MY_PLUGIN_APIKEY', 'default key value' );

What those do is check “Does the define already exist?” for you.

Now keep in mind, I wouldn’t do that. I’d do this:

$apikey = ( defined('MY_PLUGIN_APIKEY') ) ? MY_PLUGIN_APIKEY : 'default key value' ;

The best example of this in core WP is how WP_DEBUG is handled. If you delete that from your wp-config.php file, it doesn’t turn on debugging. The code checks for the existence and if it’s not there, it assumes no. For the most part, if you name your defines properly, there’s no need to allow them to be overwritten because you’re not defining them in advance. But in case you do, this code is a wise idea.

If Function (or Class) Exists …

Lately I’ve seen a lot of people do this:

if ( ! function_exists( 'my_awesome_function' ) ) {
	function my_awesome_function() {
		//function stuff
	}
}

Okay look. This sounds like a great idea until you realize the fatal flaw. What happens when (not if, when) someone else has a function with the same name and their plugin or theme loads first?

As Lilu Dallas would say “Big badda boom.”

This is a terrible idea unless we’re talking about shared libraries.

Use if-checks With Shared Libraries

That’s my answer here folks. The only time you should be checking if-exists is WHEN you are using a shared library. If your plugin includes a common PHP library, check for it before you include it.

It’s a little different with Javascript and CSS though. Let’s say you’ve got Bootstrap. This is a commonly used library. A lot of plugins and themes have it, and you’re a good person. You want to make sure you only load it one time no matter how many people include it in their plugins and themes. In this moment, you have to do something paradoxically brilliant.

Don’t use a unique name for your enqueues.

function mypluginname_resources() {
    wp_enqueue_style( 'bootstrap', plugins_url( 'css/bootstrap.min.css', __FILE__ ), array(), VERSION );
    wp_enqueue_script( 'bootstrap', plugins_url( 'css/js', __FILE__ ), array(), VERSION );
}
add_action('wp_enqueue_scripts', 'mypluginname_resources');

The magic here is specific to how WordPress handles enqueues. It knows “There’s already something enqueued as bootstrap! I don’t need this!” and you’ve sped up sites. Of course there’s a risk here when someone might have an older version loaded first. As far as I know, the enqueue system isn’t clever enough to detect what version is included, and use the newest one (I wish it was), so you may have to do some convoluted checks. Also making this worse is that people don’t name things properly. I’ve see people using bootstrap-js and bootstrap-css for the enqueue names, which is totally unnecessary. WordPress will handle that for you.

Remember: When in doubt, if coding for WordPress do it the WordPress way.