Last modified: 2011-03-09 21:14:51 UTC
Hello, I've been working on a small visual improvement on the login/registration form of MediaWiki (MediaWiki 1.5 CVS). I wrote a small JS script, which disables/enables the "Login" and "Create new account" buttons accordingly; for example, you are not allowed to click on "Create new account" if you haven't filled in the "retype password" field. What's more, the code checks if the two passwords match before the form is sent to the server, and displays a message if they don't (and also cancels the navigation process and clears the password fields). If javascript is disabled, the pages will work normally, as they would without my code. The only file I modified is /include/templates/Userlogin.php. Since I don't have CVS write access, I am submitting the modified file here. If it is possible, I would appreciate it if one of you developers with read/write CVS access can take a few minutes to check my code and CVS commit the file. I am attaching the patch file in this bugzilla tracker item. Please let me know if there's something you don't like, or something you'd like me to add, and please let me know if and when you include my changes to the CVS (or if you don't, the reasons why you won't) Thank you in advance :-) Dionysis Zindros.
Created attachment 617 [details] Userlogin.php
This sounds very good, but could you please supply a patch to the current CVS HEAD version rather than a complete replacement for the file, it might even get in 1.5 then;)
Created attachment 641 [details] Userlogin.php patch
I made a patch myself and attached it, howver I'm unable to get it to work in my browser (firefox 1.0), what browsers did you test it with?
Thanks for creating a patch file! I didn't know how to make one... Regarding the testing, I've only tested it under Firefox 1.0.4, Internet Explorer (XP SP2), K-Meleon 0.9 and Opera 7.23 (which made me assume that it also works for Opera 8, but I can't be sure about that). So, I think it works under the latest version of FireFox, and probably for previous versions too (although not tested). Do you get a JavaScript error or something similar? Keep in mind that JavaScript should be enabled to be able to use this feature.
(In reply to comment #5) > Thanks for creating a patch file! I didn't know how to make one... Regarding the > testing, I've only tested it under Firefox 1.0.4, Internet Explorer (XP SP2), > K-Meleon 0.9 and Opera 7.23 (which made me assume that it also works for Opera > 8, but I can't be sure about that). So, I think it works under the latest > version of FireFox, and probably for previous versions too (although not > tested). Do you get a JavaScript error or something similar? Keep in mind that > JavaScript should be enabled to be able to use this feature. Turns out that the whole thing was just commented out (see patch) with <!-- -->, works okey now except for the error with && being displayed as a literal (should be & or wrapped in a CDATA section).
The commenting is necessary, so that browsers that do not support JavaScript do not display the client-side script source code inside the website. The HTML comment tag is ignored by all browsers which support JavaScript when it is in the first line of a <script> tag, so it is common to use it to avoid the problem of displaying the source as text. Regarding the & entity, it shouldn't have been escaped with &, as it is used within the script code block, therefore not in HTML. Javascript should handle this correctly and without any problems -- as far as I know.
(In reply to comment #7) > The commenting is necessary, so that browsers that do not support JavaScript do > not display the client-side script source code inside the website. The HTML > comment tag is ignored by all browsers which support JavaScript when it is in > the first line of a <script> tag, This is only true when you view the page in nonconformance mode, try sending it with the application/xhtml+xml MIME type. > so it is common to use it to avoid the problem > of displaying the source as text. Regarding the & entity, it shouldn't have been > escaped with &, as it is used within the script code block, therefore not in > HTML. Javascript should handle this correctly and without any problems -- as far > as I know. & as a bareword is illegal unescaped and not within a CDATA block in XHTML/XML, try sending it with the application/xhtml+xml MIME type, it will produce a fatal parsing error.
(In reply to comment #8) > This is only true when you view the page in nonconformance mode, try sending it > with the application/xhtml+xml MIME type. > & as a bareword is illegal unescaped and not within a CDATA block in XHTML/XML, > try sending it with the application/xhtml+xml MIME type, it will produce a fatal > parsing error. Alright, I'll look into it and supply a new patch file, then. Thanks for letting me know about this :-)
(In reply to comment #8) > & as a bareword is illegal unescaped and not within a CDATA block in XHTML/XML, > try sending it with the application/xhtml+xml MIME type, it will produce a fatal > parsing error. I've tried replacing the & entities with & within the javascript code. The initial code used to be: if(o.wpRetype.value!=""&&(o.wpPassword.value!=o.wpRetype.value)){ Now it looks like this: if(o.wpRetype.value!=""&&(o.wpPassword.value!=o.wpRetype.value)){ However, I get a Javascript parsing error after the replacement: Error: missing ) after condition if(o.wpRetype.value!=""&&(o.wpPassword.value!=o.wpRetype.value)){ Therefore, I am not posting a new patchfile, since the current one seems okay. Ævar, if you could point out what I am doing wrong, it would be nice :-) Thanks.
I don't think that's needed. I personally avoid javascript as much as possible.
(In reply to comment #11) > I don't think that's needed. I personally avoid javascript as much > as possible. If one does not prefer javascript, he or she can disable it from the browser options. If javascript is disabled, the previous functionality of the plain HTML login form will be available, just as it is on the current MediaWiki stable release. On the other hand, if a user has javascript enabled, this will make sure that a user that wants to create account and hits "Enter" by mistake after re-entering the password and (optionally) Real Name and e-mail details will not be logged in with his or her non-existing account. If that was the case, it might have discouraged users from reattemping registeration, or confused inexperienced users. As a sidenode, keep in mind that there is javascript functionality embedded in the current stable version of MediaWiki, so there's no need to avoid javascript in general.
Can someone please review this for inclusion in 1.5 ?
I would prefer to see our horrible combined login/create account form completely redesigned into something humans can comprehend.
(In reply to comment #14) > I would prefer to see our horrible combined login/create account form > completely redesigned into something humans can comprehend. > You mean seperate the login and register form into two different pages?
login / creation have been split. Will be in 1.6
Thanks :-)
