vBSEO overwrites some global vars -> user can't reply

Our problem as following:

Hosting control panel: ISPConfig, lastest and stable version 3.0.4.6
PHP: lastest and stable 5.3.14.
Nginx: latest and stable 1.2.1
vBulletin: lastest and stable 4.2.0 PL2
vBSEO: lastest and stable 3.6.0 gold.

Default: all websites are stored in /var/www, our domain.com doc root: /var/www/domain.com/web (real path: /var/www/clients/client2/web2/web), vBSEO and vBulletin works fine, relpath is correct, eg: relpath = showthread.php in headinclude, $_SERVER['SCRIPT_FILENAME']=/var/www/domain.com/web/showthread.php.

But our diskspace is full so we move 'www' to /home/data/www then link /var/www to /home/data/www, vBSEO change vBulletin's relpath = /web2/web/showthread.php in headinclude, $_SERVER['SCRIPT_FILENAME']=/home/data/www/clients/client2/web2/web/showthread.php which redirects user to domain.com/web2/web/forum-name/1234-thread-title.html instead of domain.com/forum-name/1234-thread-title.html each quick reply then can't do reply with quotes, can't quote, can't edit post (using ajax),...

We tried to set 'Custom Doc Root' to '/var/www/domain.com/web' and 'Define vBSEO Custom Relative Doc Root' to '/' or leave it empty but didn't fix the problem.

We also tried to view php info via a test.php which just call phpinfo(), it shows that $_SERVER['SCRIPT_FILENAME'] still /var/www/domain.com/web/test.php instead of /home/data/ww..........

To fix the problem, we have to move 'www' back to /var instead of linking it. we don't complain about vBSEO overwrites SCRIPT_FILENAME, it's not a wrong decision but somehow, it affect to vBulletin's relpath.

So, please fix this glitch or advise, we must move 'www' to a new location which has more room to grow.

Thank you.

Hello ,

You can define correct path from vBulletin config.php and vBSEO Cp > General Setting > vBSEO Settings > Advanced Settings > Custom Doc Root

It works, thanks a lot!

Originally Posted by cdonger

It works, thanks a lot!

I'm sorry, the problem gets back after restart the web server. It works because of cached file info still available, not the settings fix the issue. Anything else should we try?