This functionality would suit well in Extension:Maintenance: The Maintenance extension adds a special page for running various maintenance scripts. The user needs the 'maintenance' right to access the special page[1].
Would it be possible/make sense to merge them, and add some configuration variables to enable the more sysadmin oriented (maintenance scripts) and super user oriented features (update slow special pages)? I think it would...
Cheers! Siebrand
[1] http://www.mediawiki.org/wiki/Extension:Maintenance
-----Oorspronkelijk bericht-----
Van: mediawiki-cvs-bounces(a)lists.wikimedia.org [mailto:mediawiki-cvs-bounces@lists.wikimedia.org] Namens ashley(a)mayflower.knams.wikimedia.org
Verzonden: zondag 10 augustus 2008 21:00
Aan: mediawiki-cvs(a)lists.wikimedia.org
Onderwerp: [MediaWiki-CVS] SVN: [39078] trunk/extensions
Revision: 39078
Author: ashley
Date: 2008-08-10 19:00:01 +0000 (Sun, 10 Aug 2008)
Log Message:
-----------
RefreshSpecial extension from Wikia - allows privileged users to refresh special pages through Special:RefreshSpecial when $wgMiserMode is set to true.
Original code by Bartek ?\197?\129api?\197?\132ski, some tweaks & fixes + Finnish i18n by me.
Added Paths:
-----------
trunk/extensions/RefreshSpecial/
trunk/extensions/RefreshSpecial/RefreshSpecial.body.php
trunk/extensions/RefreshSpecial/RefreshSpecial.i18n.php
trunk/extensions/RefreshSpecial/RefreshSpecial.php
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
aaron(a)svn.wikimedia.org wrote:
> Filecache should check &useskin. This should be backported.
[snip]
> Modified: trunk/phase3/includes/Article.php
> && ($wgUser->isAnon())
> && (!$wgUser->getNewtalk())
> && ($this->mTitle->getNamespace() != NS_SPECIAL )
> + && (!isset($useskin))
> && (empty( $action ) || $action == 'view')
> && (!isset($oldid))
> && (!isset($diff))
Ewww, scary old code. :D
Probably this should be changed from checking every parameter we can
think of that might show up to just checking if we're using the
canonical view URL -- the same logic that currently controls whether
we're going to tell Squid to cache the page should control use of the
file cache.
That would be more future-proof and proof against funky extension
parameters.
- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkifQdEACgkQwRnhpk1wk44VKACfQ7ZpD8nPRgCofHBeWb7cL5YY
i6IAniw45oJgYEENuj7Jw2tE30aczGI/
=1mUr
-----END PGP SIGNATURE-----
I recently noticed that the Persian translation for 'whatlinkshere-barrow'
was removed from the language file because it was added to the ignore list
[1]. I don't think this is okay. The direction of barrow is different in RTL
languages, and as far as I know this hasn't been automatically taken care of
inside the code (correct me if I'm wrong). So, RTL lanagues do need to
translate the barrow. Before letting this be re-added and re-removed over
and over again, I thought this debate should be solved for once. Please
comment on this. If there is no objection, I'm going to readd that message
in RTL languages.
Please bear in mind that, RTL languages are supposed to be used in RTL
environment. If you test on English Wikipedia (or a similar one) and just
put uselang=fa in the URL, the "different" direction of barrow may not make
sense to you, and you may think the barrow should be in the same direction
for all languages. But if you try Persian/Arabic/Hebrew/... wikis, you'll
notice the required change.
Best,
Hojjat (aka Huji)
[1]
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/languages/messages/M…
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
shinjiman(a)svn.wikimedia.org wrote:
> * Added $wgDisableTitleConversion to disabling the conversion for all
> pages on the wiki (this one is useful for some wikis that do not need
> the title conversion for the entire wiki like Wiktionary)
As a general note, it's easier and more consistent to conceptualize
"positive" configuration settings.
That is, these is easier to understand:
$wgEnableTitleConversion = true;
$wgEnableTitleConversion = false;
than these:
$wgDisableTitleConversion = false;
$wgDisableTitleConversion = true;
We switched from $wgDisableUploads to $wgEnableUploads a few versions
ago and I think it's definitely easier to understand. :)
I'd recommend switching these new ones too.
- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkicsGkACgkQwRnhpk1wk478oACeJzb2r78p4chjtEngRqhgocbi
kbQAoIpB54h3gzbr351Dpp5NZ09F9Xth
=D0KV
-----END PGP SIGNATURE-----
---- Alexandre Emsenhuber <alex.emsenhuber(a)bluewin.ch> schrijft:
> On the French Wikipedia, Copyvio edits are stored in a /copyvio subpage (and
> deleted of course). The procedure is:
> 1) Delete the page
> 2) Restore copyvio edits
> 3) Move the page to Page/copyvio
> 4) Delete this subpage
> 5) Restore non copyvio edits
> 6) Undo the last edit (the redirect made while renaming the page)
>
Why not just use Oversight or rev_deleted (can't remember whether the latter has finally gone live yet) here? This whole thing is nothing more than a hack to delete individual revisions, which is exactly what Oversight and rev_deleted were designed for.
Roan Kattouw (Catrope)
---- Alexandre Emsenhuber <alex.emsenhuber(a)bluewin.ch> schrijft:
> On the French Wikipedia, Copyvio edits are stored in a /copyvio subpage (and
> deleted of course). The procedure is:
> 1) Delete the page
> 2) Restore copyvio edits
> 3) Move the page to Page/copyvio
> 4) Delete this subpage
> 5) Restore non copyvio edits
> 6) Undo the last edit (the redirect made while renaming the page)
>
Why not just use Oversight or rev_deleted (don't remember whether that's finally gone into core yet) here? The sequence above is nothing more than a hack to delete individual revisions, which Oversight and rev_deleted support properly.
Roan Kattouw (Catrope)
I have a parser function that takes this:
{{#r8:http://www.holygrail.com Click Here To Search For The Grail!}}
and turns it into this link:
Click Here To Search For The Grail! <http://www.holygrail.com/> -
However, what it won't do is make an internal link within the wiki.
For example this:
> {{#r8:Main_Page Main Page}}
>
turns into this:
[Main_Page Main Page ] -
>
Any idea how to fix internal pages? Code shown below:
$wgExtensionFunctions[] = 'efExampleParserFunction_Setup';
> # Add a hook to initialise the magic word
> $wgHooks['LanguageGetMagic'][] = 'efExampleParserFunction_Magic';
>
> function efExampleParserFunction_Setup() {
> global $wgParser;
> # Set a function hook associating the "example" magic word with our
> function
> $wgParser->setFunctionHook( 'r8', 'efExampleParserFunction_Render'
> );
> }
>
> function efExampleParserFunction_Magic( &$magicWords, $langCode ) {
> # Add the magic word
> # The first array element is case sensitive, in this case it is not
> case sensitive
> # All remaining elements are synonyms for our parser function
> $magicWords['r8'] = array( 0, 'r8' );
> # unless we return true, other parser functions extensions won't
> get loaded.
> return true;
> }
>
> function efExampleParserFunction_Render( &$parser, $param1 = '', $param2 =
> '' ) {
> # The parser function itself
> # The input parameters are wikitext with templates expanded
> # The output should be wikitext too
> return "[$param1 $param2] - ";
> }
>
>
--
IU Medical School
410 West 10th Street, Suite 5000 Indianapolis, IN 46202-5122
United States of America
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It's tech hiring season again at Wikimedia!
http://wikimediafoundation.org/wiki/Job_openings/Software_Developer_/_IT_Su…http://wikimediafoundation.org/wiki/Job_openings/Software_Developerhttp://wikimediafoundation.org/wiki/Job_openings/System_Administrator
We're looking for at least some people to be here at our San Francisco
office, but remote development and system administration is also
available (especially making sure we've got stronger timezone coverage
for our sysadmins).
So all you out there who've been toiling in secret on your wikis and
websites o' doom, but always secretly (or not so secretly) wanted to
work for Wikipedia -- send yourself in to jobs at wikimedia.org.
- -- brion vibber (brion @ wikimedia.org)
CTO, Wikimedia Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkibm9UACgkQwRnhpk1wk46OkwCdFNFNbPHnr659IntA9/3l0Phh
l7YAn2fT5uEes6AvOVVhUg06TgqZSxAk
=Jlti
-----END PGP SIGNATURE-----
Hello Question regarding the downloading of the english xml dumps of
Wikipedia for archival purposes its 4gigs which is alot to download ever
time new dumps are released so any way that diff patches or xdelta patches
will ever be released along side the full dumps so I only have to download
those patches containing only the changes rather then 4gigs of more data?
(Imagine all the bandwidth saved!)?
Link to xdelta here http://xdelta.org/
and diff/patch are located in all modern unix based distros (linux/bsd and
such)