5 Easy Strategies to Make WordPress Enterprise-ready in 2021

WordPress is a popular, easy-to-use, PHP-based content management system and blogging platform. Many enterprise organizations believe that WordPress is simply a platform used by smaller companies, entrepreneurs, freelancers and companies who don’t have a robust or sophisticated infrastructure. But what if this simply isn’t the case?

This article will discuss five strategies that can help you take advantage of the easy-to-use functionality of WordPress. We’ll also leverage the enormous community support to develop an enterprise-ready site. But first we’ll talk a bit about the reasons enterprises are hesitant to use this platform for their next enterprise project and why those reasons are unfounded.

Enterprise Hesitancy

WordPress originally started as a blogging platform but quickly adapted to general website use. Today, it’s estimated that WordPress may power as much as 35–40% of the websites on the Internet, and nearly 28% of all ecommerce goes through WooCommerce (a WordPress plugin and system). However, many IT professionals and experienced developers still see the platform as only for blogging, and consider that it’s not suited to handling the larger needs of enterprises, which may need to integrate with their services. Many organizations see their systems as proprietary systems that are “too unique” for WordPress, and believe that it just won’t fit into their infrastructure.

Another fear that IT/development staff have about WordPress is that, to get the site up and running, and working with their system, they have to start from scratch. This is simply not the case. WordPress has done a very nice job of getting the main platform installed in as little as five minutes. In addition, through the use of sophisticated plugins, WordPress can tap into standardized systems, work with cloud services, provide SAML or OAuth2 functionality, and more. Even if you don’t find a plugin that does everything you need, it’s easy to build plugins and extend the platform to connect to your own proprietary system. We’ll look into some of that in this article.

Lastly, there’s a belief that WordPress is just not secure enough. Why do they think this? Well, perhaps it’s because they see a lot of security updates. But shouldn’t that tell you that WordPress is so active on the security front that it’s finding and fixing problems before your IT department even wakes up in the morning? With such a large footprint in the online world, and with so many companies using it, there are thousands and thousands of developers looking at every inch of core. Then with plugins (which can be written by anyone, that is true) we can apply a bit of basic discipline to only pick the best and vet what plugins we allow. Everything is open source, so all plugins are an open book and you can have your devs crawl through them and look for anything that may impact the organization.

The Strategies

Now that we’ve addressed some of the hesitancy and myths lurking about WordPress in the enterprise context, we can talk about some strategies for making WordPress something that could work for a company of any size. While these strategies will cover many topics, there’s always more that you can do. Be sure to look for more information on sitepoint.com as you explore these strategies.

Strategy 1: Identify what you need and lock it down

This is your standard security strategy for WordPress.

1. First make sure that you set up the platform using the famous five minute install guide. One thing to pay attention to is generating your secure salts. This is super easy to do and will give you that extra layer of protection.
2. Set up SSL. Pretty standard really.
3. Protect your wp-config.php file. This file is a great place to put your secrets, passwords, API keys and links to the platform and also your enterprise services. I’d recommend not committing this file to your repositories and instead just keep a backup of it somewhere. Then you can give it to new developers who may need it. You can even move this file to a different location that’s not accessible by the public and then reference the file. If you do a search about moving wp-config.php, you can find tons of information on the topic. In addition to moving it, you can also add a configuration to your web server configs or .htaccess file to simply deny direct access to the file.
4. Move the login page for your admin panel. Typically, this page is found at https://<yoursite.com>/wp-admin. You can also change this URL to be some other location. There are plugins that can assist you with this.
5. Put the site behind a CDN or service like CloudFlare or CloudFront for even more security.
6. Remove any labeling that mentions the WordPress version.

To complete point 6 above, you can use this simple code provided below to do this in two spots, putting them in your functions.php file.

Do the following to remove the version number in the header and RSS:

function remove_wp_head_version() {
  return '';
}
add_filter('the_generator', 'remove_wp_head_version');

And to remove the version details from scripts and CSS files, do this:

