Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Source Control / Continuous Integration Advice

Hi folks,
I'm trying to setup a source control / CI process that makes it easy for us to modify plugins/themes and also to upgrade vanilla. Up until now, we had a fork of vanilla where we had our own branch that contained plugins, themes (as submodules), and minor modifications to vanilla core (ie bootstrap.after.php). Each time a new version was released, we'd follow these steps to rebase our branch against the new version's tag. But somehow this broke, and rebasing throws hundreds of conflicts. And frankly, it's beyond my git knowledge.

So I'm back to the drawing board, and I'm thinking perhaps we should just have a "plugins" repo, our theme as a repo, and perhaps an "applications" repo... or maybe one big repo with those 3 folders in it. And we'd install vanilla from source and then clone that repo on top of it. And then put in the config.php file and apply the CHMOD commands... but I'm not sure we can have two repos sitting in the same directory. In a WordPress setup, we'd treat wordpress as a vendored dependency, in the vendor directory, and tell wordpress to use our "plugins" folder. But Vanilla comes with plugins, so we can't point it to another folder unless we pull in those plugins.

Does anyone have a good system for this? Ideally I'd like to automate this with CI but frankly even a good, easy process would be preferable to what we have now.

Thanks for your help


  • hgtonighthgtonight ∞ · New Moderator

    Base directory contains vanilla git repo and any other repo (like my addon repo)

    public web directory has the vanilla repo symlinked as well as my addons symllinked into the public/vanilla/plugins directory

    You can still use git to update/develop, while keeping them separately.

    Every modern filesystem supports symlinks. Even NTFS supports it.

    Search first

    Check out the Documentation! We are always looking for new content and pull requests.

    Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.

  • LincLinc Detroit Admin
    edited July 2016

    For our cloud infrastructure, we have a code folder with all our repos in subfolders. In the vanilla repo, we symlink in all our plugins, themes, etc from other repos. Then we have a pusher script that makes a copy of the vanilla repo (following the symlinks). Our webroot is re-pointed at the new copy, and the old copy is purged.

    My personal production setup is a little less pro: I have a script that copies each repo in succession to my webroot (I manually have each repo included in the script so it knows which subfolder goes where, like addons/plugins => main plugins folder). This is much less elegant because you can experience errors in the switchover, plus you have to remember to manually delete anything you no longer want in your web directory, but it's much easier to setup and I'm not running a large scale operation. If someone gets a bugged pageload one time during the 2-second copy, I really don't care.

    My personal localhost is even "simpler": every webroot is just a bundle of symlinks. I have a "master" symlink collection for plugins, themes, and applications, and then each of those folders is symlinked to each webroot. This isn't good for production because you don't want your repos directly running in a webroot. But it does let you roll out new test sites really easily (and allows each to have their own config & uploads while keeping code sync, and 1 new symlink adds a plugin to every site).

  • edited July 2016

    Thanks for the advice! I feel like I'm almost there with this:

    git clone --branch Vanilla_2.2.1
    git clone
    git clone
    git clone
    ln -s $(readlink -f vanilla-plugins/*) $(readlink -f vanilla/plugins/)
    ln -s $(readlink -f vanilla-api) $(readlink -f vanilla/applications/api)
    ln -s $(readlink -f vanilla-bootstrap) $(readlink -f vanilla/themes/bootstrap)

    (Pretty sure the readlink -f stuff is necessary but let me know if that looks silly.)

    The only thing missing here is config.php and the chmod commands that vanilla requires (to /conf, /cache, and /uploads). Do you put your config.php in source control with env vars? Or do you just keep the definitive copy on your server?

    EDIT: Another thing I've done is copied config.sample.php and used sed to edit the lines I need to (example)

  • Hey guys, any thoughts on the config.php and chmod workflow?

Sign In or Register to comment.