WordPress non-technical user deployed at Platform.sh!

I’m a big believer in eating my own cooking. So as I’ve moved over to Platform.sh, I felt I should move my personal blog site over. The nexcess.net hosting was working great but – you can’t drive your Ford to the Chevy dealer where you work, can you?

So with that in mind I started with the documentation here:
https://docs.platform.sh/guides/wordpress/deploy.html

and I’d outline the steps as follows. It may take a few blog posts to get through all of this. I won’t say I’ll be adding to the documentation so much as giving some commentary on how I, as a really pretty untechnical non-developer, got through these steps. Most of these steps will be their own blog post, so stay tuned.

Step 1: Decide if this is really right for you.

I’ve always said “horses for courses.” You wouldn’t use Magento for a corner store site, you wouldn’t use WordPress for a single landing page, and you would not really get much benefit from Platform.sh for single sites which are not frequently updated. It’s not the cheapest solution for fairly static, low-traffic sites. So I’d encourage you to use a 30-day trial during a period where you can really put some hours into working with it and see how it fits with your workflows. 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.

Step 2: Get hired by Platform.sh and get a console account as part of that process

(or alternately, sign up for a free demo at Platform.sh and convert to a paid account when that demo period ends. Pricing as of this writing: $10 a month for a developer account after the trial; $50 a month to go live, i.e. connect up your domain to your project. No credit card is required to get a trial account!)

Step 3: Read the getting started documentation.

Seriously, read it. We take an entirely different approach to setting up and deploying sites. I’ve had about 20 years of experience using WHM, cPanel, and proprietary solutions (like Nexcess uses) which provide approximately the same tools. This doesn’t work the same way. At all. It’s entirely Git-driven. I had some confusion about flavors of Git and asked for some advice which I’ll pass along when I write this segment in more detail.

Step 4: Install the required environments on your local machine.

You’ll need to use the terminal window and the command line interface on your machine, be it Linux, MacOS, or Windows. There are some utilities you’ll need (and some more you’ll want) to make this process work smoothly. I had a foolish notion at first that perhaps I didn’t need all this stuff, because I was very used to doing everything server-side. Surely Platform.sh has some GUIs built in somewhere. And we do, but sooner or later you’ll have to do some things in the command line.

Step 5: Learn how to make basic edits and customize configurations for your project.

I frankly struggled with some all of this, because I started out not understanding the workflows. I’m still at about a kindergarten level, but I’m beginning to at least have a box to put the broken pieces of my WordPress worldview in. For example, the big blue “easy” buttons that let you update themes, plugins and WordPress itself aren’t going to work. You’ll need to use Composer, period. Then you will deploy (preferably to a test environment on Platform.sh) and check it all out before pushing it to your production environment. And here’s where you turn the corner and start seeing some gain for all this pain, if you’re like me and you love your easy update buttons. Because if it worked on test it will work on production! That’s why we talk about “deploying on Friday” a lot. By the way, you may not need to worry about updating plugins and themes the second they release updates as much, because Platform.sh deploys everything in a read-only format. Security is a complex topic, but this may mean that you’ve got less vulnerability to certain common WordPress exploits.

Step 6: Go Live!

Once you get your site working the way you want it, you’ll need to upgrade your account and attach a domain to your project. There are some differences in the way this process works with Platform.sh as well. I had to do some tinkering and get some help to get this done right. I’ll develop this thought, along with most of the prior steps mentioned above, in a future blog post.

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.