Archive rewrites with php as cgi

Big frustrations

I am incredibly frustrated at the lack of vbSEO support. With the zend encoding of vbSEO it is not possible to bug fix it and I have had to spend many hours doing workarounds. I had to spend hours the moment before going on holiday. You promised to fix the problem while I was away and I gave you direct access to my site. However, the problem was not fixed now 12 days later, and you refuse to chat with me to sort out the issues - your excuse being that unnamed issues are being fixed in RC5.

Unnamed issues, since you refuse to let me chat with you.

Therefore, the issues are now being made public on this forum!

I have seen a number of discussions regarding objections to your zend etc encoding of the files. Until now I have been in support of your stand with the belief that bug fixes on live sites would be prompt. However, weeks go by without fixes and this is unacceptable on live heavily trafficed sites. Even more so when I have been able to find workaround fixes (taking hours) when you should have been able to find the workarounds and supply them within a much shorter timespan.

I am not an expert on htaccess, yet I have been able to find htaccess workarounds.

Archive rewrites

Regarding the archive - on one of my vBulletin installations, I have RC4 successfully installed with the host being Apache / PHP as module.

However, with my vBulletin installation with Apache / PHP as CGI, the archive links get rewritten as

HTML Code:

http://forum.time2dine.co.nz/archive/index.php/index.php?f-9.html

ie there is a double index.php

The query string exists because the vBulletin archive/index.php file senses the PHP as CGI and so uses the query string. I have tried using the standard /index.php/f-9.html and found it does not work - probably due to the PHP as CGI compatability.

Your rewrite should check for php as cgi module, and rewrite the /index.php?f-9.html as /index.php/f-9.html, then send /index.php?f-9.html to the vBulletin files for processing. Of course, this then has to be incorporated into your archive rewriting that allows for rewriting of /archive/index.php/f-9.html to /archive/f-9.html.

Checking of cgi as a module is possible via the vBulletin method of checking per /archive/global.php:

PHP Code:

 if ((substr(PHP_OS, 0, 3) == 'WIN' AND strpos($_SERVER['SERVER_SOFTWARE'], 'apache') === false) OR (strpos(SAPI_NAME, 'cgi') !== false AND @!ini_get('cgi.fix_pathinfo'))) 


Workaround

My htaccess workaround that you should have come up with has been to redirect the

HTML Code:

http://forum.time2dine.co.nz/archive/index.php/index.php?f-9.html

to the correct url being

HTML Code:

http://forum.time2dine.co.nz/archive/index.php/f-9.html

then further send the query based url to the archive/index.php file.

HTML Code:

#correct archive
RewriteCond %{QUERY_STRING} ^(.+)$
RewriteRule ^archive/index.php/index.php$ http://forum.time2dine.co.nz/archive/index.php/%1? [R=301,L]

RewriteRule ^archive/index.php/f-(.+)\.html$ archive/index.php?f-$1.html

Please do the required fixes for your RC5 and improve your level of support!!!

Hi Michael,

Thank-you for posting your concerns regarding vBSEO support. I am very happy to have such a great team of vBSEO testers in place who continue to provide us with valuable feedback as we continue to advance and prepare vBSEO for official release.

During the last two weeks, we have been extremely busy preparing RC5 for release with multiple new features and fixes for many of the bugs that were reported by our testers. We also made some major revisions to the vBSEO pre-processing engine that created the possibility for some exciting new features in the future, along with further performance gain.

Rest assured that we are actively monitoring the forums, and we will make as much time available for one-on-one troubleshooting as possible. Note: All bug reports will be dealt with in a prioritized manner.

Since most forums have a variety of mods installed, we are not working with a controlled environment. As a result, we have to carefully verify and test each new bug fix and/or new feature to ensure that it will work correctly for all of our users. This includes regression testing to ensure that our fix/feature did not breaking anything else! It's a difficult and time consuming process, but completely necessary.

Our testing team is helping us to bulletproof vBSEO. RC5 is extremely stable now, and upon official release we are committed to responding to support requests in as expedient a manner as possible.

Re: Archive Rewrites

In RC5 the archive will work correctly when running PHP as CGI. After installing RC5, you may remove your temporary workaround.

/* FYI We are also looking into adding a vBSEO extensions module that will allow users with PHP experience to make changes to vBSEO's process. */

Juan

Thanks for your response. I understand your position, but I find it hard to understand the time it takes you when I am able to find fixes myself or suggest fixes to your code that would sort out the immediate concerns.

I am not an expert in htaccess, yet with help from other friends, I was able to find a workaround. With access to the source code I would have been able to make an even quicker PROPER adjustment. Or you could have provided a temporary code fix. Or with your help, given that you are far more able in htaccess than I, you could have provided the htaccess workaround.

I have no problems with features being made available in new versions, but bug fixes that are a matter of life or death to forums should have the utmost priority.

I have been unable to have a proper Google site map for weeks now, because you have not continued the support for my Google site map program that you did the vbSEO coding for. Such a thing should be hours if not days.

In RC5 we have streamlined the internal vBSEO versioning structure to increase efficiency of development and testing for future iterations. You will likely notice an increase in our implementation, testing, and release time from version RC5 onwards, depending (of course) on the quanity and complexity of bug fixes and features that are included in each new release.

We encourage users to identify temporary solutions to issues that they detect. In fact, our tentatively planned feature for an "extensions module" should help to make this even easier in the future.

Our goal with this extensive user testing it to bulletproof vBSEO prior to its official release.

I have been unable to have a proper Google site map for weeks now, because you have not continued the support for my Google site map program that you did the vbSEO coding for. Such a thing should be hours if not days.

We have to first complete our release before reviewing your Google Site Map to ensure that it is compatible. By the time we release vBSEO officially, your Google Site Map will the first vB hack that is vBSEO-compliant! If no major issues arise with RC5, we will try to have your GSM compliant in 24-72 hours.

Juan

Thanks for your reply. Appreciated.