function remove_wp_styles_scripts( $src ) {
  if ( strpos( $src, 'ver=' . get_bloginfo( 'version' ) ) ) {
    $src = remove_query_arg( 'ver', $src );
  }
  return $src;
}

add_filter( 'style_loader_src', 'remove_wp_styles_scripts');
add_filter( 'script_loader_src', 'remove_wp_styles_scripts');

If you’d like to take things even further, check out the official WordPress hardening guide for more tips! Again, the WordPress development community has thought a lot about security. So be sure to follow this guide to the extent your organization wishes to go.

Strategy 2: Developing a plan for updating plugins and themes

Now that the basics of security are out of the way, the next thing to think about is how to create a plan for updating your site, your proprietary code, handling plugins and allowing WordPress to update itself when required.

1. First make sure you limit the number of plugins you use. It’s easy to add more plugins. You click a button and it just installs. However, each plugin adds code to your site’s footprint and makes the attack surface greater. Be sure to limit the number of plugins you use and choose plugins from respectable developers. Be sure to vet the developers. Are they responsive? Do they make a living off this plugin? Are they a company themselves? Do they answer a lot of their support tickets? Does the plugin update frequently? If a red flag appears in the answers to any of these questions, move on and try another. Just about every plugin in the repository has another three or four competitors. I typically find the magic number of plugins to have installed seems to be between 10–15. But keep in mind that we’re going to talk about building in your custom code later in this article. You don’t want to be installing plugins for things you already have code for. Make sure to pick wisely!

2. Put WordPress under version control. Here you can set up your own strategy for version control depending on the size of your site. I typically put WordPress Core and Plugins under version control. Sometimes your uploads and static assets may be too large and numerous, so keep those backed up elsewhere. The idea here is that you want to be able to roll back core and any plugin changes if there’s an issue. But again, this can be set up how your organization manages their repositories.

3. Don’t forget your database! If you update WordPress or its plugins, it may alter the database too. Provide a rollback strategy for your database and make sure you’re protected there as well. Often I use Amazon Web Services for databases, so I take snapshots before any major updates.

Strategy 3: Using your own custom classes to build a class library

Up until now, we’ve talked about some best practices and security strategies for most WordPress installs. From now on, we’re going to talk strategies that you can use for very specific proprietary code you might have that you want to work with WordPress. This is going to extend WordPress into that enterprise space and really drive value.

Time to gather up your code

Enterprises usually have class libraries and functions that carry out some kind of functionality exclusive to their offerings. If you gather up this code and put it into a file structure outside your web root directory, you can use WordPress to actually access this library and pull in code! One way you can do this is by creating a simple “Must Use Plugin“, which is a plugin WordPress will always load first thing and before any other plugins. This is ideal for something like an autoloader. Your plugin will declare the autoloader and suddenly your WordPress site has access to your library and can pull in classes from anywhere. Build your library, load it in and you are off to the races!

Okay, so now you have your classes loading in through an autoloader, what next? Well, one powerful feature of WordPress is hooks (also known as actions). When WordPress runs, it looks for callback functions to call at various stages of its lifecycle. From these hooks you can call into your proprietary library code, create objects, call custom functions and methods and do all sorts of other things. If you’ve taken the time to design this code properly from the start, you won’t even have to rewrite anything. Drop it in, inject your dependencies, and you’re good to go.

As an example, let’s assume you have a library class that ties into your data warehousing account at Amazon. When someone logs into the site, you want it send that activity to the warehouse. WordPress has a hook for login called wp_login. You can use this hook to execute your code, collect info about the user that just logged in, and use your class to send that data to the warehouse.

Another example is to intercept that login request, call a third-party authentication service through a REST API call, get a response, and then let the user in if they pass. Suddenly your WordPress site is checking Okta (or a similar service) for credentials using your own code in the background.

Strategy 4: Bolt on services

