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)