THIS is a methodology for implementing WordPress sites with extraordinarily powerful security that also happens to be fantastic for performance! Amazingly, in addition to these unmatched security and performance benefits, this methodology also results in a site that is surprisingly easy for staffers to use. And all this happens in The WordPress Way!
THIS is the magic of Static Sites! There are many approaches to creating Static Sites on the modern web, and the best find creative ways to leverage the best of modern technology with the time-tested venerable favorites that have driven the web since Day One. We call ours Split Segment Statics, or S3.
In Brief
Modernity and sophistication on the web tend to require, at a minimum, databases and server-side code.
Databases are systems that store content in formats that allow websites to handle this content in all kinds of fancy ways, such as formatting it on the fly, making automated decisions about what to display and when, automatically allow certain users to see specific data while reserving other content for different users, and much, much more.
Server-side code is computer code that does the actual fetching of data from your database (as well as providing you with Admin apps that allow you to enter the data into your database to begin with (and edit it when it changes), all without ever writing code yourself. Server-side code can also do many more things, like pulling posts from your social feeds for display on your own web pages, restricting access to certain areas of your site to specified users, etc. And, again, it allows you to do all this without ever writing any of your own code.
Interestingly, though databases and server-side code empower unmatched productivity on the web, they also have at least two significant costs: Security (each can be attacked), and performance (they both lengthen web page download times). To overcome these challenges, we can separate these valuable technologies from the user experience by setting them up to “do their thing” in advance, well before a user requests a page that depends on these technologies so that the requested page is fully ready to go before our users even arrive at our site.
The most common way to achieve this balance is with Static Sites and the Static Site Generators (or SSG’s) that take all these fancy yet somewhat risky technologies and use them to create “safe” versions of our site behind the scenes. By the time users get to our website to request (view) a page, the database and server-side code are already done with their work, so there is no reason to use them again (to serve the requested page to our user), thereby removing risk and improving performance.
WordPress is hands down, one of the very best dynamic web platforms in the world. The “dynamic” aspect of WordPress is it’s database and server-side code. But WordPress can do much more than simply empower the creation of dynamic websites (sites driven by databases and server-side code): It can actually be configured as a Static Site Generator! And when we do this, we get all the database and server-side code benefits while we build content and design… But, we also get all the security and performance benefits of Static Sites! As a result, though we are still using WordPress, our legitimate visitors get faster and safer pages, while the unwelcome digital troublemakers (hackers, terrorists, criminals, etc), are confronted by a seriously hardened target that is far more challenging to attack or deface.
Of course, there’s quite a bit more to this tale, and some very good reasons that not every website works like this. Yet. To better understand everything that’s happening here, and how we go to this place, it’s quite useful to consider some of the relevant history. Not too much history, though. Don’t worry; this won’t be too geeky…
Back in the Day
Before databases and server-side code became so commonplace, websites often needed code changes for every content change, no matter how small. Some of those code changes touched server-side code, but some were much simpler, affecting only the files that get downloaded to the visitor browser. In either case, however, unless you were willing to learn about code, deployment (the process of pushing code from your Dev environment to your host’s servers), and at least a little about security and performance, you’d have little choice but to depend upon Devs and other practitioners to make your content dreams a reality.
As the web grew, not only in size and scope but also in value and importance, we all found that we need a better way. Even those among us who live in code eventually realized that more and more of the changes we needed to push to our live sites could be completed faster and more easily if we could find a way to manage these changes without manual code changes and constant deployments for every little change request.
So We Added Databases and Server Side Code
Databases and server-side code are, of course, empowering technologies that enable a far larger number of people to publish on the web, even when they don’t know anything about databases or code. How is this possible? Developers create Admins and various other systems with these database and code technologies that can be dressed up in Admins and other utilities. These tools are then used in your browser very similarly to the way you already use many other applications on your desktop or mobile device; and voila, your website is using databases and code, even though you yourself never have to understand either!
Once our websites were beefed up with these technologies and techniques, the web exploded. Everyone could suddenly publish. The web became a competitive venue in which people of all walks of life could compete on the merits of their capabilities in their natural interests and chosen professions, rather than on their abilities to pick up technical skills that actually cost them time, thereby often reducing their capacity to serve in their actually assigned roles.
But new contributors with great ideas weren’t the only new players invited to the growing party that is today’s web. Criminals, hackers (including so-called “hacktivists”), terrorists, and other bad actors also showed up.
Mixed Blessings
Bad actors will exploit any opening to harm. It’s what they do. When we added databases and server-side code to our own toolsets, we also opened a few doors and windows for these miscreants to crawl through as they continued their hunt for harm.
There are, in essence, two buckets of “things” we should do to respond to hacktivists, cyber terrorists, and their nefarious ilk:
- Harden our infrastructure to make attacks against our servers and services harder to complete
- Simplify our infrastructure by removing elements that unnecessarily create openings that such people will exploit
The above two goals are somewhat difficult to accomplish simultaneously because hardening often adds sophistication and complexity, while simplification tends to encourage the reverse.
So, what’s the answer? We combine yesterday’s technology (static pages that lack databases and server-side code), jazz it up with today’s best tooling (databases, server-side code, and a few more specialized pieces), and use them together to create a safer and more performant ultra-modern alternative…
Yesterday + Today = Tomorrow
The web of yesteryear, a largely static experience, offers security and performance benefits (even if only due to the fact that the risky aspects of database and server-side code were less common). Today’s web offers flexibility at the cost of some security and performance. If we could find a way to combine both of these paradigms, we’d be golden!
Simply put (at least in the casual context of this article), we can achieve the best of both worlds by separating our projects into two different types of segments:
- The dynamic elements of our system (databases and server-side code) live in segments that are closed to the public (and as far away as possible from the prying eyes of our digital adversaries). This is our “Today” technology, and it includes a new element: The WordPress SSG (Static Site Generator), which is used to create the next type of segment…
- The static version of our content, which is generated by our WordPress SSG system, becomes the version of the site that end users visit. And there’s no need to worry about any additional heavy lift on your end, because the process is highly automatable! This is also the part of your site that ne’er-do-wells will see most, but because it’s static, there will be far less they can do to hurt you.
Admittedly, not all modern website content and capabilities can be static-fied in this way, but most can. Some e-commerce solutions, for example, still need dynamic features and therefore remain vulnerable to concerted attacks. But even in these unique cases, there are ways to leverage SSG architectures for reducing attack surfaces. So, if e-commerce is a requirement in your project, don’t give up!
The WordPress Way!
When we tout a solution for being implemented in “The WordPress Way”, we’re talking about the choice to use WordPress as intended by WordPress. Even when the implementation deviates from the out-of-the-box simplest way to implement a WordPress project, it is still implemented in “The WordPress Way” if the system, no matter how creative or unusual, is using WordPress tools and behaviors.
This is an issue because the open nature of WordPress as a platform means that we could, if we really wanted to, modify WordPress in ways that skip important WordPress checks, train WordPress to respond to requests in ways that gut built-in WordPress tools in favor of tools from other platforms, etc. While this is certainly allowed, it carries serious risks. For example, a true oddball configuration will be harder for most WordPress professionals to support. A true oddball configuration may not be serviceable by as many hosts. A true oddball configuration might become incompatible with plugins, themes, and other components that would otherwise work just fine in a “compliant” WordPress project.
All of these issues run the risk of increasing fragility and they are very likely to increase ongoing Total Cost of Ownership (TCO). Terror Shield’s Split Segment Statics (S3) architecture is implemented entirely in “The WordPress Way”, 100%, no exceptions, no deviations, and this is an aspect of our solutions of which we are extremely proud.
OK, Great, But Who Really Needs all This?
We’d love to argue that everybody in the WordPress universe needs this kind of solution, but that wouldn’t be entirely realistic. Yet.
This approach is a little more expensive than simpler solutions that require fewer servers, lesser technical knowledge, etc. And, as such, might not be for everyone. Yet.
However, any project that is known to attract attention from hacktivists, cyber terrorists, criminals, and other online thugs, should certainly be looking at solutions that both harden the portions of a project that must be dynamic, and remove dynamic functionality wherever possible, as these are the paths to the best security possible today.
And given the performance benefits of Static Sites, even projects that are not necessarily attracting ne’er-do-well bad actors might also be strongly advised to look into these types of solutions because these are also the paths to the best performance possible today.