5 ms·

Any consultants on here that have to deliver/maintain WordPress sites? If so, mind sharing what your basic workflow is? There are many articles on the web, but

Any consultants on here that have to deliver/maintain WordPress sites? If so, mind sharing what your basic workflow is? There are many articles on the web, but they are mostly for very entry level users. The fundamental problem my company runs into with WP is that only a theme can be meaningfully checked into version control. Everything else, including installation of plugins is coupled with entries in the database. And of course the database also includes changes necessarily made on the production instance, like comments to blog posts. Any thoughts or links to posts on this greatly appreciated.

jsalinas 11y ago
There is http://versionpress.net/ http://versionpress.net/ but it's still on early access.
raverbashing 11y ago
You can probably split (by table) bootstrap information (config) from CMS information (posts/comments) A plugin will usually set some entries on installation (then add its work data as well) But yeah, I believe there's an interesting void of supporting tools for WP (it needs to be DevOps'd)
rdrake 11y ago
I've been meaning to try out Revisr [0]. [0] https://github.com/ExpandedFronts/revisr https://github.com/ExpandedFronts/revisr
neurostimulant 11y ago
If you prefer git-based deployment for your wordpress project, bedrock is probably for you: https://roots.io/bedrock/ https://roots.io/bedrock/ Also, wp-cli helps a lot in streamlining the project (enabling/disabling plugins, updating site settings, etc, all from command line or deployment script scripts)
PopeOfNope 11y ago
I worked briefly for a wordpress consultancy last year. Our main workflow involved using Yeoman, Grunt, NPM, wp (the wordpress command line tool) and vagrant. Locally, we'd run vagrant just so we don't have to monkey around with environment issues (too much). Yeoman, grunt, npm and wp were used in tandem to script the creation of a new wordpress install, install any dependencies needed, run any tools needed through grunt (like sass and JS minifiers), and pull plugins and themes from their separate git repositories. We still had to import the database by hand, though, when setting up our environment as well as add lines to wp-config for however we wanted to handle debugging. Then we'd write code and check it in via git as with any other project. If you were working on frontend anything (html,css,js) you either ran grunt all the damned time or ran grunt watch. Those of us who had a hard time with the unique programming requirements of wordpress (escaping, sanitizing, formatting) used phpcs to automate that. As for deployment, we'd just go through the same setup on the server that we do locally. Updates were pushed via git. The fundamental problem my company runs into with WP is that only a theme can be meaningfully checked into version control. Everything else, including installation of plugins is coupled with entries in the database. That wasn't my experience. We separated functional features into separate plugins (so they could be disabled or enabled on a site by site basis) and had no problem using version control with them. In fact, one project had some government security problems and required each plugin to be in its own repo. I wouldn't suggest that, but it works. the database also includes changes necessarily made on the production instance, like comments to blog posts That was something I found aggravating that was never really addressed at the company I worked at. When new people were brought on to a project, they'd get a mysql dump of the staging environment. After that, as new features were added, you were responsible for adding your own test data to see if those features worked. As for production, the changes made that were specific to the production database were made manually in production. When a new plugin was pushed, you had to log into the production instances manually and turn the new plugin on. Luckily, there are hooks you can use to automate any setup or teardown of plugins when they get turned on and off respectively.
girvo 11y ago
Themosis Framework is my life saver, along with WP-ORM
csixty4 11y ago
At 10up, we open sourced our Engineering Best Practices[1]. And we welcome issues & pull requests from the WordPress community. [1] https://10up.github.io/Engineering-Best-Practices/ https://10up.github.io/Engineering-Best-Practices/

jsalinas 11y ago

There is http://versionpress.net/ http://versionpress.net/ but it's still on early access.

raverbashing 11y ago

You can probably split (by table) bootstrap information (config) from CMS information (posts/comments) A plugin will usually set some entries on installation (then add its work data as well) But yeah, I believe there's an interesting void of supporting tools for WP (it needs to be DevOps'd)

rdrake 11y ago

I've been meaning to try out Revisr [0]. [0] https://github.com/ExpandedFronts/revisr https://github.com/ExpandedFronts/revisr

neurostimulant 11y ago

If you prefer git-based deployment for your wordpress project, bedrock is probably for you: https://roots.io/bedrock/ https://roots.io/bedrock/ Also, wp-cli helps a lot in streamlining the project (enabling/disabling plugins, updating site settings, etc, all from command line or deployment script scripts)

PopeOfNope 11y ago

I worked briefly for a wordpress consultancy last year. Our main workflow involved using Yeoman, Grunt, NPM, wp (the wordpress command line tool) and vagrant. Locally, we'd run vagrant just so we don't have to monkey around with environment issues (too much). Yeoman, grunt, npm and wp were used in tandem to script the creation of a new wordpress install, install any dependencies needed, run any tools needed through grunt (like sass and JS minifiers), and pull plugins and themes from their separate git repositories. We still had to import the database by hand, though, when setting up our environment as well as add lines to wp-config for however we wanted to handle debugging. Then we'd write code and check it in via git as with any other project. If you were working on frontend anything (html,css,js) you either ran grunt all the damned time or ran grunt watch. Those of us who had a hard time with the unique programming requirements of wordpress (escaping, sanitizing, formatting) used phpcs to automate that. As for deployment, we'd just go through the same setup on the server that we do locally. Updates were pushed via git. The fundamental problem my company runs into with WP is that only a theme can be meaningfully checked into version control. Everything else, including installation of plugins is coupled with entries in the database. That wasn't my experience. We separated functional features into separate plugins (so they could be disabled or enabled on a site by site basis) and had no problem using version control with them. In fact, one project had some government security problems and required each plugin to be in its own repo. I wouldn't suggest that, but it works. the database also includes changes necessarily made on the production instance, like comments to blog posts That was something I found aggravating that was never really addressed at the company I worked at. When new people were brought on to a project, they'd get a mysql dump of the staging environment. After that, as new features were added, you were responsible for adding your own test data to see if those features worked. As for production, the changes made that were specific to the production database were made manually in production. When a new plugin was pushed, you had to log into the production instances manually and turn the new plugin on. Luckily, there are hooks you can use to automate any setup or teardown of plugins when they get turned on and off respectively.

girvo 11y ago

Themosis Framework is my life saver, along with WP-ORM

csixty4 11y ago

At 10up, we open sourced our Engineering Best Practices[1]. And we welcome issues & pull requests from the WordPress community. [1] https://10up.github.io/Engineering-Best-Practices/ https://10up.github.io/Engineering-Best-Practices/