Wikitech-l July 2008

wikitech-l@lists.wikimedia.org

68 participants
95 discussions

My Wiki is too slow
by Edgar A. Mendieta 11 Jul '08

11 Jul '08

Hi, i have mediawiki last version, installed on a Linux Red Hat box, but when i try to access the wiki interface this is too slow. How can i do to fix this? Thanks.

1 0

On accesskeys (re r37524 in FlaggedRevs)
by Brion Vibber 10 Jul '08

10 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 aaron(a)svn.wikimedia.org wrote: > Add form accesskey (bug 14783) > $form .= Xml::submitButton( wfMsgHtml('revreview-submit'), > - array('id' => 'mw-submitbutton','class' => 'fr-comment-box')+$toggle); > + array('id' => 'mw-submitbutton','class' => 'fr-comment-box','accesskey' => 's')+$toggle ); Where possible, avoid hardcoding accesskeys this way. Within the core software we make them localizable, so they can be changed via MediaWiki: messages, and pair them with tooltip messages. You can fetch the appropriate accesskey and tooltip title attribute via $skin->tooltipAndAccesskey('whatever'). Note though that this function is currently dreadful, returning raw HTML fragments. I half-did some improvements on a patch to bug 14757 for cleaning this up, which it would be great if some enterprising lad finished resolving: https://bugzilla.wikimedia.org/show_bug.cgi?id=14757 - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh2gm4ACgkQwRnhpk1wk44WOQCdGl0iLZn8W7n3urwKEICUOsBY eRYAoL8I8EZD2SBC9Pa3uE9Rt+INpzzD =uOZV -----END PGP SIGNATURE-----

1 0

PagesInNamespace Magic Word not working on MediaWiki.org
by Christensen, Courtney 10 Jul '08

10 Jul '08

http://www.mediawiki.org/wiki/Help:Magic_words It's trying to find a template instead of the Magic Word. I wasn't sure how I should let someone know. -Courtney

2 2

Declaring code slush for 1.13 branching
by Brion Vibber 09 Jul '08

09 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm declaring a "code slush" on MediaWiki trunk for the next week or so, so we can concentrate on cleaning things up for making a 1.13 release branch, timed oh-so-delicately to approximately coincide with the Wikimania conference (coming up July 17-19). I'd like to ask that new experimental features and giant refactorings that aren't vital fixes be pushed back until after the branching; this'll give us all a chance to make sure the release goes smoothly and that changes that are made get the attention they deserve. It's a-gonna be awesome! :D - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh1ENYACgkQwRnhpk1wk44FqQCeMwfrfIlqmxVmwA6RmaxV4tdV jlcAn3gkN5RgReCD8KFP47Sc52FgyC7J =CP90 -----END PGP SIGNATURE-----

1 0

Dumps stuck?
by Russell Blau 09 Jul '08

09 Jul '08

http://download.wikimedia.org/backup-index.html hasn't updated since 01 July. Are the dumps dead, or stuck, or is the webpage just not getting updated?

3 2

Re: [Wikitech-l] Removal of RTL CSS workarounds
by MinuteElectron 09 Jul '08

09 Jul '08

rotem(a)svn.wikimedia.org wrote: > Revision: 37377 > Author: rotem > Date: 2008-07-09 09:28:10 +0000 (Wed, 09 Jul 2008) > > Log Message: > ----------- > Removing the ordered list workaround for Firefox in RTL: Firefox 3, released a few weeks ago, fixes this issue. The workaround causes problems with the numbering in Firefox. I think that it is better to remove this workaround because of its problems. > > The unordered list workaround does not seem to cause problems; it should stay until most Firefox users upgrade to Firefox 3. If it causes no problems why not just leave it indefinitely, I see no obvious reason to remove it since it will obviously benefit at least some users since not all will be able to upgrade to Firefox 3 (it is not compatible with Windows 9x for one, which is still in use by quite a few people). MinuteElectron.

1 0

how to print php output for debugging
by gbtkjd dgjksbg 09 Jul '08

09 Jul '08

Hi Everyone !! I am a newbie currently installing mediawiki. I had a basic question: How to print the output (of php code like print array) while writing any extension so that I can know when I am making mistakes in code? Thanks,

2 1

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [37249] trunk/phase3/includes/specials/SpecialVersion.php
by Simetrical 07 Jul '08

07 Jul '08

