Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and
talked about the future of skins. Hopefully this mail summarises what
we talked about and what we agreed on. Feel free to add anything, or
ask any questions in the likely event that I've misinterpreted
something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it
currently is for developers to create a skin. The skin class involves
too many functions and does more than a skin should do e.g. manage
classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list
generator to generate things like a list of links to user tools. The
widgets will be agnostic to how they are rendered - some may use
templates, some may not.
We identified the new skin system will have two long term goals:
1) We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css
file.
2) Should be possible for us in future to re-render an entire page via
JavaScript and using the modern history push state re-render any page
via the API. (Whether we'd want to do this is another consideration
but we would like to have an architecture that is powerful enough to
support such a thing)
As next steps we agreed to do the following:
1) Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and
has resulted in MobileFrontend rewriting it. We decided to target this
as it is a simple enough example that it doesn't need a template. It's
small and contained enough that we hope this will allow us to share
ideas and codify a lot of those. Trevor is hoping to begin working on
this the week of the 2nd September.
2) We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the
templating RFC [1] can get resolved however we are getting to a point
that we need one as soon as possible and do not want to be blocked by
the outcome of this RFC, especially given a mustache based templating
language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
TL;DR: Please review [1]
I was asked to discuss the topic on the mailing list, so here goes.
Since some time Siebrand is making an effort to improve code quality by
making it phpcs-strict compliant [0]. This involves explicitly declaring
the visibility of class members.
Alas, intended or not, in very many cases he did not only explicitly
declare the class variable's visibility, but he also changed it from the
implicit 'public' to explicit 'protected' or 'private', thus introducing
a major API change without a proper deprecation period. Apparently this
was not noticed (or at least not challenged) by the reviewers. I checked
a few of his commits and they were all merged within hours.
Now, to be clear about that, I appreciate both changes - the phpcs
compliance as well as the more limited accessibility of class variables.
This was long overdue. However, to introduce something like this a
proper deprecation period is in my opinion essential, in particular
considering the extent of the changes. I do believe that Siebrand
checked that the variables he declared protected or private were not
used by extensions. However, he missed one (EditPage::mTokenOk) which
subsequently resulted in a bug in an extension (SemanticForms). Given
the number of the now newly hidden variables I am quite sure, that there
are other cases. If only because many extensions are not hosted on WMF
servers, so they can not be checked.
To keep the changes and still be able to properly deprecate the direct
access to the member variables I submitted a patch [1] that makes use of
PHP magic functions [2]. They provide access to the class members and
issue a deprecation warning. The intention is to keep these functions
for the custom two releases [3], i.e. until 1.26, and then remove them.
This patch was shot down for three reasons:
<quote>
* it duplicates code
* there is no tests
* our code base barely use the magic methods and I am pretty sure Tim
Starling commented a while back about them being nasty.
</quote>
When I pointed out, that these functions are not re-entrant and thus
Tims warning [4] did not apply the answer was "I have merely copy pasted
Tim comment without even attempting to understand what it means". I was
subsequently asked to present this to the mailing list which I do with
this mail.
I would appreciate comments on the patch (preferably constructive), that
would allow us to not revert Siebrand's changes and still properly
deprecate formerly public class members.
Thanks.
Stephan
[0]
https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/core+bra…
[1] https://gerrit.wikimedia.org/r/#/c/151370/
[2]
http://php.net/manual/en/language.oop5.overloading.php#language.oop5.overlo…
[3] https://www.mediawiki.org/wiki/Deprecation
[4] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/85288#c17504
Hi,
Users of the future Wikimedia Phabricator will have a very simple and
straightforward interface to create and edit tasks. Bugzilla's UI was one
of the top complaints from new/casual users, and we can fix this in
Phabricator easily. Currently we are testing this setup in fab.wmflabs.org,
where you can see an example:
http://fab.wmflabs.org/maniphest/task/create/ (imagine that the "Points"
field is not there).
Advanced users needing to prioritize tasks, assign them to someone, and
resolve them can join the Triagers team in order to get the additional
permissions:
http://fab.wmflabs.org/project/view/74/
We are still fine tuning this process at http://fab.wmflabs.org/T64 -- your
feedback is welcome.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi all.
I've noticed Echo has a separate special page, Special:Notifications. Would we like to rewrite the extension so that it adds entries to the watchlist instead? (And add 'Edits' tab into echo itself - put the watchlist items there).
There is a lot of Special: pages already and adding new ones doesn't - immediately - appear to help usability.
svetlana
Hi,
Is there any way to display images uploaded into a particular category on
Wikimedia Commons to be displayed in realtime on a WordPress site?
Like a plugin that follows a particular category on commons and displays
any images that are added to it? Kinda a feeder?
Thanks
Rexford | google.com/+Nkansahrexford | sent from Smartphone
Hi I would like to ask those who use jquery.choosen to start updating there extensions that use it because the change will deprecate some functions, or remove them it also changes the css code.
Main thing about the update is a speed increase.
please review change here
gerrit.wikimedia.org/r/#/c/139699/
Hi all,
I'd like to remind everyone that we now have WMF-deployed code in the
mediawiki/skins/* repository group, most importantly in
mediawiki/skins/Vector (but also MonoBook, Modern, CologneBlue). It seems
that patches proposed and merged there are getting a lot less review (and
fewer reviewers) than they used to while the skins were in core.
Please update your review subscriptions :) There are at least two ways to
subscribe to incoming changes:
* Publicly at https://www.mediawiki.org/wiki/Git/Reviewers
* Sneakily at https://gerrit.wikimedia.org/r/#/settings/projects
--
Matma Rex
Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_September_1st>
A quick list of notable items...
== Monday ==
US Holiday (Labor Day), thus no deploys
== Tuesday ==
* Commons to will get the new CirrusSearch as the primary search engine
** <https://www.mediawiki.org/wiki/Search>
* MediaWiki deploy
** group1 to 1.24wmf19: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf19>
== Wednesday ==
* Weekly fundraising banner test
== Thursday ==
* MediaWiki deploy
** group2 to 1.24wmf19 (all Wikipedias)
** group0 to 1.24wmf20 (test/test2/testwikidata/mediawiki)
Thanks and as always, questions and comments welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |