[Wikitech-l] NEW version 2.01 of Extension:OpenID
tl;dr NEW version 2.01 of Extension:OpenID published RE: https://www.mediawiki.org/wiki/Extension:OpenID (new "light" manual) RE: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/OpenID.git;a=commit;h=86e339bc695c72796014607da0223fd9d3341af9 RE: http://openid-wiki.instance-proxy.wmflabs.org/wiki/Main_Page (live code) RE: https://labsconsole.wikimedia.org/wiki/File:Wmflabs-openid.png I published the a new version 2.01 of the OpenID extension incl. a new logo. Fulfills wishes of Ryan and others, and it solves some bugs. When using as *Consumer Wiki *- the correct term is "Relying Party (RP)" - you as an admin you can now set $wgOpenIDConsumerForce to point to exactly _one_ fixed Provider and to skip the Provider selection page. When starting the authentication process, you can either choose a general OpenID - http://op-server/Special:OpenIDServer/id which then starts the *identity selection aka User login form *on the OpenID Provider Wiki (OP) or, if you what you know are doing and who you are, you can immediately authenticate as yourself (this was the only way possible in previous versions) - http://op-server/User:Username Some minor changes may need your action in LocalSettings, this is why I marked them as BREAKING CHANGES 1. renamed $wgTrustRoot to $wgOpenIDTrustRoot 2. default value $wgOpenIDShowProviderIcons = true; Enjoy it, and if you find bugs, file here https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=OpenID Known bugs are https://bugzilla.wikimedia.org/buglist.cgi?component=OpenID&resolution=--- Tom (Wikinaut) signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
On 02/09/2013 03:00 PM, Platonides wrote: On 08/02/13 21:51, Lee Worden wrote: As an aside, you could almost certainly do this cheaper with WorkingWiki. If you can write a make rule to retrieve the Excel file from the network drive and make it into html and image files (and maybe a little wikitext to format the page), you're done. LW You could do it with openoffice.org/libreoffice, although I agree that getting all the dependencies right for running in the server is a bit tedious. You can also use Excel itself for that (eg. COM automation), as suggested by vitalif, supposing you are using a Windows server. Yes, something like that is what I had in mind. On 02/09/2013 11:06 AM, Antoine Musso wrote: > In big companies, 10 000$ is cheap. Plus I bet they get a support > contract coming in. Overall, that is probably cheaper than paying an > internal software developer to integrate and then maintain the > WorkingWiki solution. > > -- Antoine "hashar" Musso True. Others who operate less formally might find it a welcome option, OTOH. LW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
On 9 February 2013 23:00, Platonides wrote: > You could do it with openoffice.org/libreoffice, although I agree that > getting all the dependencies right for running in the server is a bit > tedious. You can also use Excel itself for that (eg. COM automation), as > suggested by vitalif, supposing you are using a Windows server. You can in fact automate OO/LO in this manner. We do this at work (an application that has to turn RTF and DOC into PDFs; if you want a fighting chance of rendering Word files, you need something of comparable size to Word). Not fast (and we never could get daemon mode working) so cache your results. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia engineering January 2013 report
Hmm, you're right. Guess I forgot to mention it in the project status. Oh well, it's just SVN ;-) -Chad On Feb 9, 2013 6:09 PM, "Platonides" wrote: > On 07/02/13 21:54, Chad wrote: > > On Thu, Feb 7, 2013 at 3:50 PM, Platonides wrote: > >> Also worth mentioning, our SVN is now read-only. > >> > > > > This actually happened on Feb 1st :) > > > > -Chad > > I did check before sending. > «Marking all of SVN as read-only» sent Jan 24th. > Follow-up the next day saying: «This is now complete» > > Did January lose a week and nobody noticed me? :) > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developer Hub update
On Fri, Feb 8, 2013 at 12:30 PM, Petr Bena wrote: > Are you going to reference software that has nothing to do with mediawiki > on mediawiki.org as well? if not, then keep the hub we have on meta... > > I thought it was decided quite a long time ago that meta was for discussing the projects and not a place to keep random tech documentation, or am I mistaken? - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia engineering January 2013 report
On 07/02/13 21:54, Chad wrote: > On Thu, Feb 7, 2013 at 3:50 PM, Platonides wrote: >> Also worth mentioning, our SVN is now read-only. >> > > This actually happened on Feb 1st :) > > -Chad I did check before sending. «Marking all of SVN as read-only» sent Jan 24th. Follow-up the next day saying: «This is now complete» Did January lose a week and nobody noticed me? :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bootstrap based theme for Mediawiki
Patrick had also shown this to me a while back and I've made a demo for a replacement skin on labsconsole using a modified version of it: https://labsconsole-test.wmflabs.org/wiki/Main_Page The strapping skin itself has a few bugs that need to be fixed. I've fixed them and will be working on upstreaming them. On Fri, Feb 8, 2013 at 1:37 PM, Yuvi Panda wrote: > https://github.com/OSAS/strapping-mediawiki looks pretty awesome! (Example > at http://www.ovirt.org/Home). This also makes bootstrap's classes / > layouting helpers available to content inside the wiki itself, which is > pretty cool. > > (thanks to Patrick Reilly on IRC) > > -- > Yuvi Panda T > http://yuvi.in/blog > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
On 08/02/13 21:51, Lee Worden wrote: > As an aside, you could almost certainly do this cheaper with > WorkingWiki. If you can write a make rule to retrieve the Excel file > from the network drive and make it into html and image files (and maybe > a little wikitext to format the page), you're done. > > LW You could do it with openoffice.org/libreoffice, although I agree that getting all the dependencies right for running in the server is a bit tedious. You can also use Excel itself for that (eg. COM automation), as suggested by vitalif, supposing you are using a Windows server. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] RFC: Introducing two new HTTP headers to track mobile pageviews
On Thu, Feb 7, 2013 at 4:32 AM, Mark Bergsma wrote: > > - Since we're repurposing X-CS, should we perhaps rename it to something > > more apt to address concerns about cryptic non-standard headers flying > > about? > > I'd like to propose to define *one* request header to be used for all > analytics purposes. It can be key/value pairs, and be set client side where > applicable. There's been some confusion in this thread between headers used by mediawiki in determining content generation or for cache variance, and those intended only for logging. The zero carrier header is used by the zero extension to return specific content banners and set different default behaviors (i.e. hide all images) as negotiated with individual mobile carriers. A reader familiar with this might note that their are separate X-CS and X-Carrier headers but X-Carrier is supposed to go away now. Agreed that there should be a single header for content that's strictly for analytics purposes. All changes to the udplog format in the last year or so could likely be reverted except for the delimiter change, with a multipurpose analytics key/value field added for all else. > I think the question of using a URL param vs a request header should > mainly take into account whether the response varies on the value of the > parameter. If the responses are otherwise identical, and the value is only > used for analytics purposes, I would prefer to put that into the above > header instead, as it will impair cacheability / cache size otherwise (even > if those requests are currently not cacheable for other reasons). If the > responses are actually different based on this parameter, I would prefer to > have it in the URL where possible. > For this particular case, the API requests are for either getting specific sections of an article as opposed to either the whole thing, or the first section as part of an initial pageview. I might not have grokked the original RFC email well, but I don't understand why this was being discussed as a logging challenge or necessitating a request header. A mobile api request to just get section 3 of the article on otters should already utilize a query param denoting that section 3 is being fetched, and is already clearly not a "primary" request. Whether or not it makes sense for mobile to move in the direction of splitting up article views into many api requests is something I'd love to see backed up by data. I'm skeptical for multiple reasons. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
Le 08/02/13 21:51, Lee Worden a écrit : > > As an aside, you could almost certainly do this cheaper with > WorkingWiki. If you can write a make rule to retrieve the Excel file > from the network drive and make it into html and image files (and maybe > a little wikitext to format the page), you're done. In big companies, 10 000$ is cheap. Plus I bet they get a support contract coming in. Overall, that is probably cheaper than paying an internal software developer to integrate and then maintain the WorkingWiki solution. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Documentation for Extensions
Le 09/02/13 00:12, Matthew Walker wrote: > Do we have an existing method for extensions to > autogenerate documentation (via a commit hook or something) and then to > upload that to a documentation server? (Something akin to what we do with > MediaWiki core.) Not yet. I will have that integrated within Jenkins whenever I manage to fix the post merge jobs :-] > We should have this for Doxygen, and make something similar for JSDuck -- > the JS documentation system being pioneered by the VisualEditor team. Well at first, we would need JSDuck to be packaged so we can get it installed on a production server. Then a Jenkins job can take care of generating the doc for us after each merge. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
On Sat, Feb 9, 2013 at 2:41 AM, Teresa Cho wrote: > I would love to test the course once it comes out! I don't know how > MediaWiki API works so I should be able to give feedback as a newbie. > +1. Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Technical design review of extension
Le 09/02/13 02:35, Paul Selitskas a écrit : > Hello. > > I wrote an extension[1] for Wikinews and Wiktionary to replace the > JS-driven custom tabs (Opinions in Wikinews, Citations/Template > documentation in Wiktionary). > > According to the manual, as there were no "pros" heard from Design-l, now > the extension must undergo a technical design review, before it is decided > whether the extension is able to fly on production sites - deployment > review. Hello Paul! Thanks for notifying the new extension, we have so many nowadays that it is hard to keep track of all the code that flow in :-] I will give it a poke on Monday, probably configure it on the beta cluster too for us to test it and play with. Feel free to send patch over the weekend, I will be happy to review them too. -- Antoine "hashar" Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Technical design review of extension
One weird thing I've noticed is that for some reason the extension seems to be unsetting variables when it's done using them. I can understand not wanting to pollute the local variable scope, but it's really unnecessary and probably has some sort of performance impact when you're setting and unsetting variables in a foreach loop. Also, rather than have a separate hooks class, you can just make an object of the NamespaceRelations class in an extension setup function and register the hook using the object rather than the class name. Also, there's a few cases of call-time passing by reference, which I'm pretty sure causes fatal errors in PHP 5.4.0 and greater. As far as security goes, I cannot seem to find any issues, primarily because most of the actual rendering of the tabs occurs outside the scope of the extension. If I have time tomorrow maybe I'll submit a patch or two. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Sat, Feb 9, 2013 at 2:47 AM, Brian Wolff wrote: > Yes, extensions need to be reviewed (esp. In terms of security and > performance) before anyone will deploy them. > > -bawolff > On 2013-02-08 10:35 PM, "Tyler Romeo" wrote: > > > I agree, I'm just saying I think the guide is implying that the extension > > should be reviewed for security and whatnot before being deployed. > > > > *--* > > *Tyler Romeo* > > Stevens Institute of Technology, Class of 2015 > > Major in Computer Science > > www.whizkidztech.com | tylerro...@gmail.com > > > > > > On Fri, Feb 8, 2013 at 9:33 PM, Brian Wolff wrote: > > > > > To be honest, I doubt that many extensions go through a ui review prior > > to > > > their main review. Given that the ui components have already existed, I > > > would reccomend you just skip to the next step of that guide If you > can't > > > find anyone. Trust me as a volunteer contributed extension it will > > probably > > > get the ninth degree before it gets deployed anyhow > > > > > > -bawolff > > > On 2013-02-08 10:24 PM, "Paul Selitskas" > wrote: > > > > > > > Well, those tabs are already used in Wikinews and Wiktionary, so I > > > > personally find no reason for design review. > > > > > > > > > > > > On Sat, Feb 9, 2013 at 5:14 AM, Tyler Romeo > > > wrote: > > > > > > > > > I suppose that means there should be a review to see if the > extension > > > > > design is OK to be deployed live. > > > > > > > > > > *--* > > > > > *Tyler Romeo* > > > > > Stevens Institute of Technology, Class of 2015 > > > > > Major in Computer Science > > > > > www.whizkidztech.com | tylerro...@gmail.com > > > > > > > > > > > > > > > On Fri, Feb 8, 2013 at 9:07 PM, Paul Selitskas < > > p.selits...@gmail.com > > > > > >wrote: > > > > > > > > > > > On Sat, Feb 9, 2013 at 4:56 AM, Matthew Flaschen < > > > > > mflasc...@wikimedia.org > > > > > > >wrote: > > > > > > > > > > > > > On 02/08/2013 08:35 PM, Paul Selitskas wrote: > > > > > > > > According to the manual, as there were no "pros" heard from > > > > Design-l, > > > > > > now > > > > > > > > the extension must undergo a technical design review, before > it > > > is > > > > > > > decided > > > > > > > > whether the extension is able to fly on production sites - > > > > deployment > > > > > > > > review. > > > > > > > > > > > > > > Out of curiosity, where is this in the manual? > > > > > > > > > > > > > > Matt Flaschen > > > > > > > > > > > > > > < > > > https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment > > > > >? > > > > > > > > > > > > -- > > > > > > З павагай, > > > > > > Павел Селіцкас/Pavel Selitskas > > > > > > Wizardist @ Wikimedia projects > > > > > > ___ > > > > > > Wikitech-l mailing list > > > > > > Wikitech-l@lists.wikimedia.org > > > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > > > > > ___ > > > > > Wikitech-l mailing list > > > > > Wikitech-l@lists.wikimedia.org > > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > > > > > > > > > > > P.S. bikeshedding, guys... bikeshedding... > > > > > > > > -- > > > > З павагай, > > > > Павел Селіцкас/Pavel Selitskas > > > > Wizardist @ Wikimedia projects > > > > ___ > > > > Wikitech-l mailing list > > > > Wikitech-l@lists.wikimedia.org > > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > ___ > > > Wikitech-l mailing list > > > Wikitech-l@lists.wikimedia.org > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > ___ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listin
