Go Back   vb.org Archive > vBulletin Article Depository > Read An Article > vBulletin Tips & Tricks
FAQ Community Calendar Today's Posts Search

Reply
 
Thread Tools
How to simplify upgrading a customized vbulletin
squidsk's Avatar
squidsk
Join Date: Nov 2010
Posts: 969

 

Show Printable Version Email this Page Subscription
squidsk squidsk is offline 03-29-2015, 09:00 PM

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
  1. (L/W)AMP server
  2. git distributed version control
  3. 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
  1. make directory for the repository (e.g. mkdir /usr/src/vbulletin or ~/src/vbulletin)
  2. go to the above directory (e.g. cd /usr/src/vbulletin)
  3. run command git init

Step 2 - Setup the local repository for your vBulletin customizations
  1. 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)
  2. go to the above directory (e.g. cd /var/www/forum)
  3. run command git init
  4. edit the git config to point to the upstream repository, add the following code
    Code:
    [core]
            repositoryformatversion = 0
            filemode = true
            bare = false
            logallrefupdates = true
    [branch "master"]
            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
  5. run the command git fetch
  6. 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
  1. Download the version of vBulletin that your site is running or will be running (any format you can extract)
  2. Extract the contents of file downloaded in the previous step (not to your repository locations)
  3. Make the following changes to the files
    1. rename includes/config.php.new to includes/config.php
    2. (optional) if using a renamed admincp rename admincp to your chosen name
    3. (optional) if using a renamed modcp rename modcp to your chosen name
    4. delete the install folder (you may want to just move the folder somewhere else to facilitate running the install/upgrade script)
    5. (optional) on linux change the end of line characters of all files use the command:
      Code:
      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
  4. copy the contents of the upload directory to location of the repository from step 1
  5. change your location to be the directory for the repository from Step 1 (e.g. cd /usr/src/vbulletin)
  6. run the command git add . this adds all files to the list of files to be committed
  7. run the command git commit -m 'version' where version if the version number (e.g. 4.2.3)
  8. change your location to be the directory for the repository from Step 2 (e.g. cd /var/www/forum)
  9. run the command git fetch
  10. 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
  1. 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
  2. run the command git add . to add all non-delete changes to the list of changes to be committed
  3. run the command git add -u . to add file removals to the list of changes to be committed
  4. run the command git commit this will open a text editor to allow for a detailed commit message
  5. 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.
  1. Commit all outstanding changes in local customization repository!!! as per Step 4 - Any uncommitted changes will be lost, you've been warned!
  2. 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)
  3. Extract the contents of file downloaded in the previous step (not to your repository locations)
  4. Make the following changes to the files
    1. rename includes/config.php.new to includes/config.php
    2. (optional) if using a renamed admincp rename admincp to your chosen name
    3. (optional) if using a renamed modcp rename modcp to your chosen name
    4. delete the install folder (you'll may want to just move the folder somewhere else to facilitate running the install/upgrade script)
    5. (optional) on linux change the end of line characters of all files use the command:
      Code:
      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
  5. delete the contents of the repository from Step 1 (to deal with files that got removed in the new vBulletin version)
  6. copy the contents of the upload directory to location of the repository from step 1
  7. change your location to be the directory for the repository from Step 1 (e.g. cd /usr/src/vbulletin)
  8. run the command git add -u . this adds all removed files to the list of changes to be committed
  9. run the command git add . this adds all new/changed files to the list of files to be committed
  10. run the command git commit -m 'version' where version if the version number (e.g. 4.2.3)
  11. change your location to be the directory for the repository from Step 2 (e.g. cd /var/www/forum)
  12. 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
  13. run the command git fetch
  14. run the command git rebase origin/master
  15. if a conflict is found start the steps for git rebase conflict resolution
    1. merge the conflicting code
    2. run the command git rebase --continue
    3. if a conflict is found go to step 1 of git conflict resolution
  16. 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.
Reply With Quote
  #2  
Old 01-22-2016, 07:59 PM
TheLastSuperman's Avatar
TheLastSuperman TheLastSuperman is offline
Senior Member
 
Join Date: Sep 2008
Location: North Carolina
Posts: 5,844
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

Article approved! Nice one too squid, thanks for taking the time to outline this for everyone .
Reply With Quote
Благодарность от:
MarkFL
  #3  
Old 02-29-2016, 12:47 PM
ub.ch ub.ch is offline
 
Join Date: Jul 2010
Posts: 49
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

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!
Reply With Quote
  #4  
Old 02-29-2016, 02:39 PM
squidsk's Avatar
squidsk squidsk is offline
 
Join Date: Nov 2010
Posts: 969
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

Quote:
Originally Posted by ub.ch View Post
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:

[pre] vb repo
|
dev repo
|
live repo
[/pre]
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.
Reply With Quote
  #5  
Old 02-29-2016, 02:45 PM
ub.ch ub.ch is offline
 
Join Date: Jul 2010
Posts: 49
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

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:

PHP Code:
root@wheezy:/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 commitworking directory clean



root
@wheezy:/var/www/test.site/docs# git push
warningpush.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.0Git will default to the more conservative 'simple'
behaviorwhich 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 objects11497done.
Delta compression using up to 3 threads.
Compressing objects100% (8366/8366), done.
Writing objects100% (11158/11158), 442.61 MiB 14.21 MiB/sdone.
Total 11158 (delta 3073), reused 10446 (delta 2574)
remoteerrorrefusing to update checked out branchrefs/heads/master
remote
errorBy default, updating the current branch in a non-bare repository
remote
erroris deniedbecause it will make the index and work tree inconsistent
remote
errorwith what you pushed, and will require 'git reset --hard' to match
remote
errorthe work tree to HEAD.
remoteerror:
remoteerrorYou can set 'receive.denyCurrentBranch' configuration variable to
remote
error'ignore' or 'warn' in the remote repository to allow pushing into
remote
errorits current branchhoweverthis is not recommended unless you
remote
errorarranged to update its work tree to match what you pushed in some
remote
errorother way.
remoteerror:
remoteerrorTo squelch this message and still keep the default behaviourset
remote
error'receive.denyCurrentBranch' configuration variable to 'refuse'.
To /usr/src/vbulletin/.git
 
! [remote rejectedmaster -> master (branch is currently checked out)
errorfailed to push some refs to '/usr/src/vbulletin/.git' 
Reply With Quote
  #6  
Old 02-29-2016, 04:54 PM
squidsk's Avatar
squidsk squidsk is offline
 
Join Date: Nov 2010
Posts: 969
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

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.
Reply With Quote
  #7  
Old 02-29-2016, 05:03 PM
ub.ch ub.ch is offline
 
Join Date: Jul 2010
Posts: 49
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

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
Reply With Quote
  #8  
Old 03-02-2016, 02:32 PM
squidsk's Avatar
squidsk squidsk is offline
 
Join Date: Nov 2010
Posts: 969
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

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.
Reply With Quote
  #9  
Old 03-02-2016, 08:41 PM
ub.ch ub.ch is offline
 
Join Date: Jul 2010
Posts: 49
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

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!
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 05:39 AM.


Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.
X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.15962 seconds
  • Memory Usage 2,334KB
  • Queries Executed 24 (?)
More Information
Template Usage:
  • (1)SHOWTHREAD
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (1)ad_showthread_beforeqr
  • (3)bbcode_code
  • (1)bbcode_php
  • (1)bbcode_quote
  • (1)footer
  • (1)forumjump
  • (1)forumrules
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (1)modsystem_article
  • (1)navbar
  • (4)navbar_link
  • (120)option
  • (9)post_thanks_box
  • (4)post_thanks_box_bit
  • (9)post_thanks_button
  • (1)post_thanks_javascript
  • (1)post_thanks_navbar_search
  • (2)post_thanks_postbit
  • (9)post_thanks_postbit_info
  • (8)postbit
  • (9)postbit_onlinestatus
  • (9)postbit_wrapper
  • (1)spacer_close
  • (1)spacer_open
  • (1)tagbit_wrapper 

Phrase Groups Available:
  • global
  • inlinemod
  • postbit
  • posting
  • reputationlevel
  • showthread
Included Files:
  • ./showthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/functions_bigthree.php
  • ./includes/class_postbit.php
  • ./includes/class_bbcode.php
  • ./includes/functions_reputation.php
  • ./includes/functions_post_thanks.php 

Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_postinfo_query
  • fetch_postinfo
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • showthread_start
  • showthread_getinfo
  • forumjump
  • showthread_post_start
  • showthread_query_postids
  • showthread_query
  • bbcode_fetch_tags
  • bbcode_create
  • showthread_postbit_create
  • postbit_factory
  • postbit_display_start
  • post_thanks_function_post_thanks_off_start
  • post_thanks_function_post_thanks_off_end
  • post_thanks_function_fetch_thanks_start
  • fetch_musername
  • post_thanks_function_fetch_thanks_end
  • post_thanks_function_thanked_already_start
  • post_thanks_function_thanked_already_end
  • post_thanks_function_fetch_thanks_bit_start
  • post_thanks_function_show_thanks_date_start
  • post_thanks_function_show_thanks_date_end
  • post_thanks_function_fetch_thanks_bit_end
  • post_thanks_function_fetch_post_thanks_template_start
  • post_thanks_function_fetch_post_thanks_template_end
  • postbit_imicons
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • postbit_display_complete
  • post_thanks_function_can_thank_this_post_start
  • tag_fetchbit_complete
  • forumrules
  • navbits
  • navbits_complete
  • showthread_complete