meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Subverting WordPress

I’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!

21 Responses»

    • #1
    • Comment
    • Wed 3 Sep 2008
    • 2125
    Peter J. wrote in to say...

    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.)

    • #2
    • Comment
    • Wed 3 Sep 2008
    • 2128
    Zack wrote in to say...

    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.

    • #3
    • Comment
    • Wed 3 Sep 2008
    • 2135
    Kevin Skoglund wrote in to say...

    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.

    • #4
    • Comment
    • Wed 3 Sep 2008
    • 2236
    Tim Barsness wrote in to say...

    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# with header.php.mine, classes.php.rev# with classes.php.mine, etc.

    • #5
    • Comment
    • Wed 3 Sep 2008
    • 2237
    Tim Barsness wrote in to say...

    vendor branch, sorry

    • #6
    • Comment
    • Wed 3 Sep 2008
    • 2355
    Noel Jackson wrote in to say...

    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.

    • #7
    • Comment
    • Thu 4 Sep 2008
    • 0121
    Jilles van Gurp wrote in to say...

    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.

    • #8
    • Comment
    • Thu 4 Sep 2008
    • 0145
    Steven Ametjan wrote in to say...

    Maybe I’m under-thinking this, but could you not just merge the tag into your working copy?

    • #9
    • Comment
    • Thu 4 Sep 2008
    • 0403
    David wrote in to say...

    Obviously you need SVN with a half gainer. That’s the trick.

    • #10
    • Comment
    • Thu 4 Sep 2008
    • 0505
    Skipchris wrote in to say...

    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?

    • #11
    • Comment
    • Thu 4 Sep 2008
    • 0551
    Andrew Nesbitt wrote in to say...

    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.

    • #12
    • Comment
    • Thu 4 Sep 2008
    • 0617
    Adrian Simmons wrote in to say...

    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!

    • #13
    • Comment
    • Thu 4 Sep 2008
    • 1046
    Eric Meyer wrote in to say...

    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.

    • #14
    • Comment
    • Thu 4 Sep 2008
    • 1048
    Eric Meyer wrote in to say...

    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“.

    • #15
    • Comment
    • Thu 4 Sep 2008
    • 1050
    Eric Meyer wrote in to say...

    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…

    • #16
    • Comment
    • Thu 4 Sep 2008
    • 1532
    Ben Lowery wrote in to say...

    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.

    • #17
    • Comment
    • Wed 10 Sep 2008
    • 1809
    Scott wrote in to say...

    Andrew Nesbitt said it first so: DITO on Git/Github.

    • #18
    • Comment
    • Thu 18 Sep 2008
    • 1235
    Michael Ridley wrote in to say...

    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

    • #19
    • Comment
    • Sat 25 Oct 2008
    • 0938
    Simon wrote in to say...

    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.

    • #20
    • Comment
    • Tue 9 Dec 2008
    • 1537
    regis wrote in to say...

    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

    • #21
    • Pingback
    • Tue 20 Jan 2009
    • 0846
    Received from 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 […]

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


September 2008
SMTWTFS
August October
 123456
78910111213
14151617181920
21222324252627
282930  

Sidestep

Feeds

Extras