Subverting WordPress
Published 16 years, 2 months pastI’m going to get back to posting here in just a bit with word of conference appearances (some overseas), plugin updates, and a small elegy, but first I need a little help with WordPress and subversion, if someone could spare the cycles to assist a newb. (Which would be me.)
So I have meyerweb’s WordPress install all subversion-managed. The only problem is that there are three core files I’ve had to hack (reasons upon request) and that makes updating really icky. I fire off…
svn sw http://svn.automattic.com/wordpress/tags/2.6.1/ .
…(where 2.6.1 is replaced with whatever the latest version is) and it updates everything. For my custom-altered files, though, I get diff files and a .mine file that has my old copy and then a copy that’s littered with diff markers, which cause PHP error-crashes, which takes down the site. At least until I go in and copy the .mine files over the diffed-up files.
So: how do I do some kind of local checkin of the altered files so that I don’t attempt to post them back to the WordPress codebase (these are very specialized hacks) but future WordPress updates don’t break my site? For extra ideal points, it would be great if those files were updated with my changes merged into the files. If it helps, the files thus affected are /wp-blog-header.php, /wp-includes/classes.php, and /wp-admin/edit-form-advanced.php. Thanks for any help!
Comments (21)
Sounds like you want to apply the “vendor branch” pattern—basically you keep your own repository and merge in each release. The SVN book has a chapter about it. (You can do the same thing with just about any revision control system; I regularly get tarballs and drops from SVN, CVS and Bazaar and store and manipulate them in Perforce, since merging between branches and tracking local changes in P4 is so much easier.)
Instead of pulling each release from SVN, I did the following:
1. Created my own SVN repository, and import the starting WP release into it. Make changes, develop on local machine, and check out a copy on the web host.
2. When a new release comes out, I make a patch file using diff from the previous release to the current release. I’m using the .tar.gz files from wordpress.org to do this now, but I’d assume that it could be done totally within subversion. I wrote up instructions for doing this here:
http://zackofalltrades.com/2007/06/quick-guide-to-using-diff-and-patch-to-update-a-wordpress-weblog/
3, I then apply the diff file to my version. If it applies cleanly, I check into SVN and check out on the web host. If not, I make changes as necessary.
This works really well for me because I maintain several WordPress blogs, and I’ve got applying the diff to all the sites scripted. Also, by maintaining my own repositories, I can easily roll back to a different version with all my changes intact.
svn sw pulls down the changes and then shows you where there are code conflicts with your local copy (the .mine file). Resolving the conflicts is always a manual process.
If you can, move all of your customizations to the wp-content folder or to any file that doesn’t exist in the repository version. Then you won’t get conflicts. If you can’t move them into their own files look at setting it up as a vendor branch (http://svnbook.red-bean.com/en/1.1/ch07s05.html). If that doesn’t work, my last guess would be to try to work it out with svnmerge or piston.
You also might have better luck using Git instead of SVN.
If you want to forgo a vendor brank, you can also combine the commments of all three, doing a svn sw as you are and then diffing
header.php.rev#withheader.php.mine,classes.php.rev#withclasses.php.mine, etc.vendor branch, sorry
Eric, you probably want to use Filters/Actions for hacking WordPress – or send in your patches to trac.wordpress.org and the boys can make it part of the core code.
Check out: http://codex.wordpress.org/Plugin_API
The functions.php could be of some big help too. It load custom functions that you would ordinarily put into a plugin.
I’ve used the vendor branch pattern for a while and it’s a bit messy. I ended up with a non working setup several times only to find out that the merge somehow resulted in a setup that was quite different from what is actually in the wordpress svn. I’ve given up on the notion of maintaining my handful of modifications for now.
A possible way out would be to use a more capable distributed versioning system like mercurial or GIT that is able to pull changes from upstream into a local branch and has more robust merging.
Maybe I’m under-thinking this, but could you not just merge the tag into your working copy?
Obviously you need SVN with a half gainer. That’s the trick.
I might be being a bit newb-ish here, but would svn:ignore solve the problem?
svn propedit svn:ignore wp-blog-header.php,
svn propedit svn:ignore wp-includes/classes.php,
svn propedit svn:ignore wp-admin/edit-form-advanced.php
Maybe?
Here are two suggestions from a ruby on rails developer perspective:
1. Github is the new hottness in hosted version control, there are a number of daily updated mirrors of the wordpress subversion repo there, you could fork wordpress on there, add your changes to the files you need and still keep up with the master branch of wordpress.
2. Using a tool like capistrano, you could automate the checkout and deployment of wordpress from subversion and setup a simple after deploy task that symlinks in your custom files and assets into the wordpress folder after it has been checked out.
As Peter J says, you need a vendor branch and your modified ‘local branch’, and to merge changes between them when updating.
You might also want to check out SVK, it works with SVN but has much better merge – the same principle applies though, use a vendor branch!
Noel: I might want to, yes; but can’t, unless there’s a hook that will comment out lines 39-144 (as of 2.6.1) of classes.php. Furthermore, I think merging that change into the WP core would be a Very Bad Idea.
Ditto edit-form-advanced.php, in which I rearranged some of the markup to be more to my liking. I don’t think a plugin will be able do that for me, and having those changes in core isn’t a great idea either.
I have asked in the past for a hook that will allow easy disabling of WP’s rewrite rules—I have my own, and don’t want WP fighting me over them—but so far as I know it still doesn’t exist. If it’s ever added, I’ll gladly stop modifying classes.php and write a plugin to do what I need. Until then, though, I’m stuck with this situation, which is a serious drag on my enthusiasm for upgrades.
Steven: you might be right. I’m not sure, though, because I don’t understand exactly what you mean. I’m a newb, remember? Everything I know about subversion I learned from reading “Installing/Updating WordPress with Subversion“.
Skipchris: interesting idea. I was unaware of ignore, and it would be at least similar to what I was already doing. What I really want, though, is a way to get changes to the files from the base repository while merging in my alterations. Maybe what I want isn’t possible, but I live in hope…
I do what you’re trying to do by using git and git-svn. git-svn mirrors the wordpress svn repo into my git repository and I have a branch that is effectively wordpress’ trunk + my changes. When wordpress updates, I pull the changes into git and merge them into my branch if I like them.
The repo is at http://www.github.com/blowery/wordpress if you want to take a peek (http://github.com/blowery/wordpress/tree/ben%2Ftrunk is my branch of wordpress). I also use a git submodule to track the theme I use, but that’s another story. Another nice thing about doing it this way: my plugins, uploaded content and other ephemera for my particular install are all captured in git. With plain svn, this is a bit harder.
As others have said, you can do this with svn vendor branches too. I just did it with git because I happen to like it better, and I find it easier to maintain my branch with it.
Andrew Nesbitt said it first so: DITO on Git/Github.
Eric-
I wrote a post on this the other day for our company blog, but what I do is keep my Subversion copy of WordPress empty except for the things I’ve changed – plugins, new themes, etc. I apply the new WordPress release directly to the “live” copy, and I merge in any changes to the files in the working copy as new releases come out. Since I am only modifying a tiny subset of the WordPress code, there’s no benefit to me to having the entire WordPress code base in my Subversion working copy.
This approach works for me because I am mainly editing custom themes or plugins which are in no way affected by WordPress updates. I do sometimes hack on the main code tree, but it’s only one or two files so it doesn’t inconvenience me to update that if the main line code changes.
By following this strategy I try to keep my custom client-specific WordPress code independent of the version of WordPress that’s actually installed on the live web site. It works pretty well.
Hope that was helpful!
-m
I support the idea for a hook that will allow easy disabling of WP”s rewrite rules. I am going to send in my patches to trac.wordpress.org too. May be they can find possibility to make it part of the core code.
This worked like butter for me – in the working dir run:
svn merge curversionurl newversionurl
so going from 2.6.3 to 2.6.5:
svn merge http://svn.automattic.com/wordpress/tags/2.6.3 http://svn.automattic.com/wordpress/tags/2.6.5
Pingback ::
Keeping things in sync with Wordpress releases via SVN using vendor branches « Tales from the Script
[…] an option (except for plugins, of course). I’m certainly not the first to face this problem; Eric Meyer has (had?) similar […]