-----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-----
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.
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,
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.
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]]
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 ]
Hi Marco, et al,
Thanks for responding. I use GoDaddy hosting, so it's a black box as to
what OS and other particulars. But I've continued digging, and finally got
it to work. Below are the details on how to make it work:
*Step 1 (Optional) - Configure GoDaddy Linux account to use PHP 5 by default
*
This can be accomplished in two ways:
a) Modify the .htaccess file in your root web folder to:
AddHandler x-httpd-php5 .php
AddHandler x-httpd-php .php4
or b)Configure via the Control Panel (takes up to 24hrs of waiting)
*Log in to your Account
Manager<http://mya.godaddy.com/default.aspx?prog_id=GoDaddy>
.
*In the *My Products* section, select *Hosting Account List*.
*Next to the hosting account you want to modify, click *Open*.
*In the *Content* section of the Hosting Control Center, click the *
Languages* icon.
*Select PHP version you'd like to set as the default.
*Click *Continue*.
*Verify the listed changes, and then click *Update*.
*Step 2 - Modify LocalSettings.php*
Look for $wgImageMagickConvertCommand, and modify its value to
"/usr/local/bin/convert"
The article I found most helpful was:
http://www.ehartwell.com/TechNotes/MediaWikiOnGoDaddy.htm
That's it. Thanks everyone.
Gerard
Message: 10
Date: Sun, 06 Jul 2008 12:32:55 +0200
From: Marco Schuster <marco(a)harddisk.is-a-geek.org>
Subject: Re: [Wikitech-l] Error with Thumbnail
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Message-ID: <48709F57.4020007(a)harddisk.is-a-geek.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Gerard C schrieb:
> "Error creating thumbnail: /usr/bin/convert: Unrecognized option
> (-thumbnail)."
>
> Any ideas? Thanks.
please run convert --version or -v; maybe you got an too-old or too-new
or totally wrong version installed. what OS do you use?
marco
enwp.org currently redirects to http://en.wikipedia.org/wiki/Main_Page
. So I guess from this that WMF has control of it.
Could we set it up as an automatic URL shortener service?
enwp.org > en.wikipedia.org
------------------------------------------
/A/Article_name > /wiki/Article_name
/AT/Article_name > /wiki/Talk:Article_name
/H/Article_name > /w/index.php?title=Article_name&action=history
/D/123/456 > /w/index.php?diff=456&oldid=123
/R/123 > /w/index.php?oldid=123
/U/Foo > /wiki/User:Foo
/UT/Foo > /wiki/User_talk:Foo
/C/Foo > /wiki/Special:Contributions/Foo
They're all the ones worth doing I can think of. Maybe also some for the logs.
They would be useful for feeds & links on microblogging things.
thanks,
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
