WordPress is a prevalent CMS solution so it can't be ignored without becoming the elephant in the room. Before we travel down this rabbit hole its necessary to understand the difference between SaaS Platforms (Like Adobe BC, or Xero, or Mailchimp) versus traditional software programmes (like MS OfficePre-2011, or Adobe Acrobat), and open-source programmes (like WordPress, SugarCRM and Drupal). Indeed, you may be curious why WordPress isn't being pitched as a possible solution. Here's the answer.
(WARNING: Plain English Knowledge below. No added Sugar/No Artificial sweeteners)
SaaS (Software as a Service) versus Programmes (Software as a product)
A simple "SaaS vs Programme" example most NZ professionals will identify with is Xero versus MYOB (specifically MYOB desktop accounting software, being all MYOB was until realising too late that they'd missed the cloud paradigm shift).
Xero, like all SaaS platforms, does not require you to buy or install any software, or to update it or troubleshoot it. You simple access it in your web browser and it works (or, if it doesn't work at a certain time, you can be safe in the knowledge that Xero's top Propeller-Cap Commando's have been mobilised into action to get you back up and running before you know it).
In other words, when you use a SaaS platform you are entirely removed from the underlying technology. Any whirr, squeak or cluck under the hood, or any messed-up ones & zeros causing a binary bad-hair day, well,... it just ain't your problem!.
As time goes by new features are added and improvements magically appear requiring no action on your part. You also don't need to backup your data to an underground bunker every night in case of armageddon.
MYOB, the desktop software, was typical of any locally installed programme. New versions need to be periodically acquired and installed, and updates or patches need to be applied to correct errors and fix vulnerabilities. If the programme malfunctions then, yes, it is 100% entirely your problem.
There is a misconception about open source software used on the web. Just because it's on the web doesn't mean it's a service, and it does not define it as being "in the Cloud".
When you install open source software on a web server, it is just a software programme installed on a computer across town, or the other side of the world, rather than on the computer under your desk. Web servers are generally of a higher specification than the average office PC, but they are fundamentally the same thing. The only difference (practically speaking) is that your 1.5m long USB cable is now thousands of kilometers long. You will also allow anyone to connect to that computer and interact with the programme running on it in some way.
Generally speaking this all works nicely (until it doesn't). To make things super fun and interesting, any flaws in the software become known and exploitable fairly quickly because everybody else on the planet also has access to the programme source code and, should their favourite fetish be hacking other peoples websites, then it may become a very bad hair day indeed.
Whether you buy software and install it on your computer, or you find free, open source software that you install on a web server (or have someone install it for you), it is still "a standalone piece of software" that requires version updating, patching and troubleshooting. If something goes pear shaped it's your problem. When this inevitability occurs (and it will), you'll be unimpressed and will call your web developer to explain that: "something is wrong with the website you built you me" and, as you haven't updated the site recently, you'll explain that: "It's obviously your fault for building my site poorly and I demand you fix it".
These are the moments when developers wonder why they didn't choose a more rewarding career like sponge-bathing the elderly between Uber shifts. Bringing the subject of billing into this conversation doesn't always end well.
This is the number one cause of website owners feeling their web company has done them a disservice and it's often the nail in the coffin that destroys any trust that existed. If you're a designer/developer/agency with a service driven approach to retain happy customers then your workload goes up exponentially while your hourly income drops to a number too embarrassing to share. (Personally, I'm not keen on going back to the good-ol' WordPress days).
Today some options are available to keep you safe from harm such as WordPress.com, which is a hosted platform built on the open source software from WordPress.org. However, the hosted service is limited to only using a specific cluster of plugins. No problem if your site doesn't need specific, advanced plugin capability. But that also means it has no real benefit over the plethora of SaaS options. In fact SaaS platforms tend to offer more functionality. Alternatively some hosting providers offer services to keep WP updated for you. There will be limitations around this.
Mitigation comes at a cost and it can get mighty complicated**.
Costs can quickly reach a tipping point and this is one reason why the vast majority of WordPress sites cease getting updated and patched at some point in time. Many will still make it to the end of their lifecycle and then hopefully get replaced with a new site with the latest version installed.
But the cold hard truth is that vast majority of WP sites beyond 2 years old are left vulnerable to being hacked and a sizeable minority are. Ultimately it's a gamble.
Of course, the above oversimplifies the issues. It's more technical and complex than that and there are ways to (mostly but not completely) mitigate the worst disasters. But this is like solving the gun crisis with more guns rather than accepting that there's a bigger problem. Unfortunately, the only complete solution at this point is don't use WordPress. For me, WordPress is only a remotely viable proposition when it is able to deliver specific functions via a well supported plugin that you cannot build or find elsewhere within the budget constraints (conditional on the client being willing to pay for maintenance). If the same functions can be met via a SaaS Platform, then I would (in fact, I just did) strongly argue that using a platform is the better choice.
** WordPress risk mitigation is complicated due to 4 recurring issues. Version Frequency; Plug-in Support; Customisation; Compatibility.
Every 90 days WordPress.org releases a new version of the WP core software to resolve any vulnerabilites discovered since the previous version release. The 'one-click update' button in WP Admin is misleading as this only applies to updating the core software. However, with the exception of running a basic blog, everything your WP site does relies on 3rd party plugins. Most WP sites have between 8 to 20 plugins. The trouble is, you can't upgrade to the latest WP core without first updating all the plugins. The plugin developers 'should' have updated releases available to download for the new WP version. But, if a plug-in has no update available you either wait, or you replace it with something else (= development time/cost).
Once the plugins are all up to date you can then update the core. At this point, any custom or unique behaviour coded or styled directly on the plugins or WP core files will be overwritten. If your developer has done a good job then modified files will be separated and programming modifications will be well documented for rewriting. But don't expect that to be the case. Once you finally have the plugins and core updated and custom modifications have been re-applied, then you 'should' be back in business.
But, just because the plugins played nicely together in the previous version is no guarantee compatibility of the updated plugins will be same. This can lead to hours of development time to figure out the problem and find a workaround to solve it. Once those issues are resolved then life is good until you repeat the excercise in 90 days time. If your site is well built, on a well developed theme, well supported, and well documented, then updates will usually take about an hour, but not infrequently 2hrs to 5hrs. Ocassionally, but inevitably, things will go sideways and a one hour update can quickly become 10 hours, or worse, days of effort may be necessary to resolve an issue following a bad update.
So you have a choice.. Either live with this recurring 90 day nightmare knowing that sometimes it's going to sting... Or just leave it be. Everything will work fine and you won't face the recurring nightmare. That is until you fall victim to being hacked. If your WP site reaches 3 or 4 years old and has not kept pace with versioning then your risk of being hacked is extremely high
There's a lot I miss about WordPress. It's a great way to rapidly build complex sites. But I can only recall two ocassions where we were not be able to build a site in BC to perform the same high-level functions provided by WP plugins. The key difference with BC sites is that they don't require constant versioning, and none of them have been hacked. Ever! This is a standard I have come to expect, and selling my clients into the flaws of WP fails to live up to my ethical standards.