Bug New Post url redirect not being rewritten

Status
Not open for further replies.
Could you please create and PM me with a temporary FTP and AdminCP account?

For security reasons, we recommend you create a new FTP account only for DBTech support, then disable or delete it after we have both confirmed the issue has been solved and there are no further issues.

The same applies to AdminCP accounts; they should ideally be temporary accounts created for us only. If we have created an account on your site already, you can optionally boost that account to Administrator and then de-admin this account once the issue has been solved.

If you use a .htaccess password protection for your AdminCP directory, it is recommended that you create a new authorised user for DBTech and remove this user once the issue has been solved.

Please test any temporary accounts you create to ensure that the FTP account has access to the forum files, and that the AdminCP account can access the administrative controls for the product we are assisting you with.

Ensuring this is all in order before submitting the information will significantly speed up the process of assisting you. We will alert you via PM if there's any issues with the login information you have provided.

When sending the PM, for your security you should also un-tick the "Save a copy in my Sent Items folder" checkbox. When the access details have been received, we will delete the PM from our inbox. Ensuring you have not kept a copy of the PM reduces the risk of security breaches.

Thank you for helping us debug our products and allowing us to assist you, we appreciate it :D
 
Update: Is your server not running Apache? There is no .htaccess file, and the file I attempted to add is not picked up by the server.

The problem is that requests are not routed through dbseo.php as they should be. Therefore, DBSEO has no way of redirecting to the SEO'd URL.
 
Rewritten URLs are hitting dbseo.php, but default vBulletin URLs are not.

You can test this by creating a new PHP file test.php inside your forum folder:
PHP:
<?php echo "<pre>"; debug_print_backtrace(); ?>
then access test.php in your browser.

If DBSEO is taking over the request, as it should, you will see this:
Code:
#0  require() called at [/path/to/your/forum/dbseo.php:458]

I tested this with showthread.php on your site, and the output was blank, meaning there is an error in your nginx configuration which you need to rectify.
 
I've been doing my own tracing and was surprised when dbseo does not hook friendlyurl_resolve_class to modify the url.

Looks like showthread.php calls
Code:
exec_header_redirect(fetch_seo_url(
and that slaps us straight into the new post via showthread.php instead of dbseo.

Nginx config is fine, was able to print the stacktrace different
PHP:
$e = new Exception();
print_r(str_replace('/path/to/code/', '', $e->getTraceAsString()));


shows as
Code:
{0} main;
{/code]

How hard would it be to write a hook for friendlyurl_resolve_class?
 
Ended up augmenting my current nginx rules


This worked well for the most part.
Code:
	location /
	{
		try_files $uri $uri/ /dbseo.php;
	}

Needed to add
Code:
	location ~ ^((?!dbseo).)*\.php$
	{
		rewrite ^/(.*)$ /dbseo.php last;
	}

This is better then most of the rewrites I have seen using nasty if's which are evil
 
If you would be able to provide us with a set of Nginx rules that do not use "if", and the ruleset passed some testing by other customers or the SEOvB group, we could supply it with the product and help customers like yourself who are running nginx :)

Here is the closest thing we have seen to a working Nginx ruleset:
Code:
location / {

	try_files $uri $uri/ /dbseo.php?$args;

	if (-f $request_filename) {
		expires 30d;
		break;
	}

	if ($request_filename ~ "\.php$" ) {
		rewrite ^(/.*)$ /dbseo.php last;
	}

	if (!-e $request_filename) {
		rewrite ^/(.*)$ /dbseo.php last;
	}
}

location ~ /(.*\.php)$ {
	rewrite ^/(.*)$ /dbseo.php last;
}
 
Code:
	location ~* \.(png|jpg|jpeg|gif|ico)$ 
	{
		expires 30d;
		log_not_found off;
	}
	location /
	{
		try_files $uri $uri/ /dbseo.php;
	}

	location ~ ^((?!dbseo).)*\.php$
	{
		rewrite ^/(.*)$ /dbseo.php last;
	}
	
	location ~* \.(php)$
	{
		fastcgi_index index.php;
		fastcgi_pass unix:/var/run/php5-fpm.sock;
		include /etc/nginx/fastcgi_params;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;
		fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;
	}
Heres the relavent bits from my config.


Code:
	if (!-e $request_filename) {
		rewrite ^/(.*)$ /dbseo.php last;
	}
is not needed as that is the entire point of try_files :p
 
Just a quick update on this:
Code:
	location ~ ^((?!dbseo).)*\.php$
	{
		rewrite ^/(.*)$ /dbseo.php last;
	}
will technically no longer be needed as of v1.1.2. It will still be good to have, for performance reasons, but the product will work without it.

We actually encountered the same issue on this forum today, because of some server software changes*. These changes resulted in .htaccess files no longer being read when accessing non-rewritten URLs (e.g. showthread.php?t=15544), which subsequently caused the Canonical URL enforcement to never trigger.

This was resolved by checking whether DBSEO had ran prior to the vBulletin environment initialising, and setting required variables if not. Additionally, general Canonical URL enforcement will now be applied at the earliest possible time to save on performance.


* Apache 2.4 with PHP-FPM using mod_proxy_fcgi
 
Status
Not open for further replies.

Legacy DragonByte SEO

vBulletin 3.8.x vBulletin 4.x.x
Seller
DragonByte Technologies
Release date
Last update
Total downloads
7,191
Customer rating
5.00 star(s) 1 ratings
Back
Top