http://alliedmedia.org/news/2014/01/13/propose-session-amc2014
"The Allied Media Conference <https://amc.alliedmedia.org/> is a
collaborative laboratory of media-based organizing strategies for
transforming our world, held every Summer in Detroit." I'd love for us to
propose some sessions to help people learn about and use Magnus's query
tools, set up Wiki Loves Foo campaigns, and despam and rev up their
MediaWiki installations with multimedia.
The deadline is March 1, 2014. AMC2014 will be June 19-22, 2014 in Detroit,
Michigan, USA. Volunteers: if your session gets accepted, you can get your
trip paid for by WMF: https://meta.wikimedia.org/wiki/Grants:TPS
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
RFC: https://www.mediawiki.org/wiki/Requests_for_comment/Assert
This is a proposal for providing an alternative to PHP's assert() that allows
for an simple and reliable way to check preconditions and postconditions in
MediaWiki code.
The background of this proposal is the reoccurring discussions about whether
PHP's assert() can and should be used in MediaWiki code. Two relevant threads:
http://www.gossamer-threads.com/lists/wiki/wikitech/275737http://www.gossamer-threads.com/lists/wiki/wikitech/378676
The outcome appears to be that
assertions are generally a good way to improve code quality
but PHP's assert() is broken by design
Following a suggestion by Tim Starling, I propose to create our own functions
for assertions.
-- daniel
Hi,
to test changes to operations/mediawiki-config, I'd like to
display the settings for a given wiki.
So far I figured out:
| <?php
| $IP = 'wmf-config';
| $cluster = 'pmtpa';
| require ('/home/tim/public_html/w/includes/SiteConfiguration.php');
| require ('wmf-config/wgConf.php');
| var_dump ($wgConf->getAll ([...]));
However, all my creativity regarding parameters to getAll()
only returned an empty array.
What would be the parameters needed for example to get the
settings for de.wikipedia.org?
TIA,
Tim
Can we deprecate usage of '!ask' on IRC?
> ori-l: !ask
> wm-bot: Hi, how can we help you? Just ask your question.
It's annoying when people ask to ask, but the people who do so do it out of
insecurity or lack of experience, and so they're the last people we should
be siccing our bots on.
I've used '!ask' a lot before but I'm going to stop. I hope others do the
same.
https://blog.wikimedia.org/2014/01/21/wikimedia-israel-winter-hackathon/
Thanks to the folks who put together this event! I would love to hear more
about the "Python script to create a PowerPoint presentation directly from
a Wikipedia article"...
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Thanks to some fantastic work by Erik Bernhardson[0], MediaWiki-Vagrant can
now run MediaWiki on HHVM. The setup runs HHVM behind Apache using FastCGI,
which is a close match to how we think we'll be running it in production.
It uses the 'hhvm-nightly' packages from Facebook, so you can test
MediaWiki core and extensions against cutting-edge builds.
To switch MediaWiki from PHP to HHVM, simply run 'vagrant enable-role
hhvm', followed by 'vagrant provision'. To switch back to PHP, run 'vagrant
disable-role hhvm' and reprovision.
Please try it out and FILE BUGS for any issues you encounter. This includes
not only provisioning failures (which should be reported under the
MediaWiki-Vagrant product in Bugzilla) but also any instances of PHP code
breaking under HHVM. There is now an 'hhvm' keyword in Bugzilla you can use
to tag your report.
Three cheers for Erik B., and for Facebook's Paul Tarjan, whose recent
packaging work makes this possible.
[0]: https://gerrit.wikimedia.org/r/#/c/105834/
---
Ori Livneh
ori(a)wikimedia.org
Following Rob's advice "If it doesn't make it to the mailing list it
didn't happen."
After a chat with Markus Glaser, Mark Hersberger, and Jared Zimmerman at
the Architecture Summit, we have decided to create a wiki page to define
the specifications of this project. Your ideas and feedback are welcome:
https://www.mediawiki.org/wiki/MediaWiki/Gallery_of_extensionshttps://bugzilla.wikimedia.org/show_bug.cgi?id=46704
While we have no idea where the resources to develop this project will
come from, we agree about its importance, and we think that defining a
plan is the obvious first step. Markus & Mark will lead this discussion
as part of their efforts improving MediaWiki as a product for third parties.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
The roll-out of 1.23wmf2 to your favorite Wikimedia wiki will
inaugurate the era of ResourceLoader module storage -- an era which
will be marked by terrifying and hilarious new bugs, intermittent
client-side failures, and generally inexcusable disruptions to user
experience. Sounds exciting? Read on!
What is it?
-----------
"Module storage" refers to the use of localStorage in ResourceLoader
as an auxiliary to the browser cache. ResourceLoader, remember, is the
MediaWiki subsystem that delivers JavaScript and CSS to your browser.
One of its primary functions is to minimize the total number of
network requests that your browser needs to make in order to render
the page, and to make the remaining requests as slim as possible. One
of the ways ResourceLoader does this is by making a list of all the
different components your browser needs and then transmitting them in
bulk.
The downside of this approach is that a small update to MediaWiki's
code, touching perhaps one or two components, will often force the
browser to throw out (and re-retrieve) a bunch of unrelated modules
that did not change and did not ostensibly need to be re-retrieved.
This is because the browser cache operates on the level of network
requests; it is not intelligent enough to decompose a request into its
constituitive parts and to cache these parts separately from one
another.
Starting with the 1.23wmf2 branch, ResourceLoader will check if your
browser implements localStorage, a mechanism for storing structure
data. If it does, ResourceLoader will use it as an auxiliary cache,
capable of versioning individual components.
Why?
----
The primary goals are:
* Destabalize MediaWiki's front-end code, by coupling it to an
inconsistently-implemented and poorly-understood HTML5 API.
* Make debugging fun again, by adding another layer of caching to
MediaWiki. Yes!!
However, as with all new features, unintended side-effects are
possible. Specific concerns for module storage include the risk of
making the network footprint of page loads smaller, resulting in
improved latency.
But seriously,
--------------
* Module storage is enabled only if the underlying browser supports
localStorage (~89% of browsers in use, according to
<http://caniuse.com/#feat=namevalue-storage>). Users with older
browsers will not see a benefit, but they will not suffer a penalty
either.
* Module storage may or may not improve site performance. We need to
test it against a wide range of browsers and platforms to know for
certain. If it doesn't improve performance, we'll blame it on you,
your poor choice of browsers, and your uncooperative attitude, but
then we'll scrap it.
How can I test it?
------------------
Glad you asked! Module storage is enabled by default on the beta
cluster, and on test & test2 wikis. The simplest way you can help is
by being alert to to performance regressions and front-end code
breakage. If you know how to use your browser's JavaScript console,
you can get stats about module storage usage on the current page by
checking the value of 'mw.loader.store.stats'.
When the code is rolled out across the cluster, it will be disabled by
default, but you will be able to opt-in by manually setting a cookie
in your browser. I will follow up with the exact details. If module
storage proves stable enough for production use, we'll seek to asses
its utility by running a controlled study of some kind. If we can
demonstrate that module storage leads to a significant improvement in
performance, we'll enable by it default.
---
Ori Livneh
ori(a)wikimedia.org
Hi,
Here, its Nitin Agarwal, Software Developer and Programmer. I am currently
pursuing Computer Science and Engineering at International Institute of
Information Technology, INDIA.
I would like to Wikimedia as Web Developer and Systems Administrator
projects. I have gone through the
https://www.mediawiki.org/wiki/Starter_kitand installed and configured
mediawiki on my machine running at localhost.
I would like to work on the ongoing project works of Wikimedia and carry on
with the project through Gsoc 2014 and afterwards, become a regular
contributor to Wikimedia.
One can see my username as Wikimedia over here :
https://www.mediawiki.org/wiki/User:Nitinagarwal3006
Github : *https://github.com/NitinAgarwal <https://github.com/NitinAgarwal>*
IRC : nitinagarwal3006
--
*Nitin Agarwal*
Website : www.nitinagarwal.in