I've googeld and grepped, but no luck. I want to set the default options for new users. In particular I want new users to have "Add pages you edit to your watchlist" set by default.
How would I do this?
Thanks.
--Ben
Benjamin FrantzDale wrote:
I've googeld and grepped, but no luck. I want to set the default options for new users. In particular I want new users to have "Add pages you edit to your watchlist" set by default.
How would I do this?
# Settings added to this array will override the language globals for # the user preferences used by anonymous visitors and newly created # accounts. (See names and sample values in languages/Language.php) # # For instance, to disable section editing links: # $wgDefaultUserOptions['editsection'] = 0; # $wgDefaultUserOptions = array();
-- brion vibber (brion @ pobox.com)
I added this to LocalSettings.php and it worked:
$wgDefaultUserOptions['watchdefault'] = true;
Thanks.
--Ben
On 4/28/05, Brion Vibber brion@pobox.com wrote:
Benjamin FrantzDale wrote:
I've googeld and grepped, but no luck. I want to set the default options
for
new users. In particular I want new users to have "Add pages you edit to your watchlist" set by default.
How would I do this?
# Settings added to this array will override the language globals for # the user preferences used by anonymous visitors and newly created # accounts. (See names and sample values in languages/Language.php) # # For instance, to disable section editing links: # $wgDefaultUserOptions['editsection'] = 0; # $wgDefaultUserOptions = array();
-- brion vibber (brion @ pobox.com http://pobox.com)
MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
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
Carlton B wrote:
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
In the 1.4.2 release, Line 266 is:
if (!$u->checkPassword( $this->mPassword )) {
For this to fail in the way you describe, the LoginForm::initUser() method would have to return something broken when called here:
if ( $wgAuth->authenticate( $u->getName(), $this->mPassword ) ) { $u =& $this->initUser( $u );
It doesn't look like that should be possible, though, unless your plugin's initUser method (which is called from LoginForm's to optionally modify the user object before it's saved) looks something like this:
function initUser( &$u ) { $u = 'This will break'; }
If you're modifying the user object in that method, make sure you're not replacing it with a non-object.
-- brion vibber (brion @ pobox.com)
-----Original Message----- From: mediawiki-l-bounces@Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org]On Behalf Of Brion Vibber Sent: Friday, April 29, 2005 11:20 AM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] AuthPlugin always fails with fatal error on initialauthentication
Carlton B wrote:
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/SpecialUs erlogin.ph
p on line 266
In the 1.4.2 release, Line 266 is:
if (!$u->checkPassword( $this->mPassword )) {
For this to fail in the way you describe, the LoginForm::initUser() method would have to return something broken when called here:
if ( $wgAuth->authenticate( $u->getName(), $this->mPassword ) ) { $u =& $this->initUser( $u );
It doesn't look like that should be possible, though, unless your plugin's initUser method (which is called from LoginForm's to optionally modify the user object before it's saved) looks something like this:
function initUser( &$u ) { $u = 'This will break'; }
If you're modifying the user object in that method, make sure you're not replacing it with a non-object.
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
Carlton B wrote:
It doesn't look like that should be possible, though, unless your plugin's initUser method (which is called from LoginForm's to optionally modify the user object before it's saved) looks something like this:
function initUser( &$u ) { $u = 'This will break'; }
If you're modifying the user object in that method, make sure you're not replacing it with a non-object.
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.
No, I checked this carefully when trying to reproduce your problem (and successfully doing it only with the above code) -- it requires **LoginForm::initUser** to return a reference. **AuthPlugin::initUser** is a different function and doesn't return anything, and its return value if any is never used.
Yeah, that's lame-looking.
-- brion vibber (brion @ pobox.com)
-----Original Message----- From: mediawiki-l-bounces@Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org]On Behalf Of Brion Vibber Sent: Saturday, April 30, 2005 6:08 AM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] AuthPlugin always fails with fatal erroron initialauthentication
Carlton B wrote:
It doesn't look like that should be possible, though, unless your plugin's initUser method (which is called from LoginForm's to optionally modify the user object before it's saved) looks something like this:
function initUser( &$u ) { $u = 'This will break'; }
If you're modifying the user object in that method, make sure you're not replacing it with a non-object.
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.
No, I checked this carefully when trying to reproduce your problem (and successfully doing it only with the above code) -- it requires **LoginForm::initUser** to return a reference. **AuthPlugin::initUser** is a different function and doesn't return anything, and its return value if any is never used.
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
Carlton B wrote:
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.
Can you confirm that you made no other changes to the code? Have you followed the execution path to make sure there's no other place that's using the return value? Have you confirmed that the return value is used by checking for the returned value?
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.
That's exactly the reproduced behavior, yes.
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:
- 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.
Are you using any PHP accelerator plugins? If so, which and what versions?
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?
Have you tested this? Does it in fact help?
-- brion vibber (brion @ pobox.com)
-----Original Message----- From: mediawiki-l-bounces@Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org]On Behalf Of Brion Vibber Sent: Saturday, April 30, 2005 11:08 AM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] AuthPlugin always fails withfatal erroron initialauthentication
Carlton B wrote:
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.
Can you confirm that you made no other changes to the code? Have you followed the execution path to make sure there's no other place that's using the return value? Have you confirmed that the return value is used by checking for the returned value?
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.
Perhaps it's my version of PHP. I am on php 4.3.11.
Are you using any PHP accelerator plugins? If so, which and what versions?
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
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?
Have you tested this? Does it in fact help?
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
-----Original Message----- From: mediawiki-l-bounces@Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org]On Behalf Of Carlton B Sent: Saturday, April 30, 2005 9:50 AM To: MediaWiki announcements and site admin list Subject: RE: [Mediawiki-l] AuthPlugin always fails with fatalerroron initialauthentication
-----Original Message----- From: mediawiki-l-bounces@Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org]On Behalf Of Brion Vibber Sent: Saturday, April 30, 2005 6:08 AM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] AuthPlugin always fails with fatal erroron initialauthentication
Carlton B wrote:
It doesn't look like that should be possible, though, unless your plugin's initUser method (which is called from LoginForm's to
optionally
modify the user object before it's saved) looks something like this:
function initUser( &$u ) { $u = 'This will break'; }
If you're modifying the user object in that method, make sure
you're not
replacing it with a non-object.
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.
No, I checked this carefully when trying to reproduce your problem (and successfully doing it only with the above code) -- it requires **LoginForm::initUser** to return a reference. **AuthPlugin::initUser** is a different function and doesn't return anything, and its return value if any is never used.
I revisited this because it was bothering me not to know, and I think I arrived at a solution. After looking at the code some more, I found that the reference to the user object was intact both before and in the call to **LoginForm::initUser**, but was hosed afterward. This was even if I commented out all references to **AuthPlugin::initUser**. At that point I was back to the theory of generic "PHP4 does a bad job with references" and then I thought, we can avoid this can't we? Why does **LoginForm::initUser** need to return a reference at all? If you've passed it a reference, you're operating on the copy external to the function's scope. So why do you need to return it and capture that value? It's totally spurious and we could reduce our exposure to reference mishandling by removing it.
Thus, I simply amended line 264 of SpecialUserlogin.php from this: $u =& $this->initUser( $u ); to this: $u = $this->initUser( $u );
And since you're passing in the value by reference, I figured we could even do this (still on 264): $this->initUser( $u );
Both of those solutions work repeatably, without any odd workarounds. So I think I'll leave it that way.
I will be glad when we can put PHP 4 behind us...
-Carlton
mediawiki-l@lists.wikimedia.org