Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Account Constructor delegate behaves unexpectedly

edited April 2006 in Vanilla 1.0 Help
I recently upgraded from rev. 225 to rev. 300. One of my homebrew extensions broke, and I cannot figure out exactly why. Here's the contents of it:

if (is_numeric($Context->SelfUrl)) { # Is it an account? function Redirect_External(&$Account) { header("location:".$Account->User->Name); } $Context->AddToDelegate("Account", "Constructor", "Redirect_External"); } ?>

Before, it would redirect to the external page of the user being viewed. Now, it redirects to the external page of the person who is logged in. Any ideas why the Account Constructor delegate is being called for the logged-in user with the new version?



  • MarkMark Vanilla Staff
    edited April 2006
    That is certainly very odd. Nothing in that control (or the page underneath where the user is defined) has changed in many, many revisions.

    If I were you I'd try some local debugging. I'd go into account.php and check to see that the account control itself is getting the correct user.

    account.php lines 83-85:

    echo '<div>Username before entering control: '.$AccountUser->Name.'</div>'; // Create the account profile $AccountProfile = $Context->ObjectFactory->CreateControl($Context, "Account", $AccountUser);

    I'd run that and then see what name comes up.

    I'd do the same right before the constructor delegate is called in the control.

    I'd do the same within your delegate function, followed by a die();

    Basically I'd try to narrow down where it is screwing up and assigning the wrong user.
  • if (is_numeric($Context->SelfUrl))

    that's not going to work, is it?
    $Context->SelfUrl is going to be something like "account.php". it'll never be numeric.
  • MarkMark Vanilla Staff
    edited April 2006
    ithcy is right, but that's another issue. It obviously works in some wacky way. A better way to do it (I'd say) is like:

    if ($Context->SelfUrl == 'account.php') {
  • Yeah, I had it as

    if ($Context->SelfUrl == 'account.php') {

    previously, but for some reason it wasn't working when I did the upgrade. Some testing showed that $Context->SelfUrl was evaluating to the UserID of the user being displayed, which makes zero sense to me, but that's what it was. Testing for numericality didn't seem to break anything else, so that became my test.

    Thanks for the tips, Mark, I'll try them out.
  • I'm guessing this is something screwy with rewrites. There are at least two issues here. First, when I request /account/34/, SelfUrl takes "34" to be the action, and it fails to take "34" to be the value of the "u" parameter, even though this is clearly in .htaccess: RewriteRule ^account/([0-9]+)/$ account.php?u=$1 [QSA,L] Any ideas?
  • MarkMark Vanilla Staff
    It sounds like a mod_rewrite issue, and it explains the first bug - where it was redirecting to the user viewing the page instead of the requested user (when the page doesn't find a valid UserID to look up, it takes the current user).

    That rewrite rule looks good to me. Not really sure why it's not working. But it took me two weeks just to get mod_rewrite to work in the first place. Mod_rewrite is a finnicky module, that is for sure.
  • Thanks, Mark. I think I'll just avoid mod_rewrite for now.
This discussion has been closed.