On Mon, Jul 7, 2008 at 8:55 AM, <demon(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > Cache the SVN version so we're not doing a filesystem read every time Special:Version (or APIQuerySiteInfo) asks for it. This appears to mean that the version will be inaccurate for up to an hour after svn upping. This is a regression which could be potentially significant; it's fairly important to know the exact revision if an error is spotted right after an svn up. Is there any reason to think that the benefit is worth it? Operating systems do have disk caches, which are a lot faster than a memcached call if they get hit, and we're only talking about a vanishingly small minority of page views here anyway. I would suggest this be backed out unless this is causing a demonstrable performance problem.

2 1

Mailman upgrade?
by Petr Kadlec 07 Jul '08

07 Jul '08

Hi! I see we run Mailman version 2.1.9 on lists.wikimedia.org. Would it be possible to upgrade to some more recent version? The Czech translation of the mailman interface deployed on the web is completely terrible (problems ranging from typos and untranslated parts to incomprehensible sentences and mismatched month names (!)), and it seems the current translation is (at least) much better. -- [[cs:User:Mormegil | Petr Kadlec]]

1 0

Schema change : category redirects
by Nicolas Dumazet 07 Jul '08

07 Jul '08

Hello ! Following the latest thread on this [0] (and the older [1]) about implementation details for my GsoC project, aiming at adding category redirects / moves, I would need more input on the DB schema change that was being discussed, knowing that : * We expect category moves to be reversible * The only "feature" we are in fact adding is category redirects * I am considering this schema change as a good opportunity to fix bug #13579 [Categorylinks table should use category ID rather than category name in cl_to field] (please comment overthere if you see specific issues for that change) While thinking about that schema change, I considered the following use cases, considering categories A B and C : 1)Move existing A to empty B. 2)A and B contain pages : Redirect A to B. 3)A redirects to B : make A redirect to C 4)A redirects to B : undo the redirect, make A and B plain categories 5)A redirects to B : invert the redirect, make B redirect to A 6)On page edits, alter the category_links table 7)Listing pages that belong to a specific category Use case #1 is fairly easy to implement if cl_to points to a cat_id : you only have to rename the cat_title of the corresponding category table row, leaving the cat_id unchanged, and that's in fact the reason for switching cl_to' type == Original idea : add a cl_final field == The original idea, from the previous threads, was to change the category_links table : instead of only having the single cl_to pointing to the cat_id of the included category, add a cl_final integer field, also pointing to a cat_id, but this time the cat_id of the final category (see [2] ) : in other words, when category A redirects to category B, if a page includes category A, its category_links row' cl_to will point to category A' cat_id, and its cl_final will point to category B' cat_id. * Use cases #2, #3, and #4 : Expensive when A is a big category ! For each category_links row where cl_to = catA_cat_id, update cl_final, to respectively, B' cat_id, C' cat_id, and A' cat_id. * Use case #5 : Very expensive, for large A and B: you have to update every A and B category_links. * Use case #6 : When adding a category to a page, you have to fetch its corresponding cat_id for cl_to, (fairly easy), but you also have to fetch the right cl_final. You have to know first, if the category is a redirect. And if I'm right, with that schema, the only ways to tell this actually, are to retrieve the corresponding page_is_redirect in the page table, or to check for an entry in the redirect table. I believe that this forces us to compute a page-redirect join on page_id + a redirect-category join on page_title for each category title (see [3] ). If there's no results for that query, (can be caused if {1} the category page does not exist, {2} the category page exist but is not a redirect), the category is not a redirect, and else it returns us the cat_id for cl_final. * Use case #7 : Easy. SELECT ... FROM category_links WHERE cl_final = ## == But what about adding a cat_final field instead ? == When A redirects to B, all A' category_links entries will share the same cl_final field. Being quite unexperienced, and very naive, I may miss something important here... but I think that it makes much more sense to add that shared value to the category table, instead of duplicating it times the number of pages included in the category. I'm saying that instead of adding a cl_final field to the category_links table, we should perhaps add a cat_final field to the category table pointing to the final category it belongs to (see [4] ). * Use cases #2 #3 and #4 : Trivial. Change cat_final in one category table row. * Use case #5 : Damn. Tricky. Alter TWO category table rows :p * Use case #6 : Easy, fetch the corresponding cat_id to fill cl_to. * Use case #7 : The most expensive operation for this proposal. You have to join category_links and category (hopefully on cat_id) to retrieve what was cl_final in the first proposition, and select ... where cat_final = ### Evaluating the cost of a query is clearly one of the hardest things to do for that young me, and I fail to estimate the cost of that last query. How expensive is it compared to its use frequency ? Being apparently the most expensive part for this proposed change, the answer of that question will probably state how valid was my second approach ... I need your help to finalize the schema change needed to implement category redirects. I may also miss a third solution, even better, or have forgiven some important details while considering what has to be done : let me know :) [0] http://lists.wikimedia.org/pipermail/wikitech-l/2008-June/038495.html [1] http://lists.wikimedia.org/pipermail/wikitech-l/2008-April/thread.html#37218 [2] http://commons.wikimedia.org/wiki/Image:Mediawiki_schema_change_for_categor… [3] http://commons.wikimedia.org/wiki/Image:Mediawiki_use_case_category_redirec… [4] http://commons.wikimedia.org/wiki/Image:Mediawiki_schema_change_for_categor… -- Nicolas Dumazet — NicDumZ [ nIk.d̪ymz ]

3 8

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l July 2008