Wikitech-l April 2009

wikitech-l@lists.wikimedia.org

91 participants
73 discussions

Review patch for Oracle SS database abstraction
by freakolowsky 20 Apr '09

20 Apr '09

https://bugzilla.wikimedia.org/show_bug.cgi?id=18492 Could someone with DB and possibly Oracle knowlage take a minute to review this patch. I'll try to supply database creation script ASAP (my testing DB server took a detour trough never never land, will post it when i restore from backup). k10xbye

1 0

Re: [Wikitech-l] [OpenID] OpenID MediaWiki Extension v.0.8.4.1 - Identity Providers UI
by Sergey Chernyshev 20 Apr '09

20 Apr '09

Unfortunately, it might be quite hard for MediaWiki admins to set up SSL comparing to what they do to setup MediaWiki or it's extensions. Looks like XRDS is "easier" approach to implement. Sergey On Sun, Apr 19, 2009 at 3:46 PM, Peter Williams <pwilliams(a)rapattoni.com>wrote: > This could be interesting of itself in the uci spirit of openid. > > One can use yahoos willingess to rely without warning on a https realm as > an authentication scheme. Yahoo implies that the https cert on an https > realm is "valid" (wrt its trust list, its handling of crls and arls). A > reputation service can now crawl which sites yahoo so rates, and publish a > meta reliance signal (by updating its ocsp database for example). Those rp > doing discovery on smaller ops might configure their ssl client engines to > use that ocsp source, when qualifying the original yahoo rp (now acting as > an asserting or attribute authority/agent of the dataowner (ie the user) ). > > ________________________________ > From: Allen Tom <atom(a)yahoo-inc.com> > Sent: Sunday, April 19, 2009 12:34 PM > To: Sergey Chernyshev <sergey.chernyshev(a)gmail.com> > Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>; > general(a)openid.net <general(a)openid.net> > Subject: Re: [OpenID] OpenID MediaWiki Extension v.0.8.4.1 - Identity > Providers UI > > Hi Sergey, > > The Yahoo OpenID Provider will display a warning to the user if the RP's > OpenID endpoints are not discoverable. > > Warning: This website has not confirmed its identity with Yahoo! and might > be fraudulent. Do not share any personal information with this website > unless you are certain it is legitimate. > > The best documentation for fixing this issue is here: > http://blog.nerdbank.net/2008/06/why-yahoo-says-your-openid-site.html > > The AOL Sign-in form fails if the user just clicks the Login Button without > entering their AOL ScreenName. You might want to disable the button until > after the user types in their ScreenName. This will only be an issue until > AOL upgrades their OpenID Provider from OpenID 1.1 to OpenID 2.0. Once they > have OpenID 2.0 support, you'll be able to handle AOL logins identically to > Google and Yahoo. > > Good job! > Allen > > > Sergey Chernyshev wrote: > Hi, > > I'm done with initial implementation of Identity Providers UI for OpenID > MediaWiki Extension. > > Extension now shows a user-friendly (although my design skills are far from > perfect) form where they can pick from a list of OpenID providers (generic > OpenID URL form is still default). > > You can see it in action here: > http://www.mediawikiwidgets.org/Special:OpenIDLogin > http://www.techpresentations.org/Special:OpenIDLogin (without icons - I'll > enable them later) > > After some discussions and concerns here on the list, I implemented it in > the way that provider logos don't show up by default and if you would like > to show them on your site, you have to add: > > $wgOpenIDShowProviderIcons = true; > > to your LocalSettings.php > > Hope you like it, but I'm still open to suggestions about improving the > interface so you all finally install it on your wikis ;) > > Thank you, > > Sergey > > > -- > Sergey Chernyshev > http://www.sergeychernyshev.com/ > > > > ________________________________ > > _______________________________________________ > general mailing list > general(a)openid.net<mailto:general@openid.net> > http://openid.net/mailman/listinfo/general > > >

1 0

Bugzilla Weekly Report
by reporter＠isidore.wikimedia.org 20 Apr '09

20 Apr '09

MediaWiki Bugzilla Report for April 13, 2009 - April 20, 2009 Status changes this week Bugs NEW : 137 Bugs ASSIGNED : 8 Bugs REOPENED : 16 Bugs RESOLVED : 65 Total bugs still open: 3577 Resolutions for the week: Bugs marked FIXED : 40 Bugs marked REMIND : 0 Bugs marked INVALID : 6 Bugs marked DUPLICATE : 6 Bugs marked WONTFIX : 8 Bugs marked WORKSFORME : 2 Bugs marked LATER : 3 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Site requests 13 Page rendering 6 CodeReview 4 General/Unknown 3 CentralAuth 3 New Bugs Per Product MediaWiki 29 Wikimedia 18 MediaWiki extensions 15 Top 5 Bug Resolvers rhalsell [AT] wikimedia.org 9 innocentkiller [AT] gmail.com 8 agarrett [AT] wikimedia.org 5 herd [AT] goldrush.com 5 siebrand [AT] wikipedia.be 4

1 0

Re: [Wikitech-l] [OpenID] OpenID MediaWiki Extension v.0.8.4.1 - Identity Providers UI
by Sergey Chernyshev 20 Apr '09

20 Apr '09

On Sun, Apr 19, 2009 at 3:34 PM, Allen Tom <atom(a)yahoo-inc.com> wrote: > Hi Sergey, > > The Yahoo OpenID Provider will display a warning to the user if the RP's > OpenID endpoints are not discoverable. > > Warning: This website has not confirmed its identity with Yahoo! and might > be fraudulent. Do not share any personal information with this website > unless you are certain it is legitimate. > > The best documentation for fixing this issue is here: > http://blog.nerdbank.net/2008/06/why-yahoo-says-your-openid-site.html > Thanks, Tom, I've created a bug in Bugzilla for this: https://bugzilla.wikimedia.org/show_bug.cgi?id=18527 The AOL Sign-in form fails if the user just clicks the Login Button without > entering their AOL ScreenName. You might want to disable the button until > after the user types in their ScreenName. This will only be an issue until > AOL upgrades their OpenID Provider from OpenID 1.1 to OpenID 2.0. Once they > have OpenID 2.0 support, you'll be able to handle AOL logins identically to > Google and Yahoo. > It's probably a good idea not to have a button enabled for any of the providers - created a bug for this one as well: https://bugzilla.wikimedia.org/show_bug.cgi?id=18528 Good job! > Allen > Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/

1 0

OpenID MediaWiki Extension v.0.8.4.1 - Identity Providers UI
by Sergey Chernyshev 20 Apr '09

20 Apr '09

Hi, I'm done with initial implementation of Identity Providers UI for OpenID MediaWiki Extension. Extension now shows a user-friendly (although my design skills are far from perfect) form where they can pick from a list of OpenID providers (generic OpenID URL form is still default). You can see it in action here: http://www.mediawikiwidgets.org/Special:OpenIDLogin http://www.techpresentations.org/Special:OpenIDLogin (without icons - I'll enable them later) After some discussions and concerns here on the list, I implemented it in the way that provider logos don't show up by default and if you would like to show them on your site, you have to add: $wgOpenIDShowProviderIcons = true; to your LocalSettings.php Hope you like it, but I'm still open to suggestions about improving the interface so you all finally install it on your wikis ;) Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/

3 5

More Skin & JS cleanup thinking...
by Michael Dale 18 Apr '09

18 Apr '09

So I was thinking instead of just packaging in jQuery I should package in / move the entire mv_embed folder into the skins directory .. it does not make sense to maintain two branches reinventing what mv_embed.js provides in the process of refactoring other core mediaWiki javascript. We will have to do something like that eventually anyway if we want to start including things like the add_media_wizard, firefoog & ajax copyByUrl status upload helpers, the Kaltura Sequencer etc. If you peek at the add_media_wizard code (which provides the firefogg upload helper) you can see its using mv_embed to manage its entry point into the interface libraries. This will also pave the way for video page includes to be <video> tags that get rewriten by mv_embed supporting firefox 3.5 javascript disabled users while retaining fall-backs and a html interface player for people with javascript turned on. Mv_embed originally was a library for embedding video but now has morphed into a library for "embedding javascript interfaces". In essence this lays the groundwork for a more mash-able future since mediaWIki interfaces will be "embeddable" into other contexts just like the remote embedding of the video playback interface works. (ie opencongress embed metavid videos with their own skin / interface: http://www.opencongress.org/person/videos/400237_barbara_lee ) The vast majority of "video specific" code has already been factored out of mv_embed into libEmbedVideo libraries and the rest should be forthcoming. (reducing core mv_embed size to something pretty minimal) The scriptLoader approach has enabled the js code to become pretty modular so it should never result in including lots of js that you don't need. == An overview of what core functionality mv_embed supports / stuff we don't want to maintain in two places: * the javascript version of wfGetMsg called gM (in mv_embed) .. this function is simple right now but will get a bit more complicated as we add more advanced language msg support. * the mvJsLoader.doLoad helper function that is integrated with script loader so you can run doLoad('className', function(){ //stuff to run now that className is available } ... useful for dynamic script includes & it works well with front-loading libraries you know you will need. For example if your on a page with a video we can send the necessary libraries for video interface in the master packaged scriptLoader request and when the doLoad function is called it will skip the remote request to get those libs and jump to code it knows it can execute. But if you hit a video from a different path in the interface where we don't know if you would need the video lib (ie add_media_wizard could be used just for grabbing an image instead of a video clip) ... then you load the library on demand. * some mediaWiki convenience functions not available in jQuery core like: do_api_req that lets you contextually get mediaWiki api data given your context. (ie a add_media_wizard embed in a remote mediaWiki instance can transparently hit the commons api via json callback while if your on commons hit the api via ajax request.) * other convenient function like js_log, js_error, parseURI etc. * some patches to jQuery plugins that have not made their way upstream. == Down sides == * Ideally we want to keep mv_embed "stand alone" support this involves a minor bit of trickery in the script server to detect if its in mediaWIki context or a stand alone package. If stand alone mode we provide logical entry points for other CMS's or static usage to make use of the code embedding helper code. Static includes of mv_embed.js (without the script server & localization) should continue to work fine. * this will bring a fairly large set of javascript into the distribution branch not all of which is "stable" but un-stable parts won't be accessible via the interface. (all the js is already on the live site under the extensions directory just not evoked) == Way forward == Since mv_embed is already pretty smart about paths and context this is a really simple change technically involving renaming a path or two. Other issues to consider is the other php entry points in the mv_embed folder like sample usage pages and cortado_iframe.php we can probably disable them for wikimedias usage. peace, --michael

1 0

SVN commit access
by Robin P. 16 Apr '09

16 Apr '09

It seems this is the place to request commit access, so I'd like to request commit access too. My key: http://toolserver.org/~robin/publickey.txt Commit name: robin (my wikiname is SPQRobin but uppercase appears to be not allowed) I want to use it to commit and maintain my extension (see http://www.mediawiki.org/wiki/Extension:WikimediaIncubator) to be used on Wikimedia Incubator. Maybe I'll do some general work/maintenance as well, or fix bugs, when I see something I can fix. I have already worked on SpecialInterwiki extension but I didn't work on it further since I didn't have commit access.. I also used to work a bit on i18n through Translatewiki.net (for example, reporting unused messages, ...) although that's not so important for this :) Thank you.

1 0

[Fwd: Phorm opt-out for Wikipedia.org and related domains]
by Brion Vibber 16 Apr '09

16 Apr '09

After some internal discussion on whether opting out of the Phorm user-profiling system in the UK would legitimize it, we're going ahead and requesting an opt-out for all the domains under the Wikimedia Foundation's control. For background see eg: http://www.openrightsgroup.org/2009/03/22/open-letter-call-for-major-websit… -- brion vibber (brion @ wikimedia.org) -------- Original Message -------- Subject: Phorm opt-out for Wikipedia.org and related domains Date: Thu, 16 Apr 2009 14:28:11 -0700 From: Brion Vibber <brion(a)wikimedia.org> To: website-exclusion(a)webwise.com CC: private-l(a)lists.wikimedia.org To whom it may concern -- The Wikimedia Foundation requests that our web sites including Wikipedia.org and all related domains be excluded from scanning by the Phorm / BT Webwise system, as we consider the scanning and profiling of our visitors' behavior by a third party to be an infringement on their privacy. Here is a list of our domains which should be excluded (please exclude any and all subdomains as well): wikipedia.org wikipedia.com wikipedia.co.uk wikipedia.cz wikipedia.fr wikipedia.info wikipedia.lt wikipedia.net wikipedia.nl wikipedia.org.br mediawiki.com mediawiki.org quickipedia.net quickipedia.org toolserver.org vikipedio.com vikipedio.org wikibook.com wikibooks.com wikibooks.cz wikibooks.org wikicitaty.cz wikidata.org wikidisclosure.com wikidisclosure.org wikidruhy.cz wikifamily.com wikifamily.org wikigis.com wikigis.org wikijunior.com wikijunior.net wikijunior.org wikiknihy.cz wikimania2006.org wikimania2007.org wikimaps.com wikimaps.net wikimediacommons.co.uk wikimediacommons.de wikimediacommons.eu wikimediacommons.info wikimediacommons.mobl wikimediacommons.net wikimediacommons.org wikimedia.cz wikimediafoundation.com wikimediafoundation.net wikimediafoundation.org wikimedia.hu wikimedia.li wikimedia.lt wikimedia.org wikimedia.pl wikimedia.se wikimedia.us wikimemory.org wikimorial.com wikimorial.org wikinews.org wikipaedia.net wikipedie.cz wikiquote.com wikiquote.cz wikiquote.net wikiquote.org wikislovnik.cz wikisource.com wikisource.cz wikisource.org wikispecies.com wikispecies.cz wikispecies.net wikispecies.org wikiversity.com wikiversity.cz wikiversity.org wikiverzita.cz wikizdroje.cz wikizpravy.cz wiktionary.com wiktionary.cz wiktionary.org Thank you for your time. -- brion vibber (brion @ wikimedia.org) CTO, Wikimedia Foundation San Francisco +1 (415) 839-6885

1 0

European network outage
by Brion Vibber 16 Apr '09

16 Apr '09

We’re encountering some networking problems between our Tampa and Amsterdam data centers, which is breaking access to the sites for people in Europe. Mark’s poking to see if it can be resolved; if necessary we’ll reroute European visitors directly to the Tampa center. -- brion

1 1

DEADLINE for WMDE contract applications
by Daniel Kinzler 16 Apr '09

16 Apr '09

Hello all At the developer meetup, I announced that Wikimedia Deutschland is offering contracts for a couple of projects we feel are important. We again invite anyone to apply NOW for any project that interests you. The DEADLINE for applying is SUNDAY, APRIL 19! We did not receive any offer for the most urgent project: Evaluate the impact of using flagged revisions on the German Wikipedia, see <http://www.mediawiki.org/wiki/WMDE_contract_offers/Evaluate_the_impact_of_u…>. We feel that it would be very helpful to run a full analysis on this before the English language Wikipedia decides on how to implement flagged revisions. It's a powerful tool, and we should make sure we use it to it's full potential. Below, the other projects are listed again: * Rewrite CatScan, a tool for finding pages in a set of categories recursively, based on various criteria - http://www.mediawiki.org/wiki/WMDE_contract_offers/Rewrite_CatScan * Store interwiki-links in the database, just like we already store interlanguage-links - http://www.mediawiki.org/wiki/WMDE_contract_offers/Store_interwiki-links_in… * Improve the Gadgets extension to allow for gadgets to be enabled per default, be restricted to specific user groups, etc - http://www.mediawiki.org/wiki/WMDE_contract_offers/Improve_the_Gadets_exten… * Implement full support for TIFF files, including multi-page TIFFs, similar to how DjVu is handled - http://www.mediawiki.org/wiki/WMDE_contract_offers/Implement_full_support_f… If you would like to help with any of the above, please contact me at <daniel.kinzler AT wikimedia.de> and provide the following information: * Your real name and country of residence * How you plan to go about implementing the desired function * Any experience working with MediaWiki * How many working hours you would spend on it, and how much you ask for it * In what time frame you would be able to do the job This information is also available at http://www.mediawiki.org/wiki/WMDE_contract_offers Thanks you all for your interest! -- daniel

1 0

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 April 2009