Ace Goulet

WordPress Best Practices And Guidelines



This is my WordPress site. There are many like it, but this one is mine.
My WordPress site is my best friend. It is my life. I must master it as I must master my life.

My WordPress site, without me, is useless. Without my WordPress site, I am useless. I must develop my WordPress site true. I must develop more securely than my enemy who is trying to hack me. I must stop him before he hacks me. I will…

My WordPress site and I know that what counts in war is not the rounds we fire, the noise of our burst, nor the smoke we make. We know that it is the hits that count. We will hit…


I may have lost my thread at the end there…

There are lots of WordPress development best practices articles around the internet.

This article is not meant to be the be-all, end-all WP best practices document, but rather to supplement accepted standards with the guidelines I have come to adhere to through trial, error, blood, sweat, tears, death, and dismemberment*.

*Only two, maybe three, of the things on that list are accurate.

First Thing’s First (WTF is WordPress?)

Make sure you know what WordPress is. This sounds simple, but it’s a bit more nuanced than you may think. From

WordPress started in 2003 with a single bit of code to enhance the typography of everyday writing and with fewer users than you can count on your fingers and toes. Since then it has grown to be the largest self-hosted blogging tool in the world, used on millions of sites and seen by tens of millions of people every day.

To say that WordPress is simply a blogging tool, is a gross understatement. It can function as pretty much any type of standard website you can shake a stick at, as well as serve as an API, a backend for software applications, and much more. The uses are constantly evolving and I encourage you to just do some quick google searches and see some of the innovative ways people are using the tool.

A word about support

The best support comes from the pros. If you have a question, hit a roadblock, or are just confused about something you are seeing in a codebase, here are the places to start your search for enlightenment:


There’s a bunch of security stuff sprinkled throughout this article, but rather than jam it all in here, check out this separate article for a list of security tasks and considerations.

Some Basics

These are some of the most basic (but very important) tenets I follow when making a WordPress site. Not coincidently, these are also standard WP best practices.

Version Control

When creating a repository my WordPress sites, I only commit the theme folder. I do not commit plugins, WordPress core, uploads, etc. This makes deployments more straight forward when you consider that WordPress and plugins will be updated via the WP admin panel and very quickly you will end up with a repository that is out of date. It’s a big security risk to be deploying out of date plugins, especially if a vulnerable plugin has been updated via the WP admin, then an old flawed version is deployed at a later date, opening up the security hold once again.

Sometimes I also include a ‘dev’ directory in my theme folder that I use to hold notes, sql backups, etc…basically anything site-related that I also want in version control. I just make sure to not include that folder in your deployment, especially if it contains any sensitive data.

Initial Setup

When you start a new WordPress site, here are some things I do out of the gate to start off on the right foot.

Theme Building

As per usual, the WordPress Codex covers this topic far more deeply than I could hope to here…and they keep it up-to-date. Read these articles…seriously…lots of great information in there that you’ll want to know: &

Some basic guidelines I follow for theme building:

Customizing the WP Admin

My themes are typically leveraged for more than just the user-facing side of the site. It is equally important to make the wp-admin interface clean, customized, easy to use, and (perhaps most importantly) idiot-proof. There are lots of ways to accomplish these goals. I created a plugin (Aceify) that handles a bunch of them, but usually I implement them in my theme functions (many of these are included in my starter theme). Here are some of the basics:


Plugins extend WordPress functionality. Some are built by Automattic (the folks behind WordPress), but most are created by the extremely active WordPress community. There are currently almost 40,000 plugins available in the WordPress Plugins repository.


Because most plugins are created by random people and don’t have any real quality control, BE VERY CAREFUL when implementing a plugin that you haven’t previously vetted. Check the reviews and ratings, request a peer review of the plugin from other developers, and when in doubt, don’t use it. A lot of times you can accomplish what you are trying to do through a little extra elbow grease and some code slinging.

Plugins I Really Like

These are some plugins I have used a bunch. They have active support, and have been stable and reliable.

WPEngine Disallowed Plugins

WPengine keeps up with a lot of security and performance related issues in regards to plugins. Some of these plugins are only bad in WPE’s environment, as they duplicate functionalty WPE is already providing (like cacheing plugins), while others are just bad news across the board. When trying out a new plugin, I usually make sure to check their list…it’s never bad to check and see if they have given the plugin a red flag. Ref:

Bottom Line

Follow standard WP best practices, don’t use sketchy plugins, make your admin lean, mean, and idiot-proof, and ask for guidance should you need it.

If you read all the way to the end, thanks, you’re a real mensch.

Exit mobile version