Wikitech-l June 2014

wikitech-l@lists.wikimedia.org

139 participants
143 discussions

What should be the recommended / supported way to do skins? (A proposal.)
by Bartosz Dziewoński 21 Jul '14

21 Jul '14

tl;dr Let's adopt a better structure for skins. A more detailed proposal is at the bottom. As you might know, I am doing a Google Summer of Code project aiming to disentangle the mess of MediaWiki's skinning system a little bit, make creating custom skins a bit less painful and improve the separation between MediaWiki and its core skins [0] (https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki). I want this thread to result in code changes :) ---- So, MediaWiki supports skins, and apart from the four core ones there's a couple dozen of skins available for installation [1]. And looking at them, it seems as if every single one used a different directory structure, and this a different installation method. I think this is bad, and that we should standardize on something – preferably one of the widely used methods – and use it for the core skins as well to provide a good example. ---- There seem to be three popular ways: * $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/ for assets, using an autodiscovery mechanism to automagically make the skin available after the files are copied in the right place. This is used by all of the core skins (Vector has some special cases, but let's ignore that for now), as well as many external skins (e.g. Cavendish [2]), at a glance mostly older ones. * $IP/skins/SkinName/ for both assets and PHP files ($IP/skins/skinname/SkinName.php etc.), using require_once in LocalSettings like extensions to load the skin, manually adding an entry to $wgValidSkinNames in the main PHP file. This seems to be the preferred method among "modern" skins, for example Erudite [3] or Nimbus [4]. * $IP/extensions/SkinName/ for everything, the rest as above. This makes the skin work exactly like an extension. The only example I could find on mediawiki.org is the Nostalgia skin [5]. ---- The first one sounds like a no-go for me (in spite of being currently used for core skins, ugh): * The directory structure makes it annoying to both manage and write such skins (you need to copy/delete the PHP file and the directory separately, many text editors provide additional features for files contained in a single directory, and just look at our .gitignore file for skins oh god why [6]). * The usage of autodiscovery, while making installation and testing a bit simpler, makes it impossible or unpleasant to temporarily disable a skin or to provide configuration settings for it (the last point doesn't affect core skins). This leaves us with the two latter options: packaging skins similarly to extensions and sticking them in /skins, or packaging them like extensions and treating them like extensions. These two options are pretty similar and discussing them will be a bit bikesheddy, but let's do it anyway. (Note also that even if we wanted to, we can't stop anyone from using either of these if they feel like it, as MediaWiki supports loading everything from anywhere if you really want. We can, however, deprecate skin autodiscovery.) ---- Personally I'm leading towards the /skins/SkinName option. The pros are: * It seems to be more widely used, which means that it "felt right" to a lot of people, and that shouldn't be underestimated. * It's less revolutionary, and rather a simple improvement over the current system. * It's more intuitive when compared to how other applications / projects works. (Corollary: just because MediaWiki skins can do everything that extensions can do, we shouldn't encourage that.) * Since it's still similar to how extensions work, adapting the current system (WMF deployments, tarball packaging, installation via web installer) should be straightforward. * Switching current skins to this system within the mediawiki/core repo will be trivial. The pros of using /extensions/SkinName are: * We already have a battle-tested system for doing things with extensions (WMF deployments, tarball packaging, installation via web installer). * All non-core code in one place. I would like to settle this within a week or two. Help! :) Thoughts? I will document the result and, if feasible, convert core skins to be closer to the recommended format afterwards. ---- tl;dr Let's start putting all skins files in a single directory, and let's use a grown-up structure with one class per file + separate init code for them. Okay? [1] https://www.mediawiki.org/wiki/Category:Skin (this category tree is a mess, huh) [2] https://www.mediawiki.org/wiki/Skin:Cavendish [3] https://www.mediawiki.org/wiki/Skin:Erudite [4] https://www.mediawiki.org/wiki/Skin:Nimbus [5] https://www.mediawiki.org/wiki/Extension:Nostalgia [6] https://git.wikimedia.org/blob/mediawiki%2Fcore/master/skins%2F.gitignore -- Matma Rex

16 48

[GSOC 2014] Demo - Parsoid Based Linter
by hardik juneja 19 Jul '14

19 Jul '14

Hi Everyone, I am a GSOC student working with Parsoid Team [1] < https://www.mediawiki.org/wiki/Parsoid> to build a Parsoid based linter (Linttrap) [2] < https://www.mediawiki.org/wiki/Parsoid/Linting/GSoC_2014_Application>. Lintrap will detect broken wikitext found on the wiki pages and will also collect stats about certain wikitext usage patterns. Currently, for this demo, Lintrap can detect 4 types of broken wikitext, But, other kinds of issues could be detected in the coming weeks and months : * Fostered Wikitext : Eg [3] <http://lintbridge.wmflabs.org/_html/issues/53a2fe1e94641d9101f8e8b2> * Missing End Tag : Eg [4] <http://lintbridge.wmflabs.org/_html/issues/53a2fca994641d9101f8e72a> * Missing Start Tag : Eg [5] <http://lintbridge.wmflabs.org/_html/issues/53a2fdc394641d9101f8e850> * Stripped Tags : Eg [6] <http://lintbridge.wmflabs.org/_html/issues/53a2fd4394641d9101f8e819> Linttrap also collect information about transclusion usages where multiple templates are used to construct a DOM structure [7] < http://lintbridge.wmflabs.org/_html/issues/53a3026794641d9101f8ea81>. Here's our stats page [8] <http://lintbridge.wmflabs.org/stats>. Once a page is parsed, Lintrap uses parsoid based logger facility to log them to a web service. We call it Lintbridge [9] < http://lintbridge.wmflabs.org/>. Currently Lintbridge is hosted on Wikimedia Labs and use mongodb to store all the issues. Lintbridge offers a REST api which can be used by bots and other applications to fix the broken wikitext. Linttrap uses this REST api to store issues into Lintbridge. We have also built a HTML app on top of Lintbridge [10] < http://lintbridge.wmflabs.org/_html/issues>. This is a basic app for now which is used to demonstrate linttrap abilities. But, It is quite useful as it is today. Feel free to browse over the issues. * You can use the links in the table to filter the issues. * Click on issue type to filter issue by issue type. * You can filter issue by page too. * You can use Fix All to fix all issue for that page. * You can even use filters on the top bar to filter by Wiki and Type. * Each issue contain a info about wiki, page, revision on the left and the wikitext snippet on the right. Just for the demo of this working prototype, we have collected issues by parsing 1000 picked from http://parsoid-tests.wikimedia.org/topfails <http://parsoid-tests.wikimedia.org/topfails/0>. If you want to try the JSON API you can use the following routes. GET /_api/issues : Show all issues ( http://lintbridge.wmflabs.org/_api/issues) GET /_api/issues/type/issue-type : Filter by issue-type ( http://lintbridge.wmflabs.org/_api/issues/type/fostered) GET /_api/enwiki/issues : Filter by enwiki ( http://lintbridge.wmflabs.org/_api/enwiki/issues) POST /_api/add : Add a issue to the Lintbridge Inviting feedback. Thank you Hardik Juneja -- [1] Parsoid: https://www.mediawiki.org/wiki/Parsoid [2] Linttrap: https://www.mediawiki.org/wiki/Parsoid/Linting/GSoC_2014_Application [3] Fostered Ex : http://lintbridge.wmflabs.org/_html/issues/53a2fe1e94641d9101f8e8b2 [4] Missing End Tag eg : http://lintbridge.wmflabs.org/_html/issues/53a2fca994641d9101f8e72a [5] Missing Start Tag eg : http://lintbridge.wmflabs.org/_html/issues/53a2fdc394641d9101f8e85 <http://lintbridge.wmflabs.org/_html/issues/53a2fdc394641d9101f8e850>0 <http://lintbridge.wmflabs.org/_html/issues/53a2fdc394641d9101f8e850> [6] Stripped Tag eg : http://lintbridge.wmflabs.org/_html/issues/53a2fd4394641d9101f8e819 [7] Mixed Template eg : http://lintbridge.wmflabs.org/_html/issues/53a3026794641d9101f8ea81 [8] Stats Page : http://lintbridge.wmflabs.org/stats [9] Lintbridge: http://lintbridge.wmflabs.org/ [10] HTML App: http://lintbridge.wmflabs.org/_html/issues

3 4

Re: [Wikitech-l] MediaWiki to Latex Converter
by Fred Bauder 17 Jul '14

17 Jul '14

I have a log of what happens on when the commands: sudo apt-get install mediawiki2latex mediawiki2latex -u https://en.wikipedia.org/wiki/Adam_Ries -o AdamRies.pdf are entered on the command line of ubuntu (13.10) Better than TV... Happy to send it to anyone. Fred

6 11

RFC: Composer managed libraries for use on WMF cluster
by Bryan Davis 15 Jul '14

15 Jul '14

I have converted my email on using composer to manage a set of library dependencies for MediaWiki-Core [0] into an RFC [1]. Work is continuing on the implementation of this project, but there are still debatable implementation details and the RFC process is meant to not only validate ideas but leave behind a record of the design decisions that have been made and trade offs that were considered in the process. In particular, the current draft RFC omits discussion of the concept of library "ownership" for long term updates and security fixes and could use more detail around the process of forking, patching and subsequently maintaining a external library. I will attempt to fill in some of these details as I see them over the next day or so, but now would be a great time for people with strong ideas or opinions on these aspects to comment on the talk page. [0]: http://www.gossamer-threads.com/lists/wiki/wikitech/467520?page=last [1]: https://www.mediawiki.org/wiki/Requests_for_comment/Composer_managed_librar… Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

1 1

Tell my favorite conference about your Wikimedia tech
by Roan Kattouw 14 Jul '14

14 Jul '14

The linux.conf.au conference, which I have presented to and love going to, just opened up its call for talks: http://linux.conf.au/cfp . They want talks about all kinds of open source programming stuff, not just Linux: Trevor and I presented about ResourceLoader in 2012, and James and I presented about VisualEditor in 2014. LCA 2015 will be 12-16 January in Auckland, New Zealand. That's summer in the Southern Hemisphere, and the climate there is very moderate, so no sweltering heat like in Australia :) LCA provides travel funding to some speakers, and Wikimedia funds TPS grants for people going to conferences to talk about Wikimedia-related things: https://meta.wikimedia.org/wiki/Grants:TPS . So you could even get to go for free. LCA is basically my favorite conference - the talks are great and of high quality, they treat speakers well, and their audience gets what we're doing. This is a fun chance to show off your project. I encourage you to suggest a talk, or tell someone else that they should talk about their project. Roan P.S.: Thanks to Sumana for writing most of this email, and for talking me into proposing a talk for LCA in the first place back in 2011

5 8

MediaWiki Release RFP Status Update
by Greg Grossmeier 12 Jul '14

12 Jul '14

Hello all, We're in negotiations with one of applicants for the MediaWiki release management RFP and will make the official announcement ASAP, likely early next week. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

2 2

recent changes stream
by Ori Livneh 11 Jul '14

11 Jul '14

Hi, Gerrit change Id819246a9 proposes an implementation for a recent changes stream broadcast via socket.io, an abstraction layer over WebSockets that also provides long polling as a fallback for older browsers. Comment on < https://gerrit.wikimedia.org/r/#/c/131040/> or the mailing list. Thanks, Ori

11 17

Minding pull-requests on GitHub
by Ori Livneh 11 Jul '14

11 Jul '14

I just stumbled across <https://github.com/wikimedia/mediawiki-core/pull/19>, a small but useful contribution to core from an HHVM developer. It has gone unnoticed for two months, which is a bit sad. Is there a way to accept pull-requests from GitHub? According to < https://github.com/wikimedia/mediawiki-core/settings/hooks> (may not be visible to non-Wikimedians, sorry), the WebHook receiver < http://tools.wmflabs.org/suchaserver/cgi-bin/receiver.py> is defunct. Anyone know the story there? It'd be good if some additional people were watching (that is, receiving notifications for) <https://github.com/wikimedia/mediawiki-core/>. I haven't responded yet, by the way, so feel free to if you know the answers to these questions. I don't know what effect accepting the pull-request will have on the code in master, and telling someone who has already submitted a patch to go sign up for Gerrit seems impolite. Ori

10 13

MW-Vagrant improvements at the Zürich Hackathon
by Arthur Richards 10 Jul '14

10 Jul '14

Just wanted to send out an update on the progress we made around MW-Vagrant improvements at the Zürich Hackathon. Our primary goal was to make some key production services available in MW-Vagrant in order to make local development/testing easier/more reliable. We made some excellent headway, focussing on a few key services: SSL, Varnish, CentralAuth/Multiwiki. SSL: I spent a majority of my time focussing on this and received a lot of support/help from Ori. There is now an 'https' role in mw-vagrant which when enabled, will allow you to access your devwiki on port 4430 (forwarded to 443 in Vagrant). There is one outstanding patchset which will make it possible to use $wgSecureLogin in MW-Vagrant: https://gerrit.wikimedia.org/r/#/c/132799/ Varnish: This is proving to be much more difficult than anticipated, however some progress was made and work is ongoing, spearheaded by Andrew Otto. The plan is to set up varnish VCLs for mw-vagrant similar to what is set up for text varnishes in production, with a frontend and backend instance running in vagrant. Andrew is in the midst of refactoring the production varnish module, to make it usable in Vagrant. CentralAuth/Multiwiki: Bryan Davis, Chris Steipp, and Reedy spent a lot of time hacking on this, and we now have support for multiwiki/CentralAuth in Vagrant! There is still some cleanup work being done for the role to remove kludge/hacks/etc (see https://gerrit.wikimedia.org/r/#/c/132691/). Also of significant note, Matt Flaschen created a mw-vagrant iso which can be packaged on USB thumb drives, making it possible to set up mw-vagrant without a network connection. There is still some work to be done here to create a one-click installer as well as updating documentation. Matt got this done before the hackathon, and we brought a bunch of USB sticks imaged with the iso, which was instrumental in getting a bunch of folks new to mw-vagrant up and running at the hackathon. This was particularly useful during Bryan Davis's vagrant bootcamp sessions. I believe Katie Filbert from Wikidata did some mw-vagrant work at the hackathon as well, although I'm not clear on the current status. Katie, can you let us know where things were at with what you were working on? All in all it felt like a very fruitful hack session, and we're closer than ever to having a ready-to-go developer instance that mimics our production environment. Big thanks to everyone involved in making our work successful. -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

7 12

Call for Wikimedia Hackathon(s) 2014-2015
by Quim Gil 09 Jul '14

09 Jul '14

(CCing wikimedia-l as well, please send any replies to wikitech-l only) The Wikimedia technical community wants to have another hackathon next year in Europe. Who will organize it? Interested parties, check https://www.mediawiki.org/wiki/Hackathons We would like to confirm a host by Wikimania, latest. The same call goes for India and other locations with a good concentration of Wikimedia contributors and software developers. Come on, step in. We want to increase our geographical diversity of technical contributors. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 1

Jump to page:

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 June 2014