Account Constructor delegate behaves unexpectedly

emiller

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: http://wso.williams.edu/facebook/view?unix=".$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?

Thanks!

Mark

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.

ithcy

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.

Mark

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') {

emiller

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.

emiller

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?

Mark

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.

emiller

Thanks, Mark. I think I'll just avoid mod_rewrite for now.