Put Vbulletin Blog/cms On It's Own Sub-domain

Putting secondary vBulletin products on their own sub-domain (like we do here) turned out to be much simpler than I anticipated. Of course, I say that now after I spent countless hours working on methods that ultimately didn't work in the end for one reason or another.

For this method, you need to be running the Apache web server and have the ability to define mod_rewrite rules for it.

My example is specifically for vBulletin blogs, but the same idea could be applied to any vBulletin module (like CMS).

Create Blog Directory
Create a directory called blogs within your normal vBulletin installation directory (this should be at the same level where all the normal blog*.php files are at).

Create PHP files named the same as the normal PHP files that just include the actual ones.

These files really are nothing more than pointer files to tell Apache where the actual file is (this method is simpler than trying to create a ton of mod_rewrite rules to handle all the blog files.

Configure Apache
These are the rewrite rules I use for this site (keep in mind that the ServerAlias directive will only work in the Apache config file for your site, and will not work in an .htaccess file; also make sure your DNS is resolving the new sub-domain properly):

ServerAlias blogs.yourdomain.com
 
RewriteCond %{HTTP_HOST}        ^blogs.*
RewriteCond %{REQUEST_URI}      !^\/blogs\/.*
RewriteRule ^(.*)$              /blogs/$1 [L]
 
RewriteCond %{HTTP_HOST}        !^blogs.*
RewriteCond %{REQUEST_URI}      ^\/blog [OR]
RewriteCond %{REQUEST_URI}      ^\/entry\.php
RewriteRule ^(.*)$              http://blogs.yourdomain.com$1 [R=301,L]

Code (apache):

This will handle passing through a request to the blogs.yourdomain.com host to the proper blogs directory. It will also handle the redirection of old URLs to the new URL.

Create Plugin
Create a plugin at the global_complete location with the following line of code:

$output = preg_replace(array ('#(href|action)="blog.php#i', '#(href|action)="(blog_ajax|blog_attachment|blog_callback|blog_external|blog_inlinemod|blog_post|blog_report|blog_search|blog_subscription|blog_tag|blog_usercp|entry).php#i'), array('\1="http://blogs.yourdomain.com/', '\1="http://blogs.yourdomain.com/\2.php'), $output);

PHP:

All this does is alter the existing relative URLs to be absolute URLs.

Maybe someday vBulletin will have a Blog URL option to make this step not necessary.

Edit Blog JavaScript Files
Hopefully vBulletin will address this bug soon. If they do, this step will no longer be necessary.

In order to have the AJAX functions work, we need to edit the blog JavaScript files (these are the clientscript/blog* files).

blog_ajax_calendar.js
Change this:

asyncRequest("POST","blog_ajax.php

Code (javascript):

to this:

asyncRequest("POST",window.location.protocol+"//"+window.location.hostname+"/blog_ajax.php

Code (javascript):

blog_ajax_latest.js
Change this:

asyncRequest("POST","blog_ajax.php

Code (javascript):

to this:

asyncRequest("POST",window.location.protocol+"//"+window.location.hostname+"/blog_ajax.php

Code (javascript):

blog_ajax_rate.js
Change this:

asyncRequest("POST","blog.php

Code (javascript):

to this:

asyncRequest("POST",window.location.protocol+"//"+window.location.hostname+"/blog.php

Code (javascript):

blog_ajax_tagsugg.js
Change this:

asyncRequest("POST","blog_tag.php

Code (javascript):

to this:

asyncRequest("POST",window.location.protocol+"//"+window.location.hostname+"/blog_tag.php

Code (javascript):

blog_dragdrop.js
Change this:

asyncRequest("POST","blog_ajax.php

Code (javascript):

to this:

asyncRequest("POST",window.location.protocol+"//"+window.location.hostname+"/blog_ajax.php

Code (javascript):

blog_quick_edit.js
Change this (in two locations):

asyncRequest("POST",this.factory.ajaxtarget

Code (javascript):

to this:

asyncRequest("POST",window.location.protocol+"//"+window.location.hostname+"/"+this.factory.ajaxtarget

Code (javascript):

blog_quick_load.js

asyncRequest("POST",this.factory.ajaxtarget

Code (javascript):

to this:

asyncRequest("POST",window.location.protocol+"//"+window.location.hostname+"/"+this.factory.ajaxtarget

Code (javascript):

 

Check your server logs. Do you maybe not have it setup to allow mod_rewrite rules?

Make sure they are in the virtual site config file for Apache (the ServerAlias directive can't go in a .htaccess file if that's what you are trying to do).

 

Yep... just by looking at it (without actually trying it on a live server), it seems it should work.

 

All steps are required.

You need to set up the sub-domain in your DNS just like your main site URL. For example forums.digitalpoint.com, tools.digitalpoint.com, articles.digitalpoint.com, blogs.digitalpoint.com, etc. all resolve to 216.9.35.60

 

Hmmm... I didn't do anything special here. What settings do you have under AdminCP -> Settings -> Options -> Content Management ? Specifically, I would double check the CMS URL and Default Page.

It can be anywhere within the <VirtualHost> container in the .conf file. For example, this is how the first few lines look for this site:

<VirtualHost *:80>
	ServerAdmin admin@digitalpoint.com
	ServerName forums.digitalpoint.com
	ServerAlias articles.digitalpoint.com blogs.digitalpoint.com directory.digitalpoint.com marketplace.digitalpoint.com tools.digitalpoint.com

Code (markup):

Strange... do you have a URL I can see it at?

If you are getting logged out when you view sub-domains, you might need to check your cookie settings to work for all sub-domains, vs. just the specific one you logged in to. In your normal vB options, check the Cookie Domain setting. It should be set to ".yourdomain.com" from the drop-down list.

One thing you need to be aware of though is when you expand cookies to work on sub-domains, vBulletin does NOT remove the old sub-domain specific cookies when you log out. This can cause problems after people change their password if they were previously setup to stay logged in. For this site, I manually hacked the login.php file to remove ALL cookies (even the old ones) when someone hits the Logout button. That way if someone is having issues with staying logged in, you can just have them manually hit the Logout button and relogin and then they can properly stay loged in. It's a bit of a pain in the ass, but there's not a way to globally change user's existing cookies that were already set with the old setting.

For my login.php, after the define('NOPMPOPUP', true); line, I added this:

// Remove sub-domain specific cookies 
foreach ($_COOKIE as $key => $val) {
	if (substr($key, 0, 2) != '__') setcookie($key, '', $time - 3600);
}

PHP:

This will remove ALL cookies on logout EXCEPT Google Analytic ones (they start with __).

 

There really shouldn't be anything that needs to change in the admincp as far as I know. The admincp isn't on a different sub-domain, is it?