Common Reasons For Theme/Plugin Conflicts in WordPress

In my 8 years of WordPress theme and plugin development ( free and commercial ) I’ve often had support request about things not working as they should. It was usually a conflict with a plugin or a theme that wasn’t doing things properly.

A few reasons for those conflicts were the cause more often than others. In this article I will share those reasons and hopefully it will help make a better and more conflict free environment.

Not Using the jQuery Which Comes With WordPress

This used to happen way too often, it’s the very first thing I check when someone contacts me about an issue that’s JavaScript related.

Themes and plugins that do that are not accepted on the official WordPress themes repository and Themeforest ( not sure about other marketplaces ) started rejecting themes that do that as well a while ago, but there are still a lot of themes available that do it. It’s wrong and should NOT be done.

Not Prefixing

Your theme/plugin is not the only thing that will be active. If you don’t prefix, there will be conflicts. Some of those conflicts would cause fatal errors, some would break layout and some would break functionality.

By prefixing, you minimize the chances of such conflicts. So, what should be prefixed.

PHP

Everything in PHP that exists in the global namespace must be prefixed. That will minimize the risk of the same name being used twice and causing problems, in some cases a fatal error. So, what’s in the global namespace?

Functions

Classes

Constants

Variables defined outside of functions/methods

Let’s use functions as an example.

1

2

3

4

5

6

7

8

9

10

11

12

// This is BAD, way too generic, high chance of conflict

functiondelete_something(){

}

// This is BETTER, if the function is already defined, it won't be a fatal error

// Also, this is how child themes can alter parent theme functions

if(!function_exists('codismo_delete_something')){

functioncodismo_delete_something(){

}

}

You would of course be using your own prefix. If for example your theme name is Corporate One your prefix would be corporate_one and the full function name corporate_one_delete_something.

HTML

In plugins, prefix ALL classes and IDs. Themes don’t really need prefixed classes and IDs. But if you want you can prefix in themes as well, just as a precaution ( but I haven’t seen a theme that does it ).

Let’s take a simple example, a button element. Generally you’d go with something like this:

1

<aclass="button"href="http://example.com">Button Text</a>

It’s a common element, there’s a high chance a theme/plugin will use the same class with it’s own CSS. And we have a conflict, the rules from different sources will get mixed up and no button will look as it should.

So, a safer approach to the previous example would be this:

1

<aclass="codismo-button"href="http://example.com">Button Text</a>

JavaScript

Everything in the global namespace must be prefixed.

WordPress

There are a lot of places in WordPress where you need to prefix your stuff:

You get the gist, any function in WordPress that requires you to enter a name or ID is where you should prefix.

Menus and Sidebars do not go on that list. Sidebars should be sidebar-1, sidebar-2, sidebar-3… Menus should be primary, footer… That way when switching themes the user doesn’t have to recreate menus and widget areas.

But there is something I need to mention, Justin Tadlock ( one of the most known WordPress developers ) says in his article from 4 years ago that post types shouldn’t be prefixed ( read the post for more information ).

Sure, there’s a benefit in keeping it all standardized, but there’s also a lot of room for conflicts. So in my opinion, we should prefix post types as well. And more importantly, the official WordPress developer handbook also says we should prefix post types.

Copy/Pasting Code

This is as big of an issue as not prefixing. A lot of developers do a google search looking for the code to do something specific and simply copy/paste it into their theme or plugin. So if a WordPress user has a theme and a plugin installed and both have copy/pasted PHP code with the same function name that’s going to result in a fatal error.

Whenever you use PHP code you find on the internet, make sure to put your own prefix to it and also wrap it in function_exists() as mentioned previously.

Not Resetting After Custom Queries

When you do a custom query using WP_Query you have to reset the post data after you’re done with the query. Otherwise WordPress will no longer know on which page it is, it will think the current page is the last post from the query.

The way you reset it is by using wp_reset_postdata();

1

2

3

4

5

6

7

8

9

10

11

12

$codismo_query=newWP_Query($args);

if($codismo_query->have_posts()){

while($codismo_query->have_posts()){$codismo_query->the_post();

// Post output

}

// Reset the post data

wp_reset_postdata();

}

Final Words

That’s all for now, if I remember anything else I will update the article. And in case you have something to add let me know in the comments.

Great summary. I agree with most of it but just not fully with the CSS thing. CSS coming from a plugin is quite a No-go for me. I prefer the way many modern plugins do (also most of my) where there is an option to enable/disable the plugin css. There should be less to little Css coming from the plugin. And especially when the button class gets used I rarely prefix because I assume the theme styles that already. Only if I want the button having a specific look I prefix and style it accordingly.

Thanks Joe, happy to hear that. Yeah, theme should handle the CSS but a lot of plugin developers add CSS and it’s not really going to stop, but if they just use prefixes it would help out a lot to avoid conflicts.

I’ve even encountered issues because some plugins loaded frameworks like Bootstrap.

Also had issues with plugins having their own CSS on .clear ( to clear floats ) which was different from the one I used in a theme and it broke the layout.