Inside the WordPress developer community there is the mantra “Decisions not Options” which when applied to the UX/UI of the WordPress application attempts to streamline the user experience by making sensible choices on behalf the user and reducing confusion and clutter.
Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.
We agree 100%. In the context of using the WordPress application, we swim with the current.
In the context of deploying a WordPress application, we believe options reign supreme.
Hosting options not mandates. Flexible deployment and staging for WordPress.
Your dev team is not the average user that needs to be protected from choices, your engineering team is a skilled group of professionals that understand the ramifications of the technical choices they make. They relish their ability to make technical decisions around workflows and tools, it’s sort of why you hired them.
What does your team’s deployment workflow look like? What methods or services do you use?
Likely your workflow is similar to other workflows but unique in most respects to your company. Is it an automated workflow in grunt, or a manual git push, maybe beanstalk or SVN. Perhaps you like to use Capistrano or DeployBot. Maybe you want composer to run on every deploy. It really should be up to you right?
So why then would your WordPress host mandate the way you deploy forcing you to do it their way? I can think of a few good ones, but we believe they do not merit imposing a rigid methodology on our customers.
Our approach is to provide the hooks and advice, then get out of the way. We seamlessly integrate into your existing deployment process vs. forcing you to refactor your process to accommodate us.
More than just a ‘clone’ of another site, a staging site should be a work area to test ideas and changes, verify performance, and determine whether all or some or none of your changes should be pushed into production. Our Pagely Sync tool allows this granular level control. Copy an entire site, tweak it to your hearts content, then push some or all of it back. If during your work you would like to re-sync the staging site, as in pull over a few new files or maybe just 1 db table from production, you can do that too. Follow it all up with a few WP CLI commands to refine your WP instance to your exact specifications. Need more accurate database syncing? You can leverage 3rd party tool’s like WP Migrate DB Pro in your workflow as well.
Options are power.
I agree that your flexibility and control is best for developers.
However it would be nice for non developer site owners just wanting to test out a new plugin to have a one click copy site to staging button – just for speed and convenience.
And leave the power for when we have to call in the developers to make more major site changes.
This is the only thing I want added to the Atomic Panel that I can think of at the moment.
Dale.