The stats for en: were not refreshed for a few weeks, now they are, but
a new problem appeared.
Brion,
According to the log file, the script parsed the 'old' database dump
file exactly up to the middle, then continued happily to do something
else.
So the cause must be that splitting and joining the > 2GB dump did not
happen transparently and the stitch between first and second half did
not match the regexp.
Secondly the webalizer stats for wiki comparisons have not been
collected since November 12, it seems that the wget procedure is on
strike.
Cheers, Erik Zachte
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)
Okay, so the dev branch is now running live on the Wikipedia servers. A
few more days to clean up remaining obvious bugs, and we'll branch this
off as the new stable branch. (Should we give it a version number, or a
release codename?)
Problems I found and fixed during the rollout:
* Language.php hadn't gotten updated to use $wgSitename, which broke
some languages and all the non-Wikipedia wikis
* Cached pages were being gzipped twice due to a broken merge (I'd
moved the call to tryFileCache(), and we ended up with both the old and
the new positions calling this function and installing output buffer
handlers! I trimmed the extra call and added a double-call check to the
function.)
* Initial text wasn't being put into the 'reason' field in the confirm
deletion screen due to a missing global declaration (also, this check
wasn't working for non-article namespaces due to incorrect usage of
namespace/title in the queries)
* 'Go' search wasn't skipping the MATCH query when $wgDisableTextSearch
was set, due to a missing global declaration
* Doubled google form, missing the search term in the text box
Problems found that still need to be fixed:
* Cookie check in Special:Userlogin fails if that's the very first page
the visitor came to in the session (possible fix: do a single redirect
if the cookie isn't found; on the second try if there's still no cookie
we complain)
* Editing MediaWiki: messages doesn't clear the entries from memcached.
($wgUseDatabaseMessages is off until this is fixed.)
There are probably other problems out there...
-- brion vibber (brion @ pobox.com)
I once spent 5 months testing the same application, and finding bug
after bug. The programmers whose code I was testing were not so gracious
as E23 or Brion, however. They kept announcing that they had "fixed all
the bugs" and seemed to find my reports dismaying.
Anyway, I guess my little daughter must have overheard me discussing
work, because she started a hobby of finding bugs from the garden
outside and bringing them in the house in little jars, to study under
her magnifying glass!
She wanted to be just like her dad, I guess :-)
Ed Poor
Last night I found and fixed a bug in the new persistent link cache
code which seriously broke updates to the link tables; when the
persistent cache was loaded, the 'old' links variables weren't being
set at all, so every link in the page would be added as a duplicate to
the database, and newly removed links would not get cleared. On top of
this the linkscc entry wasn't cleared due to a missing global
declaration. Oh, those annoying little tiny things!
Anyway, we've still got a whole bunch of _old_ link table bugs to deal
with, as well as having monstrously corrupt tables to start with. E23's
working on speeding up the link rebuild script, which is great -- soon
we hopefully will be able to clean up the tables without taking the
wikis offline for half a day just to do it.
We really should scrutinize the persistent linkcache stuff a little
more, since synchronization errors between the cache and the regular
links tables can cause fun trouble that's hard to track down.
(Particularly as the data blob in linkscc is gzipped to minimize
io/cache stress; this makes it very hard to inspect it manually.)
Anyway, a number of reported link-table bugs have been consolidated
into bug #802814:
http://sourceforge.net/tracker/index.php?
func=detail&aid=802814&group_id=34373&atid=411192
Bad link tables are mostly just a nuisance at present, but they do
interfere with a lot of things.
-- brion vibber (brion @ pobox.com)
Jason won't have a chance to install it until after the holiday
(Thursday, Thanksgiving Day in the US), but he's going to play with
it, run some benchmarks, make sure it's running right.
----- Forwarded message from Jason Richey <jasonr(a)bomis.com> -----
From: Jason Richey <jasonr(a)bomis.com>
Date: Tue, 25 Nov 2003 13:28:21 -0800
To: jwales(a)joey.bomis.com
Subject: server: big package... Full of penguins.
The server just arrived.
--
"Jason C. Richey" <jasonr(a)bomis.com>
----- End forwarded message -----
FYI
[quote]
<br />
<b>Fatal error</b>: Call to a member function on a non-object in
<b>/usr/local/apache/common/php/SpecialExport.php</b> on line <b>49</b><br />
[/quote]
Regards,
Nils.
--
Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
Hello all,
I've sent a message last week-end about further testings I
planned to do by the begenning of this week.
The tests shows that I can access any wiki site from my
workplace. The only problem is that it does not work any
more when I try to use Netscape 7.01/windows2000Pro.
There is no problem while I use Internet Explorer 5.5 sp2.
Is there something wrong with the browser based upon Mozilla
when trying to access the wiki? I did not find any pertinent
answer to this question while searching the web for such
topic.
Best regards to all and thanks in advance for your kind help,
--
Alexandre.NOUVEL(a)alternatif.net
|-> http://www.bigfoot.com/~alexandre.nouvel
|-> La copie privée et l'auto-diffusion menacées : http://eucd.info
\ I hate spam. I kill spammers. Non mais.