Hi Everyone,
Next week we're going to switch the back end system that hosts thumbnail[1]
images. We have been using
ms5<http://ganglia.wikimedia.org/latest/?r=day&cs=&ce=&m=&c=Miscellaneous+pmtpa…>(a
Sun server running linux) to serve all thumbnails. We are switching
to Openstack
Swift <http://wikitech.wikimedia.org/view/Swift>, a clustered object
store. Though we have done testing and expect no problems, I want to
publicize the change so that if issues do appear, they are quickly directed
to the right place.
Here's the schedule:
* Monday Feb 6th: move 0.4% of all thumbnail traffic from ms5 to swift.
Only thumbnails with "/thumb/a/a2/"[2] in the URL will be affected.
* Tuesday: move 12.5% of traffic - thumbnails with "/thumb/a/" or
"/thumb/b/" will be affected
* Wednesday: move 50% of traffic - thumbnails with "/thumb/(a-f or 0 or
1)/" will be affected
* Thundlay: move 100% of traffic - all thumbnails will be served from Swift
Potential symptoms that might be related to this change on Monday:
* a thumbnail image with /a/a2/ simply fails to load
** try changing the number preceding 'px' to generate a different size
image[3]
* you delete an image and the thumbnail is still available
** try purging the cache[4] and see if that makes it go away
** try changing the number preceding 'px' and see what happens
* you move an image to a new name and it's still available at the old name,
when either the new or old name has /a/a2/ in the URL
** please provide full URLs for both the new and old names
If any of these things happen, or if something else odd happens with images
or thumbnails and you feel it might be related, please join #wikimedia-tech
in IRC and ping me (maplebed) or Aaron (AaronSchulz). If neither of us are
available or you would prefer to just leave us a message, add a note to
https://www.mediawiki.org/wiki/SwiftMedia/Issues. :) If things are
severely broken, you can ask someone in the #wikimedia-tech to page me.
Thanks for your help!
-ben
[1] In case you don't know what I mean by thumbnail images, I'm talking
about all URLs that start http://upload.wikimedia.org/ and have /thumb/ in
the path. When an image is uploaded to a wiki (or commons), Mediawiki
automatically generates scaled versions of the image. These are what I
call 'thumbnails'. Nearly every time an image is used in a wiki page it is
actually a thumbnail being used. Try going to any wiki page with an image,
right click on the image, and choose 'view image'. You'll get something
like
http://upload.wikimedia.org/wikipedia/commons/thumb/4/45/Liberty_Head_Nicke…
as the URL (this was taken from enwiki's featured article today)
[2] For example,
http://upload.wikimedia.org/wikipedia/commons*/thumb/a/a2/*Little_kitten_.j…
[6]
[3] For example,
http://upload.wikimedia.org/wikipedia/commons/thumb/a/a2/Little_kitten_.jpg/
*799px*-Little_kitten_.jpg
[4] Find the URL for the main image file (rearrange the URL to find the
original image - /wikipedia/commons -> commons.wikipedia.org) and add
"?action=purge" to the end of the URL (eg
http://commons.wikimedia.org/wiki/File:Little_kitten_.jpg?action=purge
[5] Image in the public domain
[6] cc-by 3.0, Alexanderwdark<http://commons.wikimedia.org/w/index.php?title=User:Alexanderwdark&action=e…>
Hi,
It's likely many of you have heard of or even participated in the Picture
of the Year contest. Every year, the Wikimedia community votes for a
picture of the year from the pool of images promoted to featured picture
status in the previous year on the Wikimedia Commons. This typically occurs
in late spring; last year's contest took place in May and was a huge
success.
This year, we're looking to improve the operation of the contest. In the
past, with the notable exception of a community-developed JavaScript
interface, the galleries, voting, and counting has been done manually. This
hurts the efficiency of the contest significantly, as these somewhat
tedious tasks will be repeated year after year.
It would be really wonderful if we could get a couple of developers to put
an extension together. I've searched fairly extensively for something that
would be sufficient for our needs and I've come to the conclusion that
building such an extension would be the most future-proof and efficient way
to accomplish the task.
I considered using a Toolserver-based system, but authenticating users in a
SecurePoll-like way on a large scale would be difficult. (It's possible
that some parts of the SecurePoll code could be used for this.) The
functionality needs for the extension include:
*a front-end voting gallery where users can vote while logged in with a SUL
account on Commons
*an administration panel to manage the front-end galleries, including
account verification requirements, dates, and statistics
*a user right for committee members to access the interface
This is certainly a "project," but it could be used for every POTY contest,
perhaps some other contests, and it doesn't have to be elaborate. However,
as I said, it would be really great if we could get just a couple people
who have some experience developing MediaWiki extensions to help program
this in time for this year's contest.
If anyone is interested in helping out or would like some more information,
please contact me as soon as possible - anything helps!
Thanks,
User:Mono
--
Sent from my iPad
Is there any hook for extensions that is called after the article is
loaded and the parser functions in the article are run and with which I
can modify the sitenotice or the content of the article?
Hi all,
I discussed with Platonides and the Suhosin author an automatic MediaWiki run-time adaption of
$wgResourceLoaderMaxQueryLength [1-3].
Currently, Suhosin and the setting of
suhosin.get.max_value_length is detected and signalled _only_ during the MW installation.
However, if the system (Suhosin) settings are changed after the MW installation,
it requires knowledge about this fact and and it requires to adapt
the setting manually in any Mediawiki installation on this server.
I now suggest to add something to the core which can adapt the
$wgResourceLoaderMaxQueryLength also during run-time but still in the limits given by a previous
$wgResourceLoaderMaxQueryLength in LocalSettings.
// Design idea
//
// In LocalSettings / DefaultSettings
// example of a user value from e.g. LocalSettings
// this value may be cropped at run-time
// to suhosin.get.max_value_length (if Suhosin extension is active)
$wgResourceLoaderMaxQueryLength = 5212;
/* In MW core after LocalSettings */
if ( extension_installed( "suhosin" ) && ini_get( "suhosin.get.max_value_length" ) ) {
$wgResourceLoaderMaxQueryLength = min( $wgResourceLoaderMaxQueryLength, ini_get( "suhosin.get.max_value_length" ) );
}
[1] https://www.mediawiki.org/wiki/Manual:$wgResourceLoaderMaxQueryLength
[2] https://www.mediawiki.org/wiki/Manual:Suhosin
[3] https://github.com/stefanesser/suhosin/issues/4#issuecomment-3816249
Hi folks,
I am new to this list but I have spent more than 5 years on Hungarian
Wikipedia.
Please visit
https://hu.wikipedia.org/w/api.php?action=query&list=blocks&bklimit=5000&bk…
scroll down to the end. There are a lot of blocks without any visible
admin. All of them have
by="" byid="0" reason="Auto-added for persistent vandalism; possible open
proxy."
What does this mean? Was it perhaps done by developers?
Is this specific for 2005 or shall we still expect such blocks?
--
Bináris
