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 ):

add_action( 'wp_enqueue_scripts', 'codismo_enqueue_scripts' ); function codismo_enqueue_scripts() { wp_enqueue_script( 'jquery' ); } 1 2 3 4 5 6 7 add_action ( 'wp_enqueue_scripts' , 'codismo_enqueue_scripts' ) ; function codismo_enqueue_scripts ( ) { wp_enqueue_script ( 'jquery' ) ; }

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 )

add_action( 'wp_enqueue_scripts', 'codismo_enqueue_scripts' ); function codismo_enqueue_scripts() { wp_enqueue_script( 'codismo-main-js', get_template_directory_uri() . '/js/main.js', array( 'jquery' ), '1.0', true ); } 1 2 3 4 5 6 7 add_action ( 'wp_enqueue_scripts' , 'codismo_enqueue_scripts' ) ; function codismo_enqueue_scripts ( ) { wp_enqueue_script ( 'codismo-main-js' , get_template_directory_uri ( ) . '/js/main.js' , array ( 'jquery' ) , '1.0' , true ) ; }

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.

// This is BAD, way too generic, high chance of conflict function delete_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' ) ) { function codismo_delete_something() { } } 1 2 3 4 5 6 7 8 9 10 11 12 // This is BAD, way too generic, high chance of conflict function delete_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' ) ) { function codismo_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:

<a class="button" href="http://example.com">Button Text</a> 1 < a class = "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:

<a class="codismo-button" href="http://example.com">Button Text</a> 1 < a class = "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:

Custom fields ( post-meta ) – update_post_meta()

Options – update_option()

Post Types – register_post_type()

Taxonomies – register_taxonomy()

Image Sizes – add_image_size()

Shortcodes – add_shortcode()

…

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

$codismo_query = new WP_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(); } 1 2 3 4 5 6 7 8 9 10 11 12 $ codismo_query = new WP_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.