Over the last few years, I’ve built quite a few plugins—most of them never installed on more than one site.

When a client wants a bit of custom functionality, there’s no better tool in your tool-belt than a custom plugin.

If you need the same functionality on a couple of sites (for the same client of course), you can just install and customize it.

However, when it comes to building plugins for enterprise sites and clients, there are a few things that you really need to think about.

Speed, uptime and security are absolutely critical for enterprise WordPress sites

When I say Enterprise, I’m talking about sites that are seeing millions of visitors a month.

Even a few minutes of downtime or a slow loading site can cost them serious money or reputation.

I’m going to walk you through 3 of the biggest issues you should be thinking about when building WordPress plugins.

You should always be concerned with these, but especially with high profile and highly trafficked sites.

Scrutinize Every Single Database Query

At it’s core, WordPress is a PHP application interacting with a database.

When done well, queries are fast, pages load quickly, and you forget that the database even exists.

Unfortunately, there are plugin authors that don’t consider the time it takes for queries to run, or are simply unaware of the implications of slow queries.

Carefully consider each database query that you use in your plugin and be sure that you are only running it when it’s necessary.

Here is some good advice from 10up’s engineering best practices:

• Only run the queries that you need — WP_Query runs 5 individual queries(!!) by default
• Do not use posts_per_page ⇒ -1 to get all the posts — use a reasonable upper limit
• Avoid Multi-dimensional queries — queries that are joining together multiple tables and take a significant amount of time to run

By focusing on the queries that you run, you can make sure that you’re only running what’s necessary and minimizing the time required to load.

Sanitize and Escape Everything

Security is critical when you’re developing software for systems at this scale.

Bad actors target these platforms more than others and it’s important that we use practices to prevent them from taking advantage of a high profile site.

A best practice that I think a lot of developers overlook is sanitizing and escaping data:

• Any time you receive content from a user, it should be sanitized​
• Any time you are outputting user-editable content to the screen, it should be escaped​

WordPress has several functions that make this really quick to implement and you should spend some time familiarizing yourself with them.

The next time you are working on your plugin, browse through the codebase and make sure that you are sanitizing and escaping the things that you need to.

Give Yourself Room To Expand Without Over-Engineering

PHP has come a long way in recent years and there are really good examples of efficient architecture for web applications (laravel, Symfony, etc.)

However, sometimes those concepts can be an opportunity to spend too much time in areas of your plugin that don’t benefit much.

Do you need that interface even though you only have a single class implementing it?

Probably not.

How about that abstract class that you’re only extending once?

Nope.

I’ve learned that building complicated systems gets in the way of efficient development.

If you absolutely need that interface because you have five different database connections and need to guarantee that they share the same methods, then use it.

But don’t over-engineer something because it’s “best practice”.

In Summary

Be very intentional with the database queries you use, make sure that you’re sanitizing and escaping content, and keep things as simple as possible until you need to expand.

I’ve spent a lot of time learning these lessons so I hope you can take something away from them and use it in your own plugins.