Bug DBSEO Custom 404 Error Processor Not Working

[bzcomputers]

for me:

/home/xxxx/public_html/error/404.php

 

[Fillip H.]

Relative to the directory the dbseo.php file is in I believe, or you can use the absolute path to be safe

 

[neounix]

Hey!

We just installed DBSEO on our main forums; and this line in our apache2 conf file worked perfectly:

ErrorDocument 404 /search.php

However, now that we have DBSEO installed, it does not work at all.

No matter how we set up the DBSEO config, it always tries give error:

Invalid Forum specified. If you followed a valid link, please notify the administrator

You can see here:

http://www.unix.com/blah_blah_blah.php

 

[Fillip H.]

Can you not use the Custom 404 Script and add the path, like on the staging server?

 

[Fillip H.]

Update: According to this: apache - PHP - Header 404 not triggering htaccess ErrorDocument - Stack Overflow it's impossible for PHP to trigger the ErrorDocument directive.

You will need to have DBSEO include the search.php file as the Custom "404 Not Found" Handler in order for it to work as you need it to.

 

[neounix]

Well, first of all, our ErrorDocument directive has been working way over a year, so I know it works fine.

Second of all, as I mentioned, nothing works in DBSEO, regardless of how we configured it.

We never solved this problem on the staging server because we did not need the 404 directive there.

I am 1000% sure our ErrorDocument directive worked, regardless of what someone else posted on the net somewhere.

As far as DBSEO, nothing works.. you can see it is configured as you mention and it does not work.



All these 404 tests come back as:

Invalid Forum specified. If you followed a valid link, please notify the administrator

This can only mean that DBSEO is not managing it properly, because it is adding a "/" at the end of each query and forcing the error.

If I turn DBSEO off, our custom 404 works fine, but we cannot turn it off now because the site is busy and in production

 

[neounix]

For example, we try:

/ssssssss.php

and DBSEO returns:

/ssssssss.php/

...it's obviously not working!

 

[neounix]

We cannot turn off DBSEO now... GoogleBot is indexing at the rate of around 3100 pages per hour.

GoogleBot Thread Index Count: 3115 - 2% of sitemap - Last 7 Days: 2% - Last 24 Hours: 2% - Last Hour: 2% (3116)

 

[Fillip H.]

Well, first of all, our ErrorDocument directive has been working way over a year, so I know it works fine.

I am 1000% sure our ErrorDocument directive worked, regardless of what someone else posted on the net somewhere.

I'm not sure how that's relevant to generating 404 errors with PHP? Have you tried to trigger your ErrorDocument directive in PHP before?

As far as DBSEO, nothing works.. you can see it is configured as you mention and it does not work.

Can you try creating a 404.php with the following content:

<?php
header('HTTP/1.1 404 Not Found');
header('Status: 404 Not Found');
include('/var/www/search.php');
?>

And set /var/www/404.php as the custom error handler in DBSEO and let me know if that works for you?

 

[neounix]

Yes, of course.

We worked with our 404 ErrorDocument directive and tested it many, many times.

Dude! We are a well established site with years of expertise. It worked perfectly fine before installing DBSEO.

That's the story man.

Please fix DBSEO and please, please stop trying to tell me our server has a problem before DBSEO was installed on this matter.

It was working perfectly before installing DBSEO. SURE!

 

[neounix]

OK.. I did your test and it proves that your settings do not work:

Here is the test page:

www.unix.com/test.php

Here is the code:

root@www:/var/www# cat test.php
<?php
header('HTTP/1.1 404 Not Found');
header('Status: 404 Not Found');
include('/var/www/search.php');
?>

If you call this directly it works fine (as it did before with all 404 errors with our ErrorDocument directive).

Then we configure DBSEO the same.. and it gives the same error I said on all 404 pages.

 

[neounix]

It's really obvious DBSEO is the problem.

DBSEO rewrites the 404'ed URL and puts a '/' a the end... this is the problem... and the custom 404 DBSEO config does not work.

 

[neounix]

Also, to further my discussion that our ErrorDocument directive worked before installing DBSEO; below I attach a discussion (image of) when one of our moderators talks about 404 error redirecting him to the search page after we removed DBSEO and were testing all the 301s.

You can see that our ErrorDocument directive was working fine and directing 404 errors to our search page.



I would very much appreciate it if we could get DBSEO working as it should, because our ErrorDocument directive was working fine up until the time we installed DBSEO today.

 

[Fillip H.]

I don't think I've been very clear, sorry: I'm not saying that DBSEO is correct in displaying "invalid forum specified".

I'm saying that if you don't use the Custom 404 Handler option, the ErrorDocument directive in Apache will not be triggered by a php-generated 404 Not Found header.

The reason why the ErrorDocument directive is triggered without DBSEO is because without DBSEO, all requests are served directly. With DBSEO active, all requests are routed via dbseo.php - this file exists, and thus there's no 404 error.

Hopefully I have made the difference clear enough now


I also need your help identifying a plugin that's causing the following DB error:

select * from style where styleid =  or styleid = 38 ORDER BY styleid ASC;

This error is a result of DBSEO needing to global a specific variable inside the handle404 function, but I need you to tell me what variable is supposed to be in that query.

 

[Fillip H.]

Update: Nevermind, I decided to work around this by finding an alternate method of handling 404 that doesn't require globalling everything under the sun.

On the staging server I'm now getting "Cannot access directly" when I attempt to use search.php as the 404 handler. Can you shed any light on this?

 

[neounix]

Yes, the staging server is not set up for managing 404 errors, as I mentioned before; I would need to test and configure it to get it working for you.

Regarding the production server, I just went into your code and found a function:

public static function handle404($uri = '', $force404 = false)

Then, I added this quick logging code to that function, right at the beginning:

 $_DEBUG = TRUE;
               if($_DEBUG  OR 1==1)
  {
      $log = '/website/logs/apache2/dbseo_404_debug.log';
      error_log(date(DATE_RFC822).' Force 404: '.$force404.' URI: '.$_SERVER['SCRIPT_URI'].' DBSEO_URI: '.$uri."\n\n", 3, $log);
   }

so, i expect to see a log entry during each 404.....

Then, I created a bunch of 404 errors using bogus URLs... and there were no entries in the log file for any of the 404 errors; and there are no PHP errors, so one view could be that DBSEO is having trouble managing 404 errors; because even when I trigger a 404 directly with a bad URL, the function above is not called.

Cheers.

 

[Fillip H.]

I configured DBSEO on the staging server to directly call search.php. No web server configuration should be needed.

If web server configuration was needed, then this should not correctly return a 404: Page Not Found - DragonByte Tech | vBulletin Mods & Addons - as we have not done anything extra with our web server

 

[Fillip H.]

Update: I made further refinements to the 404 handling on the staging server and it's now displaying the search page correctly when "404 File Not Found" Handling is set to Run Custom Script and Custom "404 File Not Found" Handler is set to search.php

 

[neounix]

Thanks! So we just need to test when I am back at my desk and update the one core class include file where the force404 function lives ?

 

[Fillip H.]

The main dbseo.php file and the class_core.php file have been updated for this issue.