302 issues - non vbseo

I have Vbadvanced Dynamics installed. All of us using it are having 302 errors, as discussed here in previous threads. This is due to the way the internal SEF urls are being created/fetched.

I was wondering if it would be possible for someone knowledgable with VBseo and how they do things, to look this over and see if we can get it worked out.

There are folks working on this over there already, and Brian, the coder, is as well, but things are moving slow. I have tried myself but apparently do not know enough to get it fixed.

There are multiple spots in 2 files that handle rewriting of the SEF urls. I have narrowed the funciton that causes the 302 errors down. If the below snippets are removed, validator.w3.org will return the page without the 302 error.

We however, then lose the functionality to forward people to the proper urls if the entry/category title changes. Without these snippets, you could type ... /anything-8/ and get categoryid 8, or /anything-1234/ and get entryid 1234.

Both would then have any given text before the ID numbers, and if abused, could kill you with duplicate content.

Even if you can't fully fix the error due to not having full access to all the files, if you have any insight as to what kind of function is causing this, or any direction as to where to start trouble shooting, what things need to be rewritten, etc, that would be great.

I understand this is not directly related to VBseo and if in the wrong forum or inappropriate to post here, I apologize in advance. Just figuring folks who are familiar with doing this so well for default VB could help out getting this resolved. A lot of my main content outside of the forum is in Dynamics, and a full VBSeo integration doesn't look possible.

I can provide full files privately to anyone who wants to look it over, or set up a test installation and FTP for someone to play around with.

A donation via Paypal would be available as well if desired.

For Categories

Code:

// Make sure the URL matches up
if ($vba_options['dyna_spiderurls'] AND $vbulletin->GPC['catrewrite'])
{
    $caturl = fetch_cat_url($rewritecatid);

    if ($caturl != $vbulletin->GPC['catrewrite'] AND $caturl != $vbulletin->GPC['catrewrite'] . '/')
    {
        exec_header_redirect($vba_options['dyna_homeurl']  . '/' .  $caturl);
    }
}

For full entry pages
(if bolded part is commented out, it returns without 302 errors)

Code:

    if (!defined('SF_ERROR'))
    {
        // Get the entry info
        $vba_dyna->load_entry('', true, true, true, true, true);
        $entry =& $vba_dyna->_entry;

        // Redirect them if the URL doesn't match up
        if ($vba_options['dyna_spiderurls'] AND $vbulletin->GPC['entryrewrite'] AND $entry['url'] != $vbulletin->GPC['catrewrite'] . '/' . $vbulletin->GPC['entryrewrite'] . '/')
        {
            exec_header_redirect($vba_options['dyna_homeurl']  . '/' .  $entry['url']);
        }
        else if ($vba_options['dyna_spiderurls'] AND !$vbulletin->GPC['entryrewrite'])
        {
            exec_header_redirect($vba_options['dyna_homeurl']  . '/' .  $entry['url']);
        }

        unset($query);

        if (!$catid)
        {
            $catid = $entry['catid'];
        }

        $entryuserid = $entry['userid'];
    }

A redirect without a header saying otherwise returns a 302, moved temp. It's the default action basically.


The fix probbaly lies in the exec_header_redirect() function.

I'd probably customize it to take a new field

exec_header_redirect($vba_options['dyna_homeurl'] . '/' . $entry['url'], '301');

and then edit the function to take the new pass, and default to = "".

function exec_header_redirect($path,$header = "") {}
{
if ($header) {
//add $header
}
//do what it does now
}


something like that

Thanks briansol, appreciate the quick input.

I believe exec_header_redirect is a vbulletin default function that Dynamics is using. It is in the vbulletin /includes/functions.php file. Didn't see it mentioned anywhere else in the Dynamics files.

Maybe create exec_header_redirect2, and use that just for Dynamics calls? Key is, how to apply what you put above into a new call, using the default one listed below as a starting point.

Code:

// #############################################################################
/**
* Halts execution and redirects to the specified URL invisibly
*
* @param    string    Destination URL
*/
function exec_header_redirect($url)
{
    global $vbulletin;

    $url = create_full_url($url);

    if (class_exists('vBulletinHook'))
    {
        // this can be called when we don't have the hook class
        ($hook = vBulletinHook::fetch_hook('header_redirect')) ? eval($hook) : false;
    }

    $url = str_replace('&', '&', $url); // prevent possible oddity

    if (strpos($url, "\r\n") !== false)
    {
        trigger_error("Header may not contain more than a single header, new line detected.", E_USER_ERROR);
    }

    header("Location: $url", 0, 302);

    if ($vbulletin->options['addheaders'] AND (SAPI_NAME == 'cgi' OR SAPI_NAME == 'cgi-fcgi'))
    {
        // see #24779
        header('Status: 302 Found');
    }

    define('NOPMPOPUP', 1);
    if (defined('NOSHUTDOWNFUNC'))
    {
        exec_shut_down();
    }
    exit;
}

Heh, that makes it almost too easy.

just make a new function somewhere...

Code:

function exec_header_301redirect($url)
{
    global $vbulletin;

    $url = create_full_url($url);

    if (class_exists('vBulletinHook'))
    {
        // this can be called when we don't have the hook class
        ($hook = vBulletinHook::fetch_hook('header_redirect')) ? eval($hook) : false;
    }

    $url = str_replace('&', '&', $url); // prevent possible oddity

    if (strpos($url, "\r\n") !== false)
    {
        trigger_error("Header may not contain more than a single header, new line detected.", E_USER_ERROR);
    }

    header("Location: $url", 0, 301);

    if ($vbulletin->options['addheaders'] AND (SAPI_NAME == 'cgi' OR SAPI_NAME == 'cgi-fcgi'))
    {
        // see #24779
        header('Status: 301 Found');
    }

    define('NOPMPOPUP', 1);
    if (defined('NOSHUTDOWNFUNC'))
    {
        exec_shut_down();
    }
    exit;
}

and call this one instead of the other one.

Well, that did do the trick with changing them to 301 for sure. So thanks for that.

Problem is, we still get redirect loop errors on validator.w3.org, which I'm assuming Google et al doesn't like it either.

Plus, these shouldn't be returning 301 or 302 at all unless there is a mistyped URL. Should be 200 OK, and if you mistype the title of the cat or entry, or use the non SEF URL, then you get the 301/2. Correct?

See these for examples:

Category:
Validation Results - W3C Markup Validator

Full Entry:
Validation Results - W3C Markup Validator

If you remove the 2 above quoted pieces of code, then the 302 errors stop. But you lose the ability to redirect to the proper url if someone types in a different category/thread title with the right category/thread ID.

Without those snippets, you can type

site-updates-18/
any-text-18/
broken-links-18/

have-your-transformers-collection-featured-on-tfw2005-165606/
any-text-165606

etc, and get to the same page.

Im assuming that its sending it through the exec_header_301redirect function multiple times.

I am attaching the entire SEF include file here in case it helps. It seems to be referencing url construction functions from the main Dynamics function file, then using those to create a master $caturl or $entryurl variable, which is what it needs to 301 to. Problem is it's getting caught in a loop somewhere.

Also of note, the category based call, is done for everything, on all pages, and then the entry based call is only for entry pages, yet creation of that SEF URL includes the cat rewrite construction. So it's doubling up there. I know commenting out the category call returns the proper location on entry pages, but we still have 302/1 loop errors.

Just pointing that out in case it helps in deciphering whats going on.

Just an update - Another user on the Dynamics forum got this worked out.

The session was being applied to the URLS, and when the system was matching the inputted URL with the Proper url, and then deciding if it needed a redirect, it was always "wrong", so it went into an infinate loop of 301/302 redirects.

The fix is available now there:

302 Errors - vBadvanced Forums

briansol, I appreciate your help, the the 301 code change fix is an additional issue now resolved thanks to your help. Ive posted it over there.