clement-h-544786-unsplash

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.

Just do a GitHub search for “wp_deregister_script jquery” and you’ll see this is still happening way too often.

The correct way to include jQuery is like this ( add_action can go after the function, whatever you prefer ):

Or in case you’re also loading your own JS file you should add jQuery as a dependency ( 3rd parameter of wp_enqueue_script function )

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.

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:

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:

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();

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.

Photo by Clément H on Unsplash

Tags: , ,
Previous Post
add-custom-class-body-wordpress
WPDev101

Adding Custom Classes to the Body Tag in WordPress

Next Post
edd-comments
Tutorials

Easy Digital Downloads – Restricting Comments Viewing & Submission

Comments

  1. Reply

    Another source of potential conflicts: use of common PHP libraries without checking whether the class is already defined.

    Example: try using WP Rocket (default minification engine setting) with Autoptimize – you’ll find a conflict on classes in the MatthiasMullie\Minify namespace.

    To avoid: Always check whether any /vendor/ classes you are using are loaded before defining them.

      • Joe
      • September 11, 2018
      Reply

      True, best use it similar to the function example in the post, like wrapping it in a if (class_exists( ‘my_class’ ))

      • BobaWebDev
      • September 11, 2018
      Reply

      True, should always check if it exists already. Will either adjust the “copy/paste” part of the article to also mention usage of libraries or add it as a separate point.

    • Joe
    • September 11, 2018
    Reply

    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.

      • BobaWebDev
      • September 11, 2018
      Reply

      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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.