WordPress Development Best Practices and Tips

WordPress is easily the most powerful open source blogging and content management system available online today, and so working knowledge of its intricacies is a boon to any developer or designer resume.

This resource contains a collection of WordPress development best practices and WordPress development tips provided by our Toptal network members. As such, this page will be updated on a regular basis to include additional information and cover emerging techniques. This is a community driven project, so you are encouraged to contribute as well, and we are counting on your feedback.

Check out the Toptal resource pages for additional information on WordPress development; there is a WordPress developer hiring guide and WordPress developer interview questions.

Use Child Themes and Plugins

A lot of newcomers to WordPress dive right in and start modifying their core theme files. This is a definite mistake. All of your changes will disappear right after an upgrade, and since plugins and themes are updated about as often as apps on your phone, this is pretty frequently.

To avoid this, create children of your plugins and themes. Not only will you preserve your changes, you can upgrade on your own time. The same steps used to create a child theme can be applied to creating a child plugin, but let’s use creating a child theme as our example.

To get started making your child theme, create a new folder in your themes folder with a unique name, then create a style.css file in your new folder.

In WordPress, all theme parameters are stored in the style.css file as the first comment block. Open the style.css from your original theme, the parent, to see an example of this.

For your child theme, go ahead and copy that comment block from your original theme’s style.css to the new file and rename it. Adding the template parameter to this header will link your new theme to the original. The Template parameter should point to the folder name of the original theme, like so:

/*
Theme Name: Twenty Fourteen Child Theme
Description: My new child theme based on Twenty Fourteen
Template: twentyfourteen
Version: 1.0
*/

Now, if you want to modify files of the original theme, copy them from the original theme’s folder and paste them into your child theme folder. WordPress will use original template files unless it sees the same file in your child theme. So if you want to make changes to header.php, copy it from your original theme into your new child theme folder, and make the changes in the copy. For adding new or modified code, you likewise create a new functions file in your child theme and make your changes there.

This same file copying strategy goes for many plugins as well: create a folder with the same name as a plugin inside your child theme, and then adhering to the file structure of the original plugin folder, copy files from the original plugin to your new folder and modify them. Most major plugins support this, but it’s always good to check with the author if you are not sure.

Speed Things Up with Caching

WordPress optimized hosting services such as Siteground, or the more expensive Wpengine, automatically support WordPress caching. If your host is one that has WordPress specific caching available, it’s the best option.

For those running on a VPS server with root access, Google PageSpeed is a turn key caching and optimization solution by Google that works with Apache and nginx. If that’s of interest to you, check out this guide on how to install PageSpeed on Plesk with CentOS.

If all of that sounds like too much work, then go with Cloudflare, a free CDN/Firewall/Caching and minification system.

Speaking of minification, minify your files yourself during development. Third party tools tend to break things more often than not, especially during upgrades. Doing it yourself gives you more control and awareness of when and where things go wrong.

Pay Attention to Security

WordPress’s popularity makes it a high priority target for hackers. If you don’t update often, you are pretty much asking to get your site hacked.

Automatic updates are a little too dangerous for users with a lot of customizations and plugins, which is why I strongly suggest installing some sort of security plugin.

I personally recommend iTheme Security, which implements security options like a password lockout and file monitoring. And Wordfence Security, a WordPress specific firewall for your site.

Three Developer Tools to Make Life Easier

WordPress has many plugins and add-ons to make your developer life a lot easier. In particular, I recommend:

WP-Cli

WP-Cli lets you work with WordPress using the command line. With this great tool you can upgrade and downgrade WordPress in seconds, as well as update plugins. Notably, when you find yourself migrating to a different server, the built in search-replace command will take care of all the url changes for you, and it’s worth installing it simply because of that.

Advanced Database Cleaner

The Advanced Database Cleaner plugin cleans out spam comments, built in revisions, and transients. You can even set up tasks to run automatically.

Query Monitor

When things are running slowly and you’re not sure what to blame, Query Monitor lets you see what queries are taking too long to execute, as well as show you PHP warnings and errors.

Don't Overdose on Plugins

Yes, WordPress has tons of plugins, but that doesn’t mean you should install them all. The more plugins you have, the bulkier your site and the slower your loading times, so don’t use plugins unless absolutely necessary. If you only need to add a few custom fields to your posts (a functionality already included in WordPress) don’t overengineer the solution by installing the advanced custom field plugin, ACF.

If you must use a lot of plugins, make sure you have Plugin Organizer installed to manage them. This great plugin lets you specify what plugins are activated on which pages (you can even use regular expressions), and this selective loading will significantly speed up your site.

You can also use tools like P3 (Plugin Performance Profiler) to see what plugins are taking up most of your precious resources.

Spring Clean Your WordPress Functions

Although great, WordPress comes out of the box with a lot of things that cannot be turned off in the settings. Here are a handful of steps to take any fresh WordPress install and make it more secure and perform better:

Remove the WordPress Version

Get rid of the WordPress version number to make your site harder to be identified by hackers. To do this, add the following to your functions.php file:

add_filter( 'the_generator', '__return_null' );

Remove Script Versions

Get rid of the version number after scripts. By default, WordPress adds versions to all your scripts. This can lead to issues with caching/minification plugins, as well as helps hackers identify your site better. To prevent this functionality, add the following code to your theme functions file:

