PDA

View Full Version : How to simplify upgrading a customized vbulletin


squidsk
30 Mar 2015, 17:08
Note: this article's suggestions work best when doing upgrades between vBulletin releases with the same major version (i.e. 4.x.a to 4.y.b) though it can be used with more work on upgrades between major versions.

Requirements

(L/W)AMP server
git distributed version control
ability to open .tar.gz or .zip files


Overview of how this works
This system works by having two git repositories setup on your computer, one to simulate the upstream changes made to vBulletin and the second to be the local, downstream, repository where you record the changes you've made to your vBulletin install. When a new version of vBulletin is released that you are upgrading to you grab the new version of vBulletin, upload it to your server and let the marvels of git rebase save you hours if not days of your life.

Step 1 - Setup the vBulletin repository

make directory for the repository (e.g. mkdir /usr/src/vbulletin or ~/src/vbulletin)
go to the above directory (e.g. cd /usr/src/vbulletin)
run command git init


Step 2 - Setup the local repository for your vBulletin customizations

make directory for the repository (e.g. mkdir /var/www/forum or ~/public_html/forum)

If you've already got vBulletin running create this repository in a temporary location (i.e. /tmp/forum)

go to the above directory (e.g. cd /var/www/forum)
run command git init
edit the git config to point to the upstream repository, add the following code
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

