Hi everyone,
A big thank you to everyone who participated in the Architecture Summit
this year! We covered a lot of ground this year, and collectively learned
a lot about how to put these things together.
A lot of our work from this summit on this is only just beginning.
Speaking of that, just the act of processing the notes is going to be the
first step. MatmaRex and Legoktm pulled together a concise list of the
etherpads here, which I've annotated with the corresponding agenda pages:
https://www.mediawiki.org/wiki/Architecture_Summit_2014/Retrospective#Notes…
Our next course of action is to get all of these copied to mediawiki.org to
the agenda pages, so that we have a record of each session that will
outlive Etherpad's temporary storage. I've done a little bit (the
Architecture value, process, and guidelines discussion), but I'd love help
from others on both getting it all copied in place, and wikifying it. Any
takers?
Those of you that couldn't make it, I'd encourage you to read through the
notes We'll be discussing a lot of this over the coming days, so it'll be
useful context to bring you up to speed on these things.
Rob
https://www.mediawiki.org/wiki/Architecture_guidelines
I have worked on improving the architecture guidelines, but I think they
are still a draft, and I'm sorry about that, because I wanted to have that
done by now. Specifically, I think the "YAGNI" and "separation of concerns"
sections could be clearer, and I'd love more examples of times in the past
we did data-driven change well or badly.
I suggest that we talk onlist, onwiki, and in a future RfC meeting about
those points. I'm this week moving on to working on API documentation
https://www.mediawiki.org/wiki/Data_%26_Developer_Hub but I can participate
in those discussions.
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
I have uploaded a new version of the Winter framework/prototype, v. 0.6.
http://unicorn.wmflabs.org/winter/
This version has significant changes over 0.5. The entire undercarriage has been refactored into a framework to allow for anyone to do rapid prototyping within their own copy. The source code has been installed into gerrit, in the form of two depots, one of which is for specialized "modules" that change the way the prototype behaves (snowflakes).
Links to the source depots are available at:
https://www.mediawiki.org/wiki/Winter#The_Winter_Framework
This release adds in several major changes:
* "Right rail" functionality, designed to surface content
* Search functionality
* Watchlist functionality (for testing)
* A revisit to the design of the edit interface.
A full changelog for version 0.6 can be found here:
https://www.mediawiki.org/wiki/Winter#Version_0.6.2C_July_13.2C_2014
As usual, feedback is welcomed here:
https://www.mediawiki.org/wiki/Talk:Winter
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
---------- Forwarded message ----------
From: Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org>
Date: Wed, Jul 16, 2014 at 4:05 PM
Subject: [Mediawiki-api] [Mediawiki-api-announce] RFC on changes to the API
To: mediawiki-api-announce(a)lists.wikimedia.org
If you want to give input on numerous proposed changes to the API, please
comment at https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap
Also, please advertise that link on-wiki at any suitable locations. Thanks.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
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
Hi,
I am Akshit (Co-Founder of Wibe), we have made a Chrome Extension by which
anyone will be able to watch relevant YouTube videos corresponding to the
Wiki Article they are reading.
It is the deadly combination of Wikipedia and YouTube, it can really become
a great new feature of Wikipedia. We developed it to solve our problem of
switching to YouTube from Wiki to understand a particular thing.
I would be very thankful if you guys please try and review it. Then if you
like Wibe, consider it to integrate as a functionality in Wikipedia for
some days so that user can use and review this new feature.
*Website*: http://www.letswibe.com
*Extension*: http://goo.gl/EiFG9t
*Demo Video*: https://www.youtube.com/watch?v=98uDPo7ZjVI
Install the Extension and then try out "
http://en.wikipedia.org/wiki/Wikipedia:About" page to see how it changes
the original wiki page by integrating relevant videos from YouTube.
Cheers,
Akshit Agarwal (Co-Founder, Wibe)
akshit.jiit(a)gmail.com
+91 8447136882
+91 8447735016
We have a number of contributors who do prefer contributing through
web-interfaces or minimal installations to MediaWiki's code base. Often
they run -1 with MediaWiki's coding conventions and do not have the time
to set up commit hooks [1]. To save them some work re-indenting or
adding a space between braces, I have decided to expose the excellent
stylize.php from wikimedia tools-code-utils and js-beautifier as a web
service at WMF labs.
The result is a web interface:
http://tools.wmflabs.org/stylize/
If you find a security vulnerable in the source code[2], you get a
barnstar by me personally.
Happy coding and don't forget to recommend it when -1ing for whitespace
reasons!
-- Rillke
[1]
https://www.mediawiki.org/wiki/Chemical_Markup_support_for_Wikimedia_Common…
[2] https://github.com/Rillke/stylize