My previous post was a description of my efforts to get WordPress working on Platform.sh. As a first step I suggested that you should decide if this is really right for you. The more developers you have, the more sites you maintain, the more frequently you update them, and the more scalability matters to you, the more benefits you will see.
More traditional hosting options give you more GUIs and nowadays it’s possible to deploy WordPress without ever interacting with a command line – just get things configured and use those “easy buttons” to add, delete, and update plugins and themes. Theme editors are so powerful today that WordPress can be a practically “no-code” option for creating content.
I won’t go too far into the pros and cons of this approach, but while it’s extremely easy to manage WordPress this way, it has limitations and risks:
Security
WordPress hacks often depend on the ability that a WordPress administrator has to make major site modifications, especially via plugins and themes. It’s relatively easy to write a script that will maliciously add and change content, and then if access is gained via a compromised admin password, the possibilities are endless (endlessly bad). A site deployed on Platform.sh using Git workflow will largely, and by default, be “read-only” – there is still a database that the application can write to (for post, pages, and certain configuration issues, like theme appearance), but the administrator is not able to simply sftp file changes to the WordPress application itself. A compromised admin account could still do damage in a number of ways, most obviously by changing the pages and posts content – so use strong, unique passwords regardless.
Keeping WordPress and its plugins and themes updated is an important part of security, and the way Platform.sh (along with a Git workflow) facilitates doing updates via Composer, testing those updates on development branches, and then pushing them to the production instance virtually assures that managing updates is risk-free.
Scalability
Messing around with a WordPress site as I’ve described above works fine if you’re the only person responsible (and if you maintain backups); it’s less great impossible if you’re part of a team of developers. Implementing version control like Git is going to be inevitable if you have multiple developers working on the project anyway, and once you’ve got that going deploying on Platform.sh is arguably easier.
If you maintain a fleet of sites this scalability also provides tangible benefits, as you can develop templates and projects that provide starting points, saving you a lot of repetitive work. If you only maintain one site, however, you will not get as much benefit from this.
If you only have one or two sites, do all the work yourself, and aren’t interested in the idea of learning Git workflow, Platform.sh may cumbersome to you when compared to more traditional managed hosting that gives you GUIs to manage files, databases, and even code. But if you maintain a number of sites with a team or teams of developers, the benefits will become obvious.
Opinions expressed are my own and not those of Platform.sh. I’m an account manager and (obviously) not part of the technical team there. I work alongside the sales and marketing teams but am not directly writing all this to sell you anything. Rather, I’m trying to organize my own thoughts about how this process goes to help myself (and maybe others) do it more smoothly in the future.