It's likely going to be a longterm project that won't be stable enough
for general use right away.
^_^ If you're interested in the long story read on... I have a bad habit
of writing to much, and the first 4 paragraphs and the first 2
sentences, and 3 words of the following text were written before I
realized I should probably have just written a short reply... for
completeness I continued to write after this, rotfl...
----
When I originally planned it I knew it would be a more long term
project. There is a huge pile of code in MediaWiki that depends on the
assumption that _ and space always map to each other, and code does some
fairly ugly things as a result.
Back when I originally started the project, I ran into what would have
become an insanely problematic bug if I didn't catch it. In MediaWiki a
user's username is stored inside the database using spaces instead of
underscores like the titles are.
Unfortunately when you change getText's definition from dbkey converted
to spaces, to the actual format of the title to display, you run into a
bit of a problem.
A fair bit of core hinges on the comparison of $title->getText() ==
$user->getName(). So all of a sudden, if you go and change
"User:Dantman" to "User:dantman" then "dantman" no longer
equals
"Dantman" which is in the db, and voila, I do not /exist/ and cannot login.
One of the resulting things that I had to do when /rewriting/ the title
backend, was to also /rewrite/ the user backend. Because I'm using a
rev_title_ui, I no longer need to worry about populating the
page_title_ui with data, now I just default to NULL and use default
normalization. However, I still need to solve the username issue.
Basically this means I've got to change the backend storage of usernames
from using spaces, to using underscores. Quite simply, I need to run a
REPLACE over every row in the 6 different columns in the database that
store the username.
So obviously this will also entail a schema change that'll hold it back
a bit longer as Wikimedia will need to think of some way to apply it.
Now that I think about it, I might add in a compatibility option, one
where the User class converts spaces in the username it extracts into
underscores on the PHP side, and the Job que slowly does the migration
in the backend. Then large wiki could enable that option and let the
change happen slowly in the background, then when it's complete (don't
know how that'll be calculated yet) they can disable the option. Of
course, that option won't be something enabled by default as the
assumption it causes would interfere with any extension to the normalizer.
But over that, there is a fair bit of ui code that needs to be fixed,
even simply because of the username change. User::getName() has been
used all over the MediaWiki codebase, now that it's usage has been
changed, I need to migrate some calls from using User::getName() to what
for now I've dubbed User::getNameText(). I opted for using
User::getName() as the keyform and making it the same as
User::getTitleKey() because it's probably better for all the code lying
around that uses it for comparing equality of users. Of course, there
are a fair bit of places where a $title->getText() == $user->getName()
needs to be changed to use $title->getDBkey().
That being said, I think I already hunted down and fixed all those cases
inside of core. However, I ran into a bit of an issue. Apparently log
pages or rather history and other pagers verbosely use the user_text
fields, as a result I had to tweak some of the stuff in the linker to
display proper user names on those pages. It is quite likely that there
may still be residual stuff lying around the codebase where usernames
won't display properly. I actually grazed over the blocking interface
code when I was tracking down getName calls with regexxer, and I have a
feeling that the blocking interface is displaying usernames a little
incorrectly. I can't remember clearly, but I think I at least fixed the
potential issue of renaming "User:Vandal" to "User:vandal" suddenly
bypassing every block you could possibly make on them. ^_^ I don't think
WP's admins would be very happy if suddenly thousands of vandals started
roaming free cause they found out they could unblock their other
accounts by moving their userpage, rotfl...
Though I have a feeling that at some point I'm going to need to profile
this and see if the extra calls for finding out the proper username to
display in the linker is going to require me to make some optimizations
to this.
^_^ I have a new static method Title::newFromUIText(); please head the
documentation on the function and NEVER USE IT! rotfl...
Title::newFromUIText, is only meant for use by something that does
movepage like things. It basically overrides the ui text, whereas
Title::newFromText normalizes the input and queries for what the actual
ui text is when you request it. Because of the purpose of it
Title::newFromUIText does not use the link cache, and isn't mass title
performance friendly like Title::newFromText, this would be done because
if I had used the link cache, then it would be possible to pollute that
cache with bad ui texts.
I think I shall stop trying to think about more to write at this
point... At least before I make a mail to long to actually submit to
wikitech-l, heh...
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
~Profile/Portfolio:
http://nadir-seen-fire.com
-The Nadir-Point Group (
http://nadir-point.com)
--It's Wiki-Tools subgroup (
http://wiki-tools.com)
--The ElectronicMe project (
http://electronic-me.org)
-Wikia ACG on
Wikia.com (
http://wikia.com/wiki/Wikia_ACG)
--Animepedia (
http://anime.wikia.com)
--Narutopedia (
http://naruto.wikia.com)
Remember the dot wrote:
That sounds very nice! How far away is this from being
ready for the
MediaWiki trunk?