I am using AuthPlugin to authenticate against an external database. The first time a user logs in, without exception they see this error: Fatal error: Call to a member function on a non-object in /home/myaccountname/public_html/mediawiki-1.4.2/includes/SpecialUserlogin.ph p on line 266 If the user then navigates back to the login page and attempts to log in again, it succeeds as if nothing happened, and never fails again. This only happens on the initial login attempt. You can reproduce this by registering with my message board - www.takimedia.com/boards - and then trying to log into the wiki at - www.takimedia.com/wiki (Please ignore the content, right now this wiki is being tested by my friends, who are just a bunch of alcoholic vandals). I tried looking through the code, but due to the abundance of global variables I had a hard time figuring out what is going on. I am suspicous of the autocreate function, though. Any help would be greatly appreciated. Thanks, Carlton

Actually I didn't override this method at all. However, looking at the code, that is precisely the problem. SpecialUserlogin.php requires initUser() to return a reference to the user object. The base class initUser() method in AuthPlugin doesn't return anything at all. Thus, if the initUser() method is not overriden in the implementation, then it effectively user object to null. The code contains the very vague comment "override this to do something", and now the meaning is clear. We must, at a minimum, return the reference that we were passed: function initUser(&$u) { return $u; } So now it occurs to me that $wgAuth->initUser() is probably where you set the email address and other optional fields, is that right? And what other user attributes is it meaningful, or even safe, to set? My plugin has a method of determining whether the external account is in a "banned" state, so I would love to be able to use this information in MW. I think the documentation could be a bit clearer on this issue. Also I think the initUser() method in the base AuthPlugin class should be modified to return the user object, because we know there is at least one case where important code will break if it doesn't. Thanks for your help... Carlton

Well, in this case I guess we've just got different things going on, because I didn't override AuthPlugin::initUser and I didn't modify LoginForm::initUser or tamper with SpecialUserlogin.php in any way. The only way I could get AuthPlugin to do an autocreate without throwing the fatal error was by overriding AuthPlugin::initUser to return the reference to the user it was passed. I wonder if your reproduction was accurate, because this is a tricky bug - even though it does throw a fatal error, the new user account indeed does get created, and the problem will not repeat itself as long as the user exists in the MW database. I have gone back through your code explanation and I can't find any fault with it. The only remaining possibilities I can think of are: 1) Some method of the User class is setting the object to null in LoginForm::initUser 2) PHP is getting its namespace confused and calling LoginForm::initUser instead of AuthPlugin::initUser on line 254 of SpecialUserLogin.php. Perhaps it's my version of PHP. I am on php 4.3.11. Frankly I do not trust PHP 4's OO strategy to correctly handle any remote similarities in the namespace, so maybe renaming the AuthPlugin::initUser interface to something else show this to be the case. Is this interface widely referenced elsewhere, can I safely rename it on line 254 of SpecialUserLogin.php and then change it to the same in my AuthUser extension? Thanks.. -Carlton

To confirm this, I unpacked the 1.4.2 tar file in a completely separate subdirectory and added back in only my AuthPlugin extension, LocalSettings.php file, and a graphics file. The pristine version continued to yield the error. A recursive diff showed that the non-erroring version's copy of SpecialUserlogin.php contained a seemingly trivial debugging edit. After doing some more focused testing on a good night's sleep, in versions 1.4.2 and 1.4.3, I can say that I was incorrect and you were correct in saying the return value from AuthPlugin::initUser's subclass was related to this problem. Now, before you toss your hat in the air and say "Aha!", let me tell say that what I did find is troubling. This is the change: Below line 254 of SpecialUserlogin.php, I had added the following line which became line 255. $rather_unique_varname_bznksjx = $u; // fairly certain this var name won't conflict with anything else. There is no other difference in the file, and of course I never used the rather variable anywhere else. I can reproduce the problem at will by adding and removing this single line. I can't give a good technical explanation of why I did it or why it makes AuthPlugin work for me. All I know is that I am highly, highly suspicious of PHP 4's scoping and references. When I noticed the variable $u used both explicitly and as a reference all throughout SpecialUserlogin.php, I suspected PHP might have mishandled transitioning between scopes. Thus I thought it would be healthy or at least harmless to explicitly reference the $u variable at least once in LoginForm::processLogin. According to what I know of PHP internals (not much at this point), this change should have had no effect. But it did, and it worries me not to know why. I am not sure how to determine this, but my host's feature page says we are using the Zend optimizer, and phpinfo() shows this information: This program makes use of the Zend Scripting Language Engine: Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St. Petersburg, by Dmitry Stogov with Zend Extension Manager v1.0.6, Copyright (c) 2003-2004, by Zend Technologies with Zend Optimizer v2.5.7, Copyright (c) 1998-2004, by Zend Technologies line 254 of I tested this and it had no effect. The difference was explicitly referencing the $u variable right after line 254 of SpecialUserlogin.php. This would be a hard nut to crack except maybe for somebody who really knows PHP internals. I've already put too many hours into this problem, so I'm not putting any more time into it, and I wouldn't expect anyone else to either. Maybe we'll just pick up from this point if somebody else runs into the same thing. -Carlton