Hi,
I just tried to fix my timezone settings now that daylight savings is over.
I get the following message:
Your password is invalid or too short. It must have at least 1 character and be different from your username.
If the password boxes are empty, the system should not assume that I was trying to change my password.
Timwi
Hi!
2008/11/5 Timwi timwi@gmx.net:
I get the following message:
Your password is invalid or too short. It must have at least 1 character and be different from your username.If the password boxes are empty, the system should not assume that I was trying to change my password.
If the password boxes are really empty, the system assumes that. However, if you use some password-remembering browser (such as Firefox), it "helpfully" pre-fills the "current password" box, leading to this. At least, that is what happened to me. Be sure to manually clear the "old password" editbox before changing other preferences, and everything should work fine.
-- [[cs:User:Mormegil | Petr Kadlec]]
On Wed, Nov 5, 2008 at 12:28 PM, Petr Kadlec petr.kadlec@gmail.com wrote:
If the password boxes are really empty, the system assumes that. However, if you use some password-remembering browser (such as Firefox), it "helpfully" pre-fills the "current password" box, leading to this. At least, that is what happened to me. Be sure to manually clear the "old password" editbox before changing other preferences, and everything should work fine.
That still seems like a bug on our part. The extra (and unintuitive) step shouldn't be necessary.
2008/11/5 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Wed, Nov 5, 2008 at 12:28 PM, Petr Kadlec petr.kadlec@gmail.com wrote:
If the password boxes are really empty, the system assumes that. However, if you use some password-remembering browser (such as Firefox), it "helpfully" pre-fills the "current password" box, leading to this. At least, that is what happened to me. Be sure to manually clear the "old password" editbox before changing other preferences, and everything should work fine.
That still seems like a bug on our part. The extra (and unintuitive) step shouldn't be necessary.
And what do you think we should do? From our viewpoint, the situation is identical to the user trying to set his password to empty string.
So, if a user really does try to do that, should we just ignore it, not telling him anything? Hmmmā¦ We could say "if you tried to clear your password, we ignored it, as that is not allowed, but other preferences have been changed successfully, but I am not sure how much of an improvement is that. We might also try to outsmart Firefox by clearing the editbox explicitly using JavaScript shortly after the page is loaded. (I don't know if that would even work, but maybe worth an attempt.)
-- [[cs:User:Mormegil | Petr Kadlec]]
Just to add my $0.02: I agree that this is due to something beyond the control of mediawiki and probably shouldn't be worked around -
Clearing the box down with JS should be easy but if you're going to wait more than a few milliseconds to do it, an experienced user may well have started to type into the box by that time - and silently chopping off the first few chars of your old password is not a great plan. (This is more likely to happen if it's driven by the page's onload event which won't fire until after all images etc... Are loaded meaning the PW box itself may have been visible for a number of seconds on a slow connection)
I was under the impression that FF and other browsers remembered passwords based on the URL and field names (please correct me if I'm wrong) so I'm not sure why it's pre-populating the password on that page (the edit box has a different name to the login page) unless someone has specifically prompted the browser to remember their password on the change password (preferences) page - which seems to me to be utterly pointless in the first place.
Can you clarify why exactly FF is remembering the password on that page - did you ask it to?
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Petr Kadlec Sent: 05 November 2008 17:42 To: Wikimedia developers Subject: Re: [Wikitech-l] Bug in user prefereces
2008/11/5 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Wed, Nov 5, 2008 at 12:28 PM, Petr Kadlec petr.kadlec@gmail.com
wrote:
If the password boxes are really empty, the system assumes that. However, if you use some password-remembering browser (such as Firefox), it "helpfully" pre-fills the "current password" box,
leading
to this. At least, that is what happened to me. Be sure to manually clear the "old password" editbox before changing other preferences, and everything should work fine.
That still seems like a bug on our part. The extra (and unintuitive) step shouldn't be necessary.
And what do you think we should do? From our viewpoint, the situation is identical to the user trying to set his password to empty string.
So, if a user really does try to do that, should we just ignore it, not telling him anything? Hmmm... We could say "if you tried to clear your password, we ignored it, as that is not allowed, but other preferences have been changed successfully, but I am not sure how much of an improvement is that. We might also try to outsmart Firefox by clearing the editbox explicitly using JavaScript shortly after the page is loaded. (I don't know if that would even work, but maybe worth an attempt.)
-- [[cs:User:Mormegil | Petr Kadlec]] _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________
P Please think of the environment before you print this email
________________________________________________________________________ This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. This footnote also confirms that this email message has been swept for the presence of computer viruses but this in no way indicates that the message is virus free. Teleperformance is a trading style of MM Teleperformance Ltd: Reg No. 02060289 England: Registered Office: St James House, Moon Street, Bristol, BS2 8QY. VAT No.763 0980 18 _______________________________________________________________________
Simon Orr wrote:
I was under the impression that FF and other browsers remembered passwords based on the URL and field names (please correct me if I'm
This could be a MediaWiki installation not using short URLs, in which case Special:UserLogin and Special:Preferences would both be under the path - index.php - so the browser might treat them as the same page.
MinuteElectron.
MinuteElectron wrote:
Simon Orr wrote:
I was under the impression that FF and other browsers remembered passwords based on the URL and field names (please correct me if I'm
This could be a MediaWiki installation not using short URLs, in which case Special:UserLogin and Special:Preferences would both be under the path - index.php - so the browser might treat them as the same page.
I admit I hadn't considered that, however, the login page uses <input name="wpPassword"> whereas the preferences page uses <input name="wpOldpass"> (at least on my install) so I'm surprised it's confusing the two unless it's been specifically told to remember the old password when a password was changed - in fact it would be interesting to know if it's populating the correct "old" password or is in fact using a very old one.
P Please think of the environment before you print this email
________________________________________________________________________ This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. This footnote also confirms that this email message has been swept for the presence of computer viruses but this in no way indicates that the message is virus free. Teleperformance is a trading style of MM Teleperformance Ltd: Reg No. 02060289 England: Registered Office: St James House, Moon Street, Bristol, BS2 8QY. VAT No.763 0980 18 _______________________________________________________________________
On Wed, Nov 5, 2008 at 12:51 PM, Simon Orr Simon.Orr@teleperformance.co.ukwrote:
Just to add my $0.02: I agree that this is due to something beyond the control of mediawiki and probably shouldn't be worked around -
Clearing the box down with JS should be easy but if you're going to wait more than a few milliseconds to do it, an experienced user may well have started to type into the box by that time - and silently chopping off the first few chars of your old password is not a great plan. (This is more likely to happen if it's driven by the page's onload event which won't fire until after all images etc... Are loaded meaning the PW box itself may have been visible for a number of seconds on a slow connection)
I was under the impression that FF and other browsers remembered passwords based on the URL and field names (please correct me if I'm wrong) so I'm not sure why it's pre-populating the password on that page (the edit box has a different name to the login page) unless someone has specifically prompted the browser to remember their password on the change password (preferences) page - which seems to me to be utterly pointless in the first place.
Can you clarify why exactly FF is remembering the password on that page
- did you ask it to?
I could be wrong here as well, but I was always under the impression FF remembered passwords based on domain name (including subdomain(s)), meaning any password box on en.wikipedia (or any domain) will be autofilled.
Like I said, I could be wrong, but I thought that's how it was and seems consistent with my own observations.
-Chad
Dear All,
I am new to developing extensions for mediawiki and need your guidance with a particular extension I am working on for my research. Basically, I want to color the words in an article based on its age. As a first step, I am writing a simple extension which just colors all words in an article. I am having problems with the hook I need to use.
I use the 'OutputPageBeforeHTML' hook to add span tags to the text before it is actually displayed. But that does not seem to be working. So I have 2 questions.
1. Which hook would be the right one to add span tags to every word in an article. 2. How do i extract the words in an article, without the markup details?
Any help would be appreciated.
Thanks
Avanidhar
avani@cs.umn.edu schrieb:
Dear All,
I am new to developing extensions for mediawiki and need your guidance with a particular extension I am working on for my research. Basically, I want to color the words in an article based on its age.
Perhaps you are interested in the WikiTrust project, which does something like this, but a bit more sohpisticated. Have a look at http://trust.cse.ucsc.edu/ and, for an impression of what it does, at http://wiki-trust.cse.ucsc.edu/index.php?title=Cheerleading&direction=prev&oldid=104848222.
Even if it's not quite what you want, you can perhaps find the relevant bits in the source code.
-- daniel
On Wed, Nov 5, 2008 at 12:41 PM, Petr Kadlec petr.kadlec@gmail.com wrote:
And what do you think we should do? From our viewpoint, the situation is identical to the user trying to set his password to empty string.
So, if a user really does try to do that, should we just ignore it, not telling him anything?
That seems fairly reasonable, to be honest. Fields that aren't filled in can be ignored.
We might also try to outsmart Firefox by clearing the editbox explicitly using JavaScript shortly after the page is loaded. (I don't know if that would even work, but maybe worth an attempt.)
Isn't there some HTML directive for inputs saying "don't auto-fill this box"?
On Wed, Nov 05, 2008 at 12:56:23PM -0500, Aryeh Gregor wrote:
Isn't there some HTML directive for inputs saying "don't auto-fill this box"?
Adding a property autocomplete="off" works in Firefox and IE, at least according to various Google searches. It won't validate, though, if that matters to you.
On Wed, Nov 5, 2008 at 7:40 PM, Brad Jorsch b-jorsch@northwestern.edu wrote:
On Wed, Nov 05, 2008 at 12:56:23PM -0500, Aryeh Gregor wrote:
Isn't there some HTML directive for inputs saying "don't auto-fill this box"?
Adding a property autocomplete="off" works in Firefox and IE, at least according to various Google searches. It won't validate, though, if that matters to you.
Here is a ridiculous hack to able that:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [ <!ATTLIST html xmlns:goo CDATA #FIXED "http://zerror.com/google/autocomplete"
<!ATTLIST input autocomplete CDATA #IMPLIED> ]
<html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml" xmlns:goo="http://zerror.com/google/autocomplete" > <head><title>Example</title></head> <body> <input type="text" name="search" autocomplete="on" value="Looks mon, no hands!" /> </body> </html>
Petr Kadlec wrote:
And what do you think we should do?
MediaWiki should not try to change the password if no new password was entered.
From our viewpoint, the situation is identical to the user trying to set his password to empty string.
So put a short piece of text next to be text box saying "empty password not allowed" (if that is the only restriction).
Timwi
2008/11/8 Timwi timwi@gmx.net:
Petr Kadlec wrote:
And what do you think we should do?
MediaWiki should not try to change the password if no new password was entered.
Some wikis allow users to have no password (and it's still the default setting), and in that case, it is a completely valid operation (see http://www.mediawiki.org/wiki/Manual:$wgMinimalPasswordLength).
-- [[cs:User:Mormegil | Petr Kadlec]]
On Sat, Nov 8, 2008 at 1:40 PM, Petr Kadlec petr.kadlec@gmail.com wrote:
Some wikis allow users to have no password (and it's still the default setting), and in that case, it is a completely valid operation (see http://www.mediawiki.org/wiki/Manual:$wgMinimalPasswordLength).
That's even scarier. In this situation, the password would get silently set to empty.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Petr Kadlec wrote:
Hi!
2008/11/5 Timwi timwi@gmx.net:
I get the following message:
Your password is invalid or too short. It must have at least 1 character and be different from your username.If the password boxes are empty, the system should not assume that I was trying to change my password.
If the password boxes are really empty, the system assumes that. However, if you use some password-remembering browser (such as Firefox), it "helpfully" pre-fills the "current password" box, leading to this. At least, that is what happened to me. Be sure to manually clear the "old password" editbox before changing other preferences, and everything should work fine.
We're still kind of assuming it's something like this problem. :)
The proper thing to do is to move the password reset form out of preferences to its own form -- it really shouldn't be there anyway.
- -- brion
I think Google Chrome has the same behaviour. ---Bence
On Wed, Nov 5, 2008 at 6:15 PM, Timwi timwi@gmx.net wrote:
Hi,
I just tried to fix my timezone settings now that daylight savings is over.
I get the following message:
Your password is invalid or too short. It must have at least 1 character and be different from your username.If the password boxes are empty, the system should not assume that I was trying to change my password.
Timwi
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hoi, Given that I currently have user profiles on 427 WMF wikis, I will not bother changing settings like my timezone. It is just to much work. Many applications allow you to select the timezone itself and have the offset to GMT be a consequence of the timezone selected. An equally good change would be to make the timezone part of preferences that are maintained globally for a user. Thanks, GerardM
On Wed, Nov 5, 2008 at 6:15 PM, Timwi timwi@gmx.net wrote:
Hi,
I just tried to fix my timezone settings now that daylight savings is over.
I get the following message:
Your password is invalid or too short. It must have at least 1 character and be different from your username.If the password boxes are empty, the system should not assume that I was trying to change my password.
Timwi
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2008/11/6 Gerard Meijssen gerard.meijssen@gmail.com:
Given that I currently have user profiles on 427 WMF wikis, I will not bother changing settings like my timezone. It is just to much work. Many applications allow you to select the timezone itself and have the offset to GMT be a consequence of the timezone selected. An equally good change would be to make the timezone part of preferences that are maintained globally for a user.
This has nothing to do with this problem; this problematic behavior occurs for any change of preferences, e.g. enabling some gadget, it is not in any way limited to time zones.
For the request you describe, take a look at https://bugzilla.wikimedia.org/show_bug.cgi?id=505 (which would, indeed, be a useful thing to have).
-- [[cs:User:Mormegil | Petr Kadlec]]
Hoi, I do not have the illusion that my need for preferences that have a global impact is unique. When I read the bug, I find that it was looked at for the last time in 2004. In the mean time we have implemented SUL, in the mean time much of what has been said in the bug report there is not that relevant anymore.
The problem that Timwi described is one that needs a solution. When people aim to fix this, it makes sense to do a proper job and consider the other issues that exist as well. Because of this I think my reaction to this thread is appropriate. :) It would be nice not to do the job, but to do a great job. Thanks, GerardM
On Thu, Nov 6, 2008 at 2:38 PM, Petr Kadlec petr.kadlec@gmail.com wrote:
2008/11/6 Gerard Meijssen gerard.meijssen@gmail.com:
Given that I currently have user profiles on 427 WMF wikis, I will not bother changing settings like my timezone. It is just to much work. Many applications allow you to select the timezone itself and have the offset
to
GMT be a consequence of the timezone selected. An equally good change
would
be to make the timezone part of preferences that are maintained globally
for
a user.
This has nothing to do with this problem; this problematic behavior occurs for any change of preferences, e.g. enabling some gadget, it is not in any way limited to time zones.
For the request you describe, take a look at https://bugzilla.wikimedia.org/show_bug.cgi?id=505 (which would, indeed, be a useful thing to have).
-- [[cs:User:Mormegil | Petr Kadlec]]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Gerard Meijssen wrote:
Hoi, Given that I currently have user profiles on 427 WMF wikis, I will not bother changing settings like my timezone. It is just to much work. Many applications allow you to select the timezone itself and have the offset to GMT be a consequence of the timezone selected. An equally good change would be to make the timezone part of preferences that are maintained globally for a user. Thanks, GerardM
Why the timezone and not the preferred math display or image size? It should be a global preferencing so you could globally set any preference you want to.
Hoi, If we are to have global preferences fine. With the defaults for "preferred math display" or "image size" I have no problem. The offset for time is not usuable and i have user profiles effectively in two time zones; this is confusing
So I agree, create a framework that allows for global preferences and implement the time offset / time zone soonest. Thanks, GerardM
On Thu, Nov 6, 2008 at 3:57 PM, Platonides Platonides@gmail.com wrote:
Gerard Meijssen wrote:
Hoi, Given that I currently have user profiles on 427 WMF wikis, I will not bother changing settings like my timezone. It is just to much work. Many applications allow you to select the timezone itself and have the offset
to
GMT be a consequence of the timezone selected. An equally good change
would
be to make the timezone part of preferences that are maintained globally
for
a user. Thanks, GerardM
Why the timezone and not the preferred math display or image size? It should be a global preferencing so you could globally set any preference you want to.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Gerard Meijssen wrote:
Hoi, If we are to have global preferences fine. With the defaults for "preferred math display" or "image size" I have no problem. The offset for time is not usuable and i have user profiles effectively in two time zones; this is confusing
So I agree, create a framework that allows for global preferences and implement the time offset / time zone soonest. Thanks, GerardM
On Thu, Nov 6, 2008 at 3:57 PM, Platonides Platonides@gmail.com wrote:
Gerard Meijssen wrote:
Hoi, Given that I currently have user profiles on 427 WMF wikis, I will not bother changing settings like my timezone. It is just to much work. Many applications allow you to select the timezone itself and have the offset
to
GMT be a consequence of the timezone selected. An equally good change
would
be to make the timezone part of preferences that are maintained globally
for
a user. Thanks, GerardM
Why the timezone and not the preferred math display or image size? It should be a global preferencing so you could globally set any preference you want to.
I don't think there's anyone who thinks that global preferences would be a bad idea (or if there are, they're a tiny minority). It just hasn't been done yet. Any global preferences system would probably come after a rewrite of the current preferences system[1] as it would probably be done in mostly the same way. Doing it one preference at a time would be rather inefficient.
The main issue is that you may not want the same preferences everywhere. For example, email notification settings, which also has the issue of not being consistent across projects. I may want notification for watchlisted changes on small projects I don't check often, but not for commons and meta, as I check those often. Or you may not want to use UTC on projects that use a different default timezone for signatures and such. So the global preferences would have to be locally overridable.
[1]http://www.mediawiki.org/wiki/Deficits_of_the_current_preferences_system
I thought it didn't have anything to do with the preferences system itself, but was a performance issue; the context switching needed to get the preferences everytime would be too darn expensive. I vaguely recall Domas mentioning something like that...
Siebrand
-----Oorspronkelijk bericht----- Van: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Namens Alex Verzonden: donderdag 6 november 2008 20:49 Aan: Wikimedia developers Onderwerp: Re: [Wikitech-l] Bug in user prefereces
I don't think there's anyone who thinks that global preferences would be a bad idea (or if there are, they're a tiny minority). It just hasn't been done yet. Any global preferences system would probably come after a rewrite of the current preferences system[1] as it would probably be done in mostly the same way. Doing it one preference at a time would be rather inefficient.
The main issue is that you may not want the same preferences everywhere. For example, email notification settings, which also has the issue of not being consistent across projects. I may want notification for watchlisted changes on small projects I don't check often, but not for commons and meta, as I check those often. Or you may not want to use UTC on projects that use a different default timezone for signatures and such. So the global preferences would have to be locally overridable.
[1]<http://www.mediawiki.org/wiki/Deficits_of_the_current_preferences_system
-- Alex (wikipedia:en:User:Mr.Z-man)
On Thu, Nov 6, 2008 at 2:57 PM, Siebrand Mazeland s.mazeland@xs4all.nl wrote:
I thought it didn't have anything to do with the preferences system itself, but was a performance issue; the context switching needed to get the preferences everytime would be too darn expensive. I vaguely recall Domas mentioning something like that...
Domas doesn't want a hit on the global user table for every page view, IIRC, no. However, there could be implementations that avoid that, perhaps using memcached, or just stupid denormalization to all the other databases (a button saying "change this preference on all my accounts and any new ones").
On Fri, Nov 7, 2008 at 11:18 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
Domas doesn't want a hit on the global user table for every page view, IIRC, no. However, there could be implementations that avoid that, perhaps using memcached, or just stupid denormalization to all the other databases (a button saying "change this preference on all my accounts and any new ones").
We already cache global user objects in memcached, and memcached hits are cheap, anyway (on the order of a few hundred us).
wikitech-l@lists.wikimedia.org