Building on strategy 3, we can also create a special place on your site that offers REST API endpoints or scripts that can be called directly. One company I worked for used a service to help set up trial software through in-product calls. Someone fires up some software and clicks a button; the software calls the WordPress site, which loads in WordPress and uses proprietary code to provision a trial license. It then returns that license to the user, who can then immediately activate it.

This strategy can be used for various APIs, special portals, logging scripts, and so on. The beauty of this strategy is that these services sit next to WordPress and can use both your custom proprietary classes as well as WordPress functionality to carry out additional tasks, flows and integrations. These services can even fire off webhooks to other services if you want.

Here’s how you can set this up:

/lib      <-- Custom library
/webroot
  |__ /wp-admin
  |__ /wp-content
  |__ /wp-includes
  |__ /services   <-- Services directory
      |__ /api    <-- Service that uses lib classes
      |__ /oauth
      |__ /trial-system

As you can see above, we have a services directory sitting alongside our WordPress installation. It can load in files like wp-load.php to bring in WordPress functionality or reach above webroot to access classes in lib to execute our services. Since these directories serve as their own individual services and are not tied directly to WordPress, this is what I call “bolt-on services”. You could delete /api and suddenly the API isn’t there anymore. WordPress isn’t even aware anything has changed.

Lastly, by having your own custom library of code, you can pull that code in quickly for your own custom plugins! Plugins for WordPress are pretty easy to get started with, and you don’t have to share them with the public. You can write a plugin for a service of yours, pull in the classes and functions from your library, and use WordPress to serve new features. You can do things like locking off portions of pages to specific members, accessing third-party services to know if a visitor can access their account, or serve up assets from the cloud. These are just a few ideas, but there are tons more.

Strategy 5: Advanced function file configuration

A part of most WordPress themes is the functions.php file. Often, online articles that talk about placing some code into WordPress are talking about dropping code into that file. But what many people don’t realize is that this is just a standard PHP file like any other. You can use PHP include and require statements to bring in other files. These files could be your own custom PHP files full of proprietary function code. These files could be from your library as well. By keeping these files separate and full of your own code, organized however you see fit, you can use your functions.php file as a conductor in your own code orchestra. Below is an example of how you might lay this out:

include('lib/classes/oauth.php');
include('lib/functions/configuration.php');
include('lib/functions/utilities.php');
include('lib/functions/shortcodes.php');
include('lib/functions/actions.php');
include('lib/functions/filters.php');

// Here we do stuff with our code

add_action('wp_login', 'do_login_stuff');
function do_login_stuff() {
  // Use Oauth to contact a third-party service
}

When you mix in the advanced function file setup here, our custom library and bolt-on services, you create a synergy that allows enterprises to extend their code however they like. Since none of this touches the actual WordPress core or third-party plugins, you gain the advantage of being able to update WordPress core and plugins without impacting your proprietary code. Again, this code could also live in a separate location away from the public and only pulled in as needed.

In Summary

In this article, we’ve talked about five easy strategies for getting WordPress up to a level where it can be of real use to enterprises.

We started with a basic strategy by talking about the process of hardening the platform, and then we jumped into strategy 2 about planning for how you might want upgrading/updating to happen. These two topics were very generic in that each company has their own level of standards and systems for implementing these sorts of things.

Next, we got into the thought-provoking strategies of code organization and how, with some clever tricks, we could create a class library (strategy 3), bolt on services (strategy 4), and our work with our functions file (strategy 5) to allow enterprises to leverage their code alongside WordPress to create many new features. Through the use of a custom library, plugins, actions, filters, and so on, enterprise developers get the tools needed to build out new services that will play nicely with WordPress to create amazing new tools. Leverage the great features of WordPress and let your marketing team build pages, all while tapping into the power of your hard-earned PHP class library code.

Using these strategies myself, I’ve built trialing systems, REST APIs, integrated with tools like Zendesk, AHA!, Flexnet Operations, and even proprietary physics software and more. The sky’s the limit! I hope you’ve found these strategies interesting and useful!

Frequently Asked Questions about Making WordPress Enterprise-Ready