Have recently become enamored of subversion, not just as a developer’s tool but as a software management system. WordPress and Drupal installations and updates become trivial when you throw away FTP.
Realized there was no WordPress Codex page on managing WordPress via svn, so I wrote one (Codex is a MediaWiki site). Covers installing and tracking the trunk release, but also (and this is the info I originally set out to find but couldn’t), installing and tracking stable release versions. Linked from the Getting Started/Installation section.
Since there are probably thousands of WordPress blogs that were originally installed without subversion, but that people might want to convert over for the sake of dirt-simple future upgrades, tossed in a recipe for converting “traditional” WP installs to subversion-style installs.
13 Replies to “Managing WordPress with Subversion”
Sounds like awesome goodness, Scot. Very useful. I’ll have to check it out.
bzr. That is all. :)
Oh, thank god. The awful process you have to go through in order to upgrade WordPress is what keeps me, on average, about 2 versions behind the most recent one. That plus the fact that I usually lose all the customizations I’ve made to my templates. It sounds like this is just the ticket. Thank you!!
Glad people are digging it! I really couldn’t believe it when I realized there was no codex page on the topic.
Dylan, I’m surprised you’ve found the WP upgrade process difficult – upload new files, run upgrade.php, and you’re done. The svn version is even easier since you don’t need FTP, but WP is generally praised for its easy upgrades. What have you found difficult about it?
What have I found difficult? Nothing, in principle, but the instructions are daunting and there are a lot of steps involved:
Download FTP package. Unzip package to local desktop. Backup database. Backup files. Deactivate plugins one by one. Upload files via FTP. Make sure you delete old files. Run upgrade script. Switch theme back to your old one. Reactivate plugins. Whew!
I figure this process can be done in 20 minutes but could easily take an hour if things go awry. And it has to be done sometime when people aren’t likely to be hitting your site, because it all happens live — meaning the formatting & functionality of the site get screwed up, depending on how much you rely on plugins and the custom theme.
Hmm… you’re right – if you follow all the instructions there, it really would take quite a bit more time. Personally, I think those instructions are a bit on the paranoid side, and also geared for users who might be intimidated to, say, go into phpmyadmin and disable a plugin if one broke and it totally screwed up the site.
Personally, I stopped backup up WP before upgrades, and I also don’t deactivate plugins. Have yet to encounter a single problem. Possibly, a bit risky possibly, but I also know I can fix things in other ways if something were to go wrong.
Hmm… I should probably note on the Codex page that the instructions there don’t respect the suggestions to deactivate plugins and back up the db… OK, caveats added to the wiki.
I’ve been avoiding upgrading my WP install, especially as I have made a few changes to the core files. I’m gonna have to give this a spin though, sounds like it will make life a lot easier and stop me from worrying so much abou living with an old version.
Dan – Out of curiosity, why have you had to edit core files? Ouch. Never an ideal situation, and usually avoidable via plugins.
How stable is this? I’m sick of dealing with the crappy update procedure used by wordpress (copy files a,b,c over d,e,f but do not delete g, unless you have h. etc), and would love to replace this with a nice simple “svn up”.
Sorry Scot, I never answered your question – the reason I modified the core files was largely ignorance. There are, it seems, several different function calls for doing something like displaying a list of categories. I didn’t realise this, and just saw the function calls in the templates I was using. They weren’t flexible enough for me – I wanted to display specific things before, between and after each category depending on whether it was the first or last category or one in between, so I just updated the core functions to work in the way I wanted them to work.
And I’m with Simon on this – upgrading seems too much like hard work to me (although, having not actually had the courage to try it yet, I’m probably not the best person to judge).
Simon – Despite what the instructions say, I never disable all plugins, back up database, etc. before upgrades. I just go for it and overwrite. I figure I can always go into phpmyadmin and disable plugins after the fact if somehting were to break. But nothing ever breaks. So, yes, that’s a bit hasty perhaps, but it saves SO much time. Likewise, my svn instructions bypass the “disable plugins / back up database” instructions. Haven’t heard of any issues yet, but caveat emptor. There’s some talk on the forums about a future change to the entire way WP is upgraded – in the future I think there will be a slick web-based UI for this that takes care of all the safety stuff automatically.
Dan – I believe you, but am surprised – I’ve found the category tags extremely flexible in terms of what you can put before/after, arrangement, etc.