There seem to be more Wikimedia server problems. No sysadmins could be found
on IRC, so I'm posting here to see if someone gets the message.
We're getting the standard Wikimedia Error on all wikis with a message to
the effect of:
Request: GET http://de.wikipedia.org/, from 66.230.200.146 via
sq18.wikimedia.org (squid/2.6.STABLE12) to ()
Error: ERR_CANNOT_FORWARD, errno (11) Resource temporarily unavailable at
Thu, 21 Jun 2007 04:13:11 GMT
It's been reported on multiple squids, and at present I am completely unable
to load any page of any wiki without getting it. If a sysadmin could kindly
assist -- thank you.
--
Daniel Cannon (AmiDaniel)
http://amidaniel.com
cannon.danielc(a)gmail.com
Hi,
I am running MediaWiki 1.10 on Windows/IIS with MS SQL Server 2000, but have
a problem which may or may not be related to my unusual configuration. I am
struggling to get the Portal pages to work (pretty much everything else
works). For example, If I go to
http://en.wikipedia.org/w/index.php?title=Portal:Geography&action=edit I
see:
Pages transcluded onto the current version of this page:
...
Portal:Box-header (semi-protected)
Portal:Geography/Articles
Portal:Geography/Categories
...
However, on my wiki, if I copy the source over and navigate to the "same"
page I'll see:
Templates used on this page:
...
Template:Portal:Box-header
Template:Portal:Geography/Articles
Template:Portal:Geography/Categories
...
Any hints on what I need to twiddle with to get correct behavior?
I pause with baited breath, knowing I'm treading where I oughtn't, and
invading territories which are best left well enough alone, however, I
have a few open questions regarding the status of implementation of
CentralAuth, or as the peasants call it, "single user login":
1. What *is* the current status?
2. What are we waiting on? Technical barriers?
3. Next steps?
As usual, don't hesitate to call me nasty names and holler at me if
there's anything I can do to help.
Rob Church
Hi All,
I am trying to customise the Special:Preferences page to remove tabs and
change certain form fields. My amendments are relatively simple to achieve
but editing includes/SpecialPreferences.php. However I would rather use an
extension and keep the core code intact. I have tried using the
SpecialPageExecuteBeforePage hook, but this seems not to work as expected
(see my extension code below). The following note in the core code,
includes/SpecialPage.php, stating that the SpecialPageExecuteBeforePage hook
needs to be fixed:
# FIXME: these hooks are broken for extensions and anything else that
subclasses SpecialPage.
If this hook is not due to be fixed soon will someone please offer another
way to amend the Special:Preferences page without hacking the core code?
My extension code:
$wgHooks['SpecialPageExecuteBeforePage'][] = 'CustomUserPreferencesPage';
function CustomUserPreferencesPage($specialpage, $par, $func) {
// Check if this hook has been called from the correct page
if ($specialpage->mName == 'Preferences') {
global $IP ;
$specialpage->file($IP .
"/extensions/CustomUserPreferencesPage/templates/CustomSpecialPreferences.php")
;
}
return true ;
}
Many thanks in advance,
Matthew
MediaWiki version 1.10.0
PHP version 5.2.2
Does any record remain from which it would be even theoretically
possible to extract the actual uploaders of the images from before
mid-2002 whose file history only lists "(Automated conversion)" as the
uploader? How about those marked as uploaded by "Conversion script"
with the summary "(recovered file, missing upload log entry)"?
Or, for that matter, is there even a list of the affected files, given
that they don't show up in the upload log? (It _should_ be possible to
obtain that from the image / oldimage / filearchive tables.)
Reason I'm asking is that these images seem to be disappearing gradually
as people and bots come across them and tag them as having no source.
Not to mention that the lack of proper upload history does make them
technically GFDL violations.
--
Ilmari Karonen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
yurik(a)svn.wikimedia.org wrote:
> - static function decodeExpiry( $expiry ) {
> + static function decodeExpiry( $expiry, $timestampType = TS_MW ) {
> if ( $expiry == '' || $expiry == Block::infinity() ) {
> return Block::infinity();
> } else {
> - return wfTimestamp( TS_MW, $expiry );
> + return wfTimestamp( $timestampType, $expiry );
> }
> }
I don't really like this... it seems a bit odd to have it return a
different timestamp format than the one that is used for all internal
processing.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGdu8pwRnhpk1wk44RAl16AJwOK65mbFg1BsGOoJdRHZgTZ3q1BQCguFNa
YsJ3BhAMFX05xgVst5U9G6c=
=apff
-----END PGP SIGNATURE-----
There's a discussion going on at [[Wikipedia:Reference desk/
Computing#Wikipedia Random Article]] about how the random
article feature works. A couple people have made claims that
I find surprising, such as that we "take 1000 articles every
few minutes and then chose a random one from it", or that the
function "only shows articles up to a certain size", or that
instead of choosing a random article it now chooses "a random
subject (and then a random article in that framework)".
Is anything like this going on? Are we no longer simply taking
a a random selection from the entirety of the page table?
(Feel free to answer at RD/C, or here.)
On 15/06/07, Monahon, Peter B. <Peter.Monahon(a)uspto.gov> wrote:
> > Cary wrote: ... monobook is getting old
> > ... and it's marginally relevant to
> > Wikimedia Commons ... so similar to
> > many of the projects that it's not ...
> > easy to tell that you've moved from one
> > wiki to another ... But not all of us are
> > good at designing skins ... how do we
> > change it while upsetting the least
> > amount of people? I propose ... a
> > contest to come up with a new, more
> > exciting monobook.css ... -C
>
> Peter Blaise responds: I know this is a "commons" discussion list, so
> my contribution in this thread is specious, but where else should we
> discuss this ... and you started it! So...
>
> Although I agree with much of your observations, I disagree with your
> conclusions.
>
> I suggest that we instead design a new MediaWiki front end to allow the
> look and feel and function of any MediaWiki element to be customized
> USING MediaWiki directly through the same interface everyone else uses.
>
> ... instead of having to search for and find and hand edit *.css, *.js,
> *.ini, *.conf, *.php and so on files. I say, do all that programming
> ONCE, and do it INSIDE a new version of the MediaWiki distribution
> program. Then let sysops/admins tweak everything to their heart's
> content from within the MediaWiki program without having to become
> OS/MySQL/PHP/CSS/and-so-on programming nerds (with NO documentation
> skills, apparently?!?). You want the commons blue? Make it blue from
> WITHIN MediaWiki, rather than hand coding a new *.css!
>
> I hope my 2 cents catches someone's imagination. I'm not up to either
> task - customizing MediaWiki using the current resources as a one-off
> design, nor programming such a modern interface enhancement tool as an
> upgrade included into MediaWiki. I just want one. And the people I'm
> trying to get to adopt MediaWiki would really appreciate it.
>
> That said, keeping everything as "Wikipedia" as possible makes training
> and experience with one transferable to any other. "Have you seen
> Wikipedia?" "Yes." "Well, then, THIS is the exactly same. Dive in and
> enjoy!" Works for me.
>
> In other words, I'm reframing the challenge: rather than adding yet
> another one-off skin, why not design a "skin designer" and incorporate
> it right into MediaWiki?
>
> ;-) -- Peter Blaise
>
>
> _______________________________________________
> Commons-l mailing list
> Commons-l(a)lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/commons-l
>
This idea is very interesting, I can already imagine what this could
look like - I am forwarding this to the wikitech-l mailing list so
that the people involved in that can also add their ideas. No doubt
this would require some nifty JavaScript though.
--
Robert
http://roberthl.wikitest.co.uk/
Hey,
I've put together an extension for rating articles if anyone is
interested. It's just a first version and hasn't been tested much, but
the details can be found here:
http://www.wikihow.com/WikiHow:RateArticle-Extension
You can see an example here on our development server:
http://wiki16.wikidiy.com/Get-a-Better-Deal-on-a-Home-Loan
(username password wikihow / wikihow2006) - scroll down to the bottom
of the page for the checkmarks.
I'd appreciate feedback if anyone has any. If someone wants to add
this to extensions in svn, that'd be great.
Thanks,
Travis