function remove_cssjs_ver( $src ) {
  if( strpos( $src, '?ver=' ) )
   $src = remove_query_arg( 'ver', $src );
  return $src;
 }
add_filter( 'style_loader_src', 'remove_cssjs_ver', 1000 );
add_filter( 'script_loader_src', 'remove_cssjs_ver', 1000 );

Restrict WooCommerce

Did you install WooCommerce, and now the site is running slowly? Adding this function to your functions.phpwill prevent WooCommerce from loading its scripts on non-WooCommerce pages:

/**
 * Tweak WooCommerce styles and scripts.
 * Original credit goes to Greg from: https://gist.github.com/gregrickaby/2846416
 */
function grd_woocommerce_script_cleaner() {
 
 // Remove the generator tag, to reduce WooCommerce based hacking attacks
 remove_action( 'wp_head', array( $GLOBALS['woocommerce'], 'generator' ) );
 // Unless we're in the store, remove all the scripts and junk!
 if ( ! is_woocommerce() && ! is_cart() && ! is_checkout() ) {
  wp_dequeue_style( 'woocommerce_frontend_styles' );
  wp_dequeue_style( 'woocommerce-general');
  wp_dequeue_style( 'woocommerce-layout' );
  wp_dequeue_style( 'woocommerce-smallscreen' );
  wp_dequeue_style( 'woocommerce_fancybox_styles' );
  wp_dequeue_style( 'woocommerce_chosen_styles' );
  wp_dequeue_style( 'woocommerce_prettyPhoto_css' );
  wp_dequeue_style( 'select2' );
  wp_dequeue_script( 'wc-add-payment-method' );
  wp_dequeue_script( 'wc-lost-password' );
  wp_dequeue_script( 'wc_price_slider' );
  wp_dequeue_script( 'wc-single-product' );
  wp_dequeue_script( 'wc-add-to-cart' );
  wp_dequeue_script( 'wc-cart-fragments' );
  wp_dequeue_script( 'wc-credit-card-form' );
  wp_dequeue_script( 'wc-checkout' );
  wp_dequeue_script( 'wc-add-to-cart-variation' );
  wp_dequeue_script( 'wc-single-product' );
  wp_dequeue_script( 'wc-cart' ); 
  wp_dequeue_script( 'wc-chosen' );
  wp_dequeue_script( 'woocommerce' );
  wp_dequeue_script( 'prettyPhoto' );
  wp_dequeue_script( 'prettyPhoto-init' );
  wp_dequeue_script( 'jquery-blockui' );
  wp_dequeue_script( 'jquery-placeholder' );
  wp_dequeue_script( 'jquery-payment' );
  wp_dequeue_script( 'jqueryui' );
  wp_dequeue_script( 'fancybox' );
  wp_dequeue_script( 'wcqi-js' );

 }
}
add_action( 'wp_enqueue_scripts', 'grd_woocommerce_script_cleaner', 99 );

Enable Shortcodes in a Widget Area

Trying to use shortcodes in a widget area and getting nothing? Drop this in into functions.php to use shortcodes in widget areas:

add_filter('widget_text', 'do_shortcode');

Use a Function to Load Scripts and CSS

WordPress already keeps track of all the scripts and CSS that it has loaded, so instead of adding your JS and CSS into a header or footer, let WordPress handle it with its enqueue functionality. This way WordPress will keep dependencies in check and you will avoid potential conflicts. You add enqueue methods to your theme’s function.php file: wp_enqueue_script() or wp_enqueue_style(), respectively. Here is an example with some explanatory comments:

function add_theme_scripts() {
//example script from CDN, true means our script will be in the footer.
wp_enqueue_script( 'particles', '//cdn.jsdelivr.net/particles.js/2.0.0/particles.min.js', array(), null, true );
});

//All referred to when to load your style like: 'screen', 'print' or 'handheld.
wp_enqueue_style( 'slider', get_template_directory_uri() . '/css/slider.css',false, null,'all'); 

//this will actually execute our function above
add_action( 'wp_enqueue_scripts', 'add_theme_scripts' ); 

WordPress.org’s Theme Handbook further explains the many parameters to an enqueue method, but here’s the method signature for both enqueue methods:

wp_enqueue_style($handle, $src, $deps, $ver, $media );
wp_enqueue_script($handle, $src, $deps, $ver, $in_footer);

As you can see, the only difference between these two methods is the final parameter. For wp_enqueue_style(), the last parameter sets the media for which this stylesheet has been defined. Such as screen (computer), print (print preview mode), handheld, and so on. The last parameter for wp_enqueue_script() specifies whether or not the script should be loaded in the footer.

Here’s a breakdown for the other parameters in our example:

• $handle is the name of the stylesheet, which can be anything you’d like.
• $src is where the stylesheet is located (CDN, local, etc). This is the only required parameter.
• $deps stands for dependencies. When passed a stylesheet handle, it will load it before executing the source script. When $deps is passed in wp_enqueue_script(), it’s an array.
• $ver sets the version number.
• $media is the wp_enqueue_style() only parameter. It specifies which type of display media the stylesheet is designed for, such as ‘all’, ‘screen’, ‘print’ or ‘handheld.’
• $in_footer is the wp_enqueue_script()’s only parameter, a boolean that allows you to place your scripts in the footer of your HTML rather than in the header, which means it will not delay the loading of the DOM tree.

Contributors:

• Alex Gurevich, a Toptal freelance developerTucson, United States