On Nov 20, 2003, at 17:11, Evan Prodromou wrote:
So, I've been coming up with great ideas for
MediaWiki -- or, rather,
great ideas for enhancements for MediaWiki for Wikitravel's needs. But
I figure it's probably going to be easiest to get into the code if I
start working on some bugs instead.
Are there any bugs that an interested volunteer could start working on
and submitting patches for? The huge list on sourceforge is a bit
much.
Some things off the top of my head...
Login doesn't actually check that the session cookie is present, so
someone coming in with cookies disabled is told their login is
successful but it's lost when they visit the next page. We really
should check for this condition! It's a fairly frequently reported
problem, and probably not that hard to fix. In all probability, simply
checking for the existence of the session cookie at the top of
SpecialUserlogin.php and complaining if it's not there will be enough.
(Bug #770011)
The "Cologne Blue" skin has a few minor problems where useful/important
links are missing, and various stylistic issues. The structure of the
current skin code is kind of difficult to grasp, but the individual
bits are fairly not too insane, I think. (Bugs #825774, 827160, etc)
See
http://meta.wikipedia.org/wiki/Cologne_Blue_skin_problems
If you want an ugly but simple and important job... we'd like to remove
our dependency on register_globals (the option, formerly on by default,
in which GET/POST parameters and cookies are dumped into the global
variable namespace). Since PHP 4.2 this option is off by default, as it
can lead to security problems when there's sloppy coding and you use a
variable that turns out to be uninitialized -- until someone slips it
into a URL or cookie.
Moving from the globals to the $_GET and $_POST arrays would let us
remove that configuration dependency and potentially clean up some
security trouble if there are any more surprises. (Also related to bug
#842921)
It's drudge work, but if you pick it up you'll get a quick overview of
the whole codebase! :)
Another thing that would be nice would be proper locking and/or use of
transactional BEGIN/COMMIT wrappers and handling of errors with
rollbacks where multiple SQL statements are required to perform a
read/write operation. We do have race conditions where simultaneous
actions could perhaps interfere with each other, or where an operation
that fails partway through leaves the database in an inconsistent
state. Again, that's kind of drudge work, sorry. :)
See also here:
http://meta.wikipedia.org/wiki/Development_tasks
-- brion vibber (brion @
pobox.com)