remote = origin
merge = refs/heads/master
[remote "origin"]
url = /usr/src/vbulletin/.git
fetch = +refs/heads/*:refs/remotes/origin/*

Where the url in the remote "origin" section is the location you created the git repository in step 1
run the command git fetch
run the command git checkout -b master origin/master


Notes:

You should now have two empty repositories with no files in them, you can verify this by running the command git log in both directories and you should see nothing.
If you've already customized your vbulletin site create a new location for the repository we will move the repository later to its final location.
Ideally this directory will be where your "live" code resides once you've completed Step 4.


Step 3 - Install base vBulletin

Download the version of vBulletin that your site is running or will be running (any format you can extract)
Extract the contents of file downloaded in the previous step (not to your repository locations)
Make the following changes to the files

rename includes/config.php.new to includes/config.php
(optional) if using a renamed admincp rename admincp to your chosen name
(optional) if using a renamed modcp rename modcp to your chosen name
delete the install folder (you may want to just move the folder somewhere else to facilitate running the install/upgrade script)
(optional) on linux change the end of line characters of all files use the command:
fromdos `find * -exec file {} + | grep -w text | awk '{print $1}' | sed s/:$//`
Note: those are backticks not single quotes surrounding the argument to the fromdos command

copy the contents of the upload directory to location of the repository from step 1
change your location to be the directory for the repository from Step 1 (e.g. cd /usr/src/vbulletin)
run the command git add . this adds all files to the list of files to be committed
run the command git commit -m 'version' where version if the version number (e.g. 4.2.3)
change your location to be the directory for the repository from Step 2 (e.g. cd /var/www/forum)
run the command git fetch
run the command git checkout -b master origin/master

Note:

At this point in both repositories if you run an ls (dir on a windows server) you should see all the files from the upload directory of the vbulletin version you downloaded. If so you're now ready to start customizing your vbulletin install.
Another check is to the command git log in both repositories, you should see a single entry for the version of vbulletin you just installed.
The repository from step 1 should now only be used when you are upgrading your version of vbulletin. If you are customizing your vbulletin version (i.e. changing core files or installing plugins or custom code) then you should be working in local repository location.


Step 4 - Add your vBulletin customizations

make changes in the vBulletin customization repository

copy files into the directory, including your previously customized vBulletin
directly edit files within the directory
delete files within the directory

run the command git add . to add all non-delete changes to the list of changes to be committed
run the command git add -u . to add file removals to the list of changes to be committed
run the command git commit this will open a text editor to allow for a detailed commit message
Repeat these steps as necessary for further customization

Note: During the initial setup if you had a pre-existing vbulletin install after you have added all customizations you should replace your "live" folder with the folder that has the customized vBulletin repository. This way you don't need to maintain files is multiple places.

Step 5 - Upgrading your vBulletin version
To upgrade your version of vBulletin you follow mostly the same process as in Step 3 above with a few critical differences, noted in red and blue text.

Commit all outstanding changes in local customization repository!!! as per Step 4 - Any uncommitted changes will be lost, you've been warned!
Download the version of vbulletin that you will be upgrading to, the full version recommended to keep the headers consistent (any format you can extract)
Extract the contents of file downloaded in the previous step (not to your repository locations)
Make the following changes to the files

rename includes/config.php.new to includes/config.php
(optional) if using a renamed admincp rename admincp to your chosen name
(optional) if using a renamed modcp rename modcp to your chosen name
delete the install folder (you'll may want to just move the folder somewhere else to facilitate running the install/upgrade script)
(optional) on linux change the end of line characters of all files use the command:
fromdos `find * -exec file {} + | grep -w text | awk '{print $1}' | sed s/:$//`
Note: those are backticks not single quotes surrounding the argument to the fromdos command

delete the contents of the repository from Step 1 (to deal with files that got removed in the new vBulletin version)
copy the contents of the upload directory to location of the repository from step 1
change your location to be the directory for the repository from Step 1 (e.g. cd /usr/src/vbulletin)
run the command git add -u . this adds all removed files to the list of changes to be committed
run the command git add . this adds all new/changed files to the list of files to be committed
run the command git commit -m 'version' where version if the version number (e.g. 4.2.3)
change your location to be the directory for the repository from Step 2 (e.g. cd /var/www/forum)
run the command git reset --hard HEAD this commands reset the custumized vBulletin to its last commit, and is required to upgrade your vBulletin install
run the command git fetch
run the command git rebase origin/master
if a conflict is found start the steps for git rebase conflict resolution

merge the conflicting code
run the command [b]git rebase --continue
if a conflict is found go to step 1 of git conflict resolution

after completing the git rebase you'll need to run the upgrade script for the forum if you aren't applying a patch


You can repeat steps 4 & 5 as often as necessary, mostly you'll be doing step 4 as you install plugins, custom code, or alter the core code for vBulletin.

TheLastSuperman
22 Jan 2016, 21:59
Article approved! Nice one too squid, thanks for taking the time to outline this for everyone :D.

ub.ch
29 Feb 2016, 14:47
Heya!

thank you so much for the article!

I still have a question

As far as I understood the changes made in my local repository (so eg /var/www/) are never pushed?
I am still confused as to how this exactly works, but shouldn't changed that have been commited also be pushed?
Especially if you were to have a dev environment and a live environment.

My plan is to "work" on the dev env, to rebases etc, and once done push all those commits to live.
Or - if absolutely need be - do changes on live and push them back to the repo to also have them on dev

As far as I can see this does not work?
Seeing that the changes made in /var/www are never pushed?
Or am I missing something?

Again thank you so much for posting!

squidsk
29 Feb 2016, 16:39
Heya!

thank you so much for the article!

I still have a question

As far as I understood the changes made in my local repository (so eg /var/www/) are never pushed?
I am still confused as to how this exactly works, but shouldn't changed that have been commited also be pushed?
Especially if you were to have a dev environment and a live environment.

My plan is to "work" on the dev env, to rebases etc, and once done push all those commits to live.
Or - if absolutely need be - do changes on live and push them back to the repo to also have them on dev

As far as I can see this does not work?
Seeing that the changes made in /var/www are never pushed?
Or am I missing something?

Again thank you so much for posting!
To do what you want you'd need a third level repository for your live site that is downstream from the second repository in the article.

Something like:

vb repo
|
dev repo
|
live repo

The dev repo is the second repo from the article. You use it to deal with upstream changes from vbulletin as well as your own customizations. Once you have all of that dealt with you can fetch the changes in the live repo and reset to HEAD, which will update/add/delete all relevant files.

ub.ch
29 Feb 2016, 16:45
thanks for the very quick reply!

I am not sure I understand correctly.
the dev repo has the vb repo as remote, so all changes that are pushed will land there?

Right now I can't push any changes made in dev:

[email protected]:/var/www/test.site/docs# git status
# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
# (use "git push" to publish your local commits)
#
nothing to commit, working directory clean



[email protected]:/var/www/test.site/docs# git push
warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:

git config --global push.default matching

To squelch this message and adopt the new behavior now, use:

git config --global push.default simple

When push.default is set to 'matching', git will push local branches
to the remote branches that already exist with the same name.

In Git 2.0, Git will default to the more conservative 'simple'
behavior, which only pushes the current branch to the corresponding
remote branch that 'git pull' uses to update the current branch.

See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)

Counting objects: 11497, done.
Delta compression using up to 3 threads.
Compressing objects: 100% (8366/8366), done.
Writing objects: 100% (11158/11158), 442.61 MiB | 14.21 MiB/s, done.
Total 11158 (delta 3073), reused 10446 (delta 2574)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To /usr/src/vbulletin/.git
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '/usr/src/vbulletin/.git'

squidsk
29 Feb 2016, 18:54
No you don't push to the vb repo, since you have to treat it as a repo you can't edit, which you can't since you have no control over the code vb creates. You fetch from the dev repo on your live repo. All work on your dev repo will be in a branch that isn't HEAD so you aren't fetching non-head commits from your live site.

ub.ch
29 Feb 2016, 19:03
ah I see!
It's just that your Step 4 did not say anything about using a branch - that's maybe where my confusion came from

squidsk
02 Mar 2016, 16:32
That's because in the instructions above I leave how you administer your repo and how you want to handle doing your changes to yourself. The best practice for using git is that any changes you make to your repo are done on a branch and when finalized merged back into HEAD. The instructions are for setting up a simple method of applying vbulletin changes to a location where you have your own customized changes to vbulletin. How you track your customization to the vbulletin code base is up to you, as is any additional infrastructure you want to add around the above process.

ub.ch
02 Mar 2016, 22:41
ok :)
I am fairly new to git, I do understand the basics but rebases etc are a bit over my head atm - thats the reason behind my numerous questions ;)

Thanks again!
Your help made things and my future env setup a lot clearer!