How to Name Plugin Functions, Options, Variables & More

Experienced programmers and WordPress plugin developers will likely think that it is silly to even waste a whole website page to cover this subject, but it is actually extremely important that all WP developers understand this properly.

Here is the basic notion: global variable names, class names, and function names in WP plugins and themes must be unique.

If your plugin will create it's own database tables, hooks, actions, filters, and/or WP options, you should also utilize these same recommendations to name them.

There is one simple way to accomplish this but before I tell you that, it is worth understanding why you simply must program your plugins this way.

WordPress is an ever-growing, open source script. On top of that, you have thousands of developers making plugins and themes for WP.

People that use WP to power a website have complete control over the software that they want to use on each site. For this reason, a develop cannot have any idea or any control over what software will be used alongside of their own.

Since a developer cannot control or even predict these things, they simply must account for this in their own programming or else they will eventually run into problems.

Problems happen because of the basic way that the PHP programming language works and also because of the way WordPress works.

Whenever someone visits a page on a WP site or when the WP dashboard is accessed by the administrator, all of the code from WordPress, activated plugins, and activated themes is loaded together.

PHP scripts will throw a fatal error if functions or classes exist that have the same name.

As an example, if two plugins both have an activation function that was simply named activate, WordPress would die with a fatal error with every single load, even if those functions were not currently being called.

Duplicate global variables names can also have dire consequences, even though they will not easily show up as fatal errors. Instead, duplicate variable names can simply cause unexpected bugs in a plugin or elsewhere in WordPress.

Just in case you are not familiar with the term global variables, I am referring to a variable that could be accessed from any other script or plugin in WordPress besides your own. If you use classes or functions in your script, variables within those classes or functions would not be global variables, unless they were declared as such.

WordPress Function Naming Strategy

At this point, you should understand exactly why you need to use unique names in your plugin for function, class, and global variable names. Without knowing exactly how important it is to take this step, you may easily brush it off and ignore these rules until it is too late.

Now, you need to understand what you can do about it that will also allow you to stay organized. The easy solution is to adopt a strategy for naming these things in your plugins.

You should already have a unique name for you plugin that you used as the name of the plugin's folder and the main PHP file.

You now need to use the same name or an abbreviation of the name as a prefix for the functions, classes, and global variables in your plugin. Just like the plugin name, this prefix needs to be something that is unique to only your plugin.

You can use whatever prefix you want as long as you are confident that other plugins will never use it. Typically, some random combination of four or more letters is sufficient to avoid problems.

As an example, my plugin ExtendAzon uses the prefix exaz.

The code below shows a few examples of this prefix name in use.

// Global script variable containing a unique license key for this plugin copy
$exaz_key = "k83ns98j4hs83kj58dn3k48dy4";

// Function for the activation hook
exaz_activate()
{
//Plugin Activation Code
}

To go a step beyond that, you may also want to consider adding a second prefix to some parts of your plugin (like function names, for example). Personally, I will often make a secondary prefix for function names that are found in files other than the main file of my plugin. This secondary prefix is really just for my own organization. This way, when you are browsing through your own code and see a particular function name, you will know exactly which file will contain that function based on how it is named. For example, I might have a file named functions.php. In that file, a function for the activation hook might be named exax_functions_activate.

By adopting your own method of naming functions, options, database tables, classes, global variables, and more, you can boost your organization and also avoid conflicts with WordPress or other plugins and themes.

When you make this a habit from the first plugin you develop, you'll simply avoid these problems from the beginning. However, if you choose to ignore this advice, I can almost guarantee that a time will come that you will wish that you had not done so (trust me, it is worth the extra effort).

Comments are closed.