The API return in XML for queries with no result elements was broken a
few hours ago. I believe the culprit is r46845
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/46845 which does
say it is a "breaking change", but the break intended is that
applications may see query-continue earlier than expected (i.e.
earlier than the limit the app set), which applications should usually
handle anyway.
However it changes the XML structure for no results; if I query for
(say) recentchanges in the last few hours, and there are none, it
should (and did) return (in part):
<query><recentchanges /></query>
now it returns
<query recentchanges="">
which is not the same thing. Application code looking for the
"recentchanges" element will see the return as missing, incomplete, or
some error, rather than an empty element.
For RC, the code diff is
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/api/ApiQuer…
given the way setIndexedTagName_internal apparently works.
I think (but haven't tested) this breaks null returns for everything,
and thus a lot of applications may have trouble. Can we get it backed
out and re-committed when it generates the correct XML? (I will patch
a couple of my things for now.)
Best regards,
Robert
I've deleted all the slow refreshLinks2 jobs which have apparently been
preventing the job queue from making any headway for the last few months.
Some people report that they have received hundreds of edit notification
emails in the last few hours, due to the months of backlog now being cleared.
-- Tim Starling
Hello,
Can somebody give a status update about when the special pages will be
updated again? (like broken redirects or double redirects) The stopt
updating for almost a week now.
And what is the reason that the are not working?
Best regards,
Huib
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
> after upgrade to 1.14 we suffer from empty parts in print preview and
> print output at only some pages!
>
> It "works" only with IE7, FF and other IE versions print well.
>
> Is this a known thing?
>
> Empty part (white area) seems to start right after a toc and then
> ends at not remarkable places within text to show/print the rest of
> an article.
Now there is an example:
One wiki, one article in two versions, that differ only in one paragraph
("4.1 Quickttext"), where some characters "'" (for formatting italic)
are substituted by ".":
http://wiki-test.genealogy.net/w/index.php?title=Stadt&diff=217734&oldid=21…
You can see (with IE7 only!) in print preview mode this situation:
* version 217734
(<http://wiki-test.genealogy.net/w/index.php?oldid=217734>) (the
original text with italic formatting) has empty pieces.
* version 217731
(<http://wiki-test.genealogy.net/w/index.php?oldid=217731>) suddenly
shows all correct.
We cannot recommand all users not to use IE7 (though we should).
Any suggestions?
Uwe (Baumbach)
U.Baumbach(a)web.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJmt+kFEbayCH8zXkRAnLIAKCFq2ck2Lq47uQWbX72n6k+11l9+wCfc5l7
rA8WyHF26yF9T3uaBoDS4R0=
=9nLx
-----END PGP SIGNATURE-----
Hello,
In several Tex-implementations, Euro-sign (€) can be created by \euro,
\EURO \texteuro or \EUR.
This isn't implemented in Mediawiki jet - but several WP-users have been
asking for it.
Could anyone please do this?
Best Regards,
Michi
--
Michael F. Schönitzer
Mail: michael(a)schoenitzer.de
Homepage: http://www.schoenitzer.de
Jabber: Schoenitzer(a)jabber.ccc.de/Home
ICQ: 294808517
Magdalenenstraße 29
80638 München
Tel: 089/152315
Hey MediaWikians,
I've been working with some MediaWiki installations for almost 2 years now and I keep learning more from looking up question, reading this list, and finding what I need to use in the code. So now I have a new question and I have looked in mailing list archives and mediawiki.org but I haven't found a definitive list.
What are the suggested maintenance tasks that should be run on a regular schedule?
I've been occasionally running rebuildall, mostly when category sorting goes a little funky. I just read Aryeh's note mentioning populateCategory being a good one, and last week someone was proclaiming the wonders of database recovery cron-jobs.
So, what wiki maintenance should be done on, say, a weekly basis for a small internal wiki?
Thanks very much!
Courtney Christensen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Aryeh Gregor <Simetrical+wikilist(a)gmail.com> wrote:
> On Mon, Feb 16, 2009 at 9:38 AM, Uwe Baumbach <U.Baumbach(a)web.de> wrote:
>> > after our upgrade to 1.14 we see at one category page:
>> >
>> > http://wiki-de.genealogy.net/Kategorie:Stiftung_Stoye/Band_42_(Genealogisch…
>> >
>> > that this cat should have 618 pages. But browsing through the pages we can see: they are only 351.
>> > This correct number is shown by our own mini extension that queries table "categorylinks"...
>
> Running maintenance/populateCategory.php --force should fix this. It
> will refresh *all* category table counts, however, not just one.
> There's currently no nice mechanism to force a category size recount,
> other than removing enough entries to get it below 200 and then
> re-adding them. There's probably a bug open for this somewhere.
Thx - this was the solution!
Uwe (Baumbach)
U.Baumbach(a)web.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJmndcFEbayCH8zXkRAs38AJ9xpEyYVA5c/QzBEQlpoLdFkSRIVACeNf8h
kFh9+nPDfXgmGB0frzRbIpc=
=3/nS
-----END PGP SIGNATURE-----
On any wiki where there's an operation restricted to logged in users,
the error message "You must be logged in .." is shown with a link to
the login form. Is there a reason (other than "not coded yet") why
this login form isn't rendered directly onto the error page, skipping
one step?
Thanks,
Erik
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate