Also, update monobook/main.css to actually offer the redlink colour that's been seen on wikipedia since forever. It's only when you turn off this per-user styling stuff that you realise that it's been overriding a different colour since September 2004 :D
* Make Live Preview entirely JS-based. It requires no modification of the HTML.
* Replace annoying slideDown with less annoying fadeIn().
* Ensure that elements not supposed to be shown are not, in fact, shown by fadeIn().
* Remove some redundant lines of code.
* Make compatible with the current jQuery usage in MediaWiki.
* Reverted HttpFunctions.php to r45549 and renamed wgSyncHTTPTimeout back to wgHTTPTimeout
* Edited out the asynchronous features from UploadFromUrl. Made fetchFile() use the curlCopy() function from new-upload r47811 instead of Http::doDownload(). Wrote my own URL validity check to avoid having to use either of the two buggy precedents.
* Removed UploadFromChunk
* Removed chunk upload and background status from ApiUpload.php
* Reverted r54669, use of addScriptClass()
* Left getHeadScripts() in its current location (OutputPage) instead of moving it back to SkinTemplate, just added wikibits.js to it to replace the removed addCoreScripts2Top()
* hide some user settings if user is not allowed to send e-mail, but can receive e-mail
* update API 'cannot send e-mail' message
* FIXME: gives 'mailnologin'/'mailnologintext' as error. Error handling should be made more fine grained
Looks like the base problem is that empty is being interpreted as "put empty in the sig" instead of as "use default sig" at signature replacement time.
We shouldn't be saving the username into preferences if it hasn't been explicitly typed; if the user changes their name, they should automatically pick up the new value.
autofocus attribute added in some places; this looks like it's respected
by both recent Opera and recent WebKit. Its function is
self-explanatory. :) I used this in a few obvious places like
Special:UserLogin and Special:ResetPass to focus the first field in the
form. Could be used in other places too: Special:Search, etc.
required attribute added in some places. This is only supported in
recent Opera at the moment. Also self-explanatory: it won't allow form
submission if the field is empty.
For stuff using HTMLForm (i.e., Special:Preferences), validation will be
done for integers and floats. Browsers that support this (recent Opera)
will not allow non-integers to be submitted for integer fields, will not
allow non-floating-point values to be submitted for float fields, and
will enforce any min/max values specified. Opera also gives little up
and down arrows to allow the user to increment/decrement the value in
addition to letting them edit the field as text.
For HTMLForm and account creation, the email input type is used for
e-mails. This enforces a sane set of values for e-mails (alphanumerics
plus some ASCII punctuation, with an @ in it). Again, this is supported
only by recent Opera (yay Opera!). Note that this is actually more
restrictive than what we currently check for on the server side; it
might be sane to tighten up our server-side checks to forbid e-mail
addresses that HTML 5 forbids.
In all cases, the extra features aren't added if $wgHtml5 is false, and
will be ignored by non-supporting browsers.
The major room for further improvement here is use of the pattern
attribute. We can have the client refuse to submit the form unless it
matches a regex! The HTML 5 spec says that if a title attribute is
provided, it should be a message that explains what the valid values
are and browsers should provide it to the user if the regex doesn't
match, so it's not a usability problem. I didn't bother adding that
anywhere at this point because it would require adding new messages, but
it should be easy to do. Note of course that HTMLForm should be updated
to verify that pattern matches on the server side as well -- this way we
have a clean, unified way of ensuring that our client and server checks
are the same.
* (bug 16697) Unicode combining characters are difficult to edit in some browsers
Adds font style option to preferences and adds default override for Lingala (ln)
Authentication is via a token entered in preferences, if not blank. If
you set a token in your preferences, the following sort of link will
generate the RSS feed:
api.php?action=feedwatchlist&list=watchlist&wluser=Simetrical&wltoken=91c1ef18279f9c24ccf67a79e899ae4d2a3201bc
I haven't actually added the <link> tag to Special:Watchlist, since I've
done enough coding for one night. Someone else can feel free to do
that (otherwise people might get kind of confused :) ).
An auto-generated random token is suggested to the user on the pref page
so that they don't have to be too creative. Pref help text is rather
underemphasized in the default style, though.
It would be worth considering making this opt-out instead of opt-in,
but that would require some voodoo magic to get the default prefs to
work right (since we'd need a different value for each user). We might
set the default to some function of user id + secret site-specific value
to avoid having to store the values in the database.
Since the feature is implemented via the API, it only works if the API
is enabled. Some API people might want to review my code for sanity.
Bug: 471
* use array type parameter instead of string to escapeLocalUrl(), getFullURL() and getFullUrl() for readability
* add FIXME in Parser.php and LogEventsList.php where I didn't know how to replace makeKnownLinkObj by link()
* return type for private method Skin::editUrlOptions() changed from string to array
* some code readability improvements
Linking this to r51559 for CodeReview as there is some discussion there, and these changes are very similar.
Todo: core special pages
Commit message was: "* (bug 18958) Added ability to disable entire variant conversion engine per user preferences (languages with language converter class only)"
Reverted because of multiple issues on CodeReview, notably:
* Unexplained rename of a configuration variable, with no backwards-compatibility code.
* Suspected parser cache pollution.
* Variant tabs flip-flop with parser cache misses and hits.
* Hacky implementation: changing configuration variables on the fly is almost always a bad idea, unless you are writing a configuration extension.
* Implementation of default is done as a special case in code accessing the preference, rather than by adding an entry to $wgDefaultUserOptions.
