Hacker News new | past | comments | ask | show | jobs | submit login
Git Management for WordPress (revisr.io)
70 points by matthijs_ on July 1, 2014 | hide | past | web | favorite | 26 comments



Wordpress is less than ideal for managing via git, primarily due to their plugin architecture. The best way I have managed to use git is to put the repo at the wp-content level and only watch the theme and plugin directories. Then anytime I make updates to a plugin or group of plugins, I make sure to commit those changes as a seperate commit to what I am normally working on. It is tedious and hacky, but it at least gets me basic version control functionality with the ability to roll back on any code that can effect theme functionality.


This is my workflow as well. Not ideal, but better than nothing.

Though I will say the biggest pain point with Wordpress is syncing and merging DB changes amongst team members, since so much of WP configuration is stored in the DB this becomes a real point of frustration especially on very large sites. I'd peg that problem as a much higher priority in terms of WP workflow than how to manage git inside WP admin.


this is a massive problem with all kinds of CMS including Drupal which we are using often. Drupal 8 is introducing configuration management, i.e. saving database configuration in yaml files which makes them "gittable". I hope wordpress and other CMS will also adopt this or a similar way.


The Features module in Drupal 7 is a semi-workaround https://www.drupal.org/project/features but I've hated Drupal a lot because of this. Too much stuff is stored in the DB.


Forum One just released a sort of "Features for Wordpress" plugin:

http://forumone.com/insights/configuration-management-finall...

https://github.com/forumone/wp-cfm


It seems as though it works in reverse from a normal git setup--items which get changed on the server directly through say a UI initiated upgrade can be tracked and reverted in GIT from a dashboard. Kinda cool for single server installs.

Storing the DB state in GIT is going to be an issue with a site of any substance.


I've done this before (though not using this solution), and I'll never do it again. Managing Wordpress (and the database backups) with Git causes ENORMOUS history files over time, to the tune of many gigs on the server depending on the size and configuration of the site. It isn't worth it. Perhaps only monitoring a couple directories (such as plugins) would be better, but too limited for a serious whole-framework solution.


I use a .gitignore in root directory and ignore everything but the files that I control - theme and custom plugins.


Slightly offtopic: was surprised yesterday when publishing my first plugin at wordpress.org to find they use SVN.

Thankfully there was a deploy.sh script on github [1] which could be used to deploy your plugin from git repo straight to wordpress.org's SVN repo. :)

[1] https://github.com/pdclark/deploy-plugin-to-wordpress-dot-or...


Wordpress in next to not manageable with git anyway in my experience.The plugin system is totally broken when it comes to versioncontrol. Anything added to wordpress might f.. up the db or the cms itself. Wordpress codebase is f.ed up, ugly, badly architectured yet this is the most popular CMS and its ecosystem is huge. It's amazing and scary.


You sound like you may not know how to do it. I manage a medium-large sized site with Wordpress and git and it works great. Why would you ever try to check plugins into git? You are not supposed to touch anything outside of your theme folder. I have never had any issue updating anything.


> You are not supposed to touch anything outside of your theme folder.

Uh, what? Any medium/large site inevitably ends up with a few custom plugins.


Treat plugins as separate and independent modulse, just as you would in any other project and put each plugin into their own git repository.


Plugin functionality can be coded into the theme itself. Unless it isn't 'custom' that is. Then there is a plugins folder.


Themes should only be used as templates. Functionality for the most part belongs in plugins.


Thats a pretty bold statement. Kind of curious the reasoning


I guess I view this separation as an adaption of The Single Responsibility Principle. This is how I view themes & plugins, and their relationship. Your theme is used to display your site, it's navigation, content, it controls the markup browsers see.

Plugins are for adding functionality to your site, if you want a sitemap, there's a plugin for that. Not happy with your current sitemap? Install/Create a new plugin, replacing the old one. If your sitemap isn't working, where do you look? Your sitemap plugin's code.

The importance of having this separation of tasks, removes a lot of risks too in my opinion. If your site isn't working instead of risking having to change your theme, you can deactivate the troublesome plugin. Albeit finding the offending may be difficult, but at least you're not changing the total design of your site.

Hence why I believe in plugins and themes having distinct tasks. It really helped me organise the development, and maintenance of sites.

Here's a pretty decent setup for using git with WordPress too. https://github.com/markjaquith/WordPress-Skeleton

http://en.wikipedia.org/wiki/Single_responsibility_principle


This is why I love HN. Such an in-depth smart response. Really making me rethink how I build on WP. Thank you


First time I've contributed something of value on here. Thanks!


Great job: making Git work outside it's familiar environment is a headache, but such an important problem to solve. It looks like they are some point on the way to doing it with Wordpress, so all the props to them. Keep on keeping on and don't let the naysayers get you down!


Very useful for situations where SSH access is not allowed but exec('git'); is :)


So what would you say is the benefit of this over a basic github integration?


database changes I think?


Trying to compete with versionpress.net?


Considering this is shipping I'd say it's rather the other way around.

Versionpress sound like they're going to try something a bit smarter with the database file though.


Version press still doesn't have a defined pricing structure. Competing against Open Source on Github doesn't bode well for them!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: