Hello,
Kevin Carillo[1] from University of Wellington is going to research
"Newcomer experience and contributor behavior in FOSS communities[2]
So far Debian, GNOME, Gentoo, KDE, Mozilla, Ubuntu, NetBSD, OpenSUSE
will be taken into account, and FreeBSD recently joined[3] and
there is still some possibility for other large FOSS projects to join.
I think it could fit nicely into our recent efforts directed
at newcomer experience after Git migration. And MediaWiki is
a bit different than above projects.
Are we interested
to include MediaWiki in that research?
As Kevin explains in his post he tried to avoid spamming mailing
lists to look for project interested, so I am doing this for him :-)
//Saper
[1] http://kevincarillo.org/about/, http://twitter.com/kevouze
[2] http://kevincarillo.org/survey-invitation/
[3] http://kevincarillo.org/2012/11/15/welcome-freebsd/
All extension branches were removed during the migration to Git. Very
few extensions have branches for MW core major version support.
There's no longer a simple way to branch all extensions when a core
release is updated, and nobody has volunteered to write a script.
So we're back to the situation we had in MW 1.9 and earlier, where
it's usually not possible to run any actively maintained extension
against an MW core that's not the current trunk.
Given this, I think code reviewers should insist on backwards
compatibility with MW 1.20 for commits to the master branch of
extensions that are commonly used outside Wikimedia, at least until
the release management issue is solved.
-- Tim Starling
https://fosdem.org/2013/news/2012-11-01-cfp/
FOSDEM is an open source conference in Brussels, February 2-3 2013.
Wikimedians who want to give a talk there are eligible for Participation
Support subsidies:
https://meta.wikimedia.org/wiki/Participation:Support
I encourage you to submit a talk, to the main conference or the
devrooms, about MediaWiki, your work on bots, legal/licensing issues,
mobile, our use of MySQL or PHP, or other relevant topics. I can help
you develop a talk proposal. Deadlines are coming up in December.
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Hi all,
Two months ago, we talked about Extension:Widgets [1] and
mediawikiwidgets.org [2] on wikitech-l [3].
Reminder: With Extension:Widgets, external services (Youtube, Facebook...)
are added to the parser by writing code (smarty) in the Widget namespace.
These Widgets are hosted on mediawikiwidgets.org.
In short, Sergey Chernyshev [4] wondered how we could save this great work.
That lead to a discussion about the quality/sustainability of
Extension:Widgets. Biggest issues raised were: security (code stored within
the wiki pages) and version control (of widgets).
We [5] have been working since on Extension:WidgetsFramework [6]. Inspired
by Extension:Widgets, we hope it could be a suitable successor. With
Extension:WidgetsFramework, external services are added to the parser like
any other MediaWiki extension (php) but the code is factorized and
simplified. These Widgets are hosted in Git [7]
See the thorough documentation:
http://www.mediawiki.org/wiki/Extension:WidgetsFramework
We believe WidgetsFramework is now stable and advanced enough to face the
community (and its challenging insights). And here we are, asking:
- Do you think this extension has an use and a future for more than just
our wiki?
- If yes, what is the best way to distribute/manage the codes
(framework+widgets) within the community?
- If answer is "Git+Gerrit+mediawiki.org", can we get help? Our resources
are rather limited and... well... Gerrit scares us a bit :-)
Thank you for your time,
Regards.
--
[1] http://www.mediawiki.org/wiki/Extension:Widgets
[2] http://www.mediawikiwidgets.org
[3]
http://comments.gmane.org/gmane.science.linguistics.wikipedia.technical/637…
[4] http://www.sergeychernyshev.com
[5] http://www.seizam.com
[6] http://www.mediawiki.org/wiki/Extension:WidgetsFramework
[7]
https://github.com/Seizam/seizamcore/tree/master/WikiZam/extensions/Widgets…
--
Clément Dietschy
*Seizam* Sàrl.
24, rue de Bâle
68300 Saint-Louis (France)
tél. +33 6 87 75 99 27
www.seizam.com
Hi!
Some year ago, I used to create Vector-based skin with redesigned layout (very different positions of sidebar and action links) in MW 1.17 from scratch, via copying all of Vector subtree and modifying it, then adding my skin resources into Resources.php. It worked, but was a lot of work, including core patching.
Now I work with 1.20 and there's an article written by Daniel Friesen on how to create Vector-derived skins without modifying Resources.php and using Vector classes and styles as a base. So I do not have to modify the core and to copy the whole skin subtree:
http://blog.redwerks.org/2012/02/28/mediawiki-subskin-tutorial/
I mostly followed the instructions in the guide. However my skin also changes skin execute() method, because not just css and quite a lot of layout is changed. execute() works fine.
I need to override a lot of Vector's css, located in 'skins.vector' resource module.
But the following code:
/**
* @param $out OutputPage object
*/
function setupSkinUserCss( OutputPage $out ){
parent::setupSkinUserCss( $out );
$out->addModuleStyles( "skins.artmuseum" );
}
causes 'skins.vector' styles to be loaded after my 'skins.artmuseum' styles. So, the Vector styles are not overwritten by my skin styles.
Changing the order does not help:
function setupSkinUserCss( OutputPage $out ){
$out->addModuleStyles( "skins.artmuseum" );
parent::setupSkinUserCss( $out );
}
ResourceLoader has 'dependencies' key to make resource automatically be dependent on another resource:
$wgResourceModules['skins.artmuseum'] = array(
'styles' => array(
'artmuseum/screen.css' => array( 'media' => 'screen' ),
),
'remoteBasePath' => &$GLOBALS['wgStylePath'],
'localBasePath' => &$GLOBALS['wgStyleDirectory'],
'dependencies' => 'skin.vector'
);
However, 'skin.vector' module includes both styles and scripts. And setupSkinUserCss() adds styles only. So 'dependencies' did not help, vector styles are loaded later, anyway. What can I do with that?
Also, I need to load remote google webfonts. Does ResourceLoader support this or I have to use old-fashionated methods of OutputPage() ?
Dmitriy
Hey all,
Just a reminder that jQuery will (after almost 4 years of deprecation!) drop
$.browser [1] in jQuery 1.9.
Please check your scripts and make sure you are are no longer using "$.browser"
(or "jQuery.browser"). After jQuery 1.9 is released, from the next MediaWiki
deployment after that $.browser will be undefined and old code trying to access
a property of it will throw a TypeError for accessing a property of undefined.
Don't be alarmed, this has been a long time coming. It's been almost 4 years,
and by the time this is deployed it will probably have been 4 years.
For those who just realised their script is still using it, or if you read this
later to fix someone else's script that just broke (hello future, did the world
end in 2012?), I'll briefly describe two migration paths you can take from
here:
== Feature detection
In most (if not all) cases of people using $.browser it is because they want
different behaviour for browsers that don't support a certain something. Please
take a minute to look at the code and find out what it is you are special-casing
for that apparently doesn't work in a certain browser.
Research on the internet and look for a way to detect this properly (examples
below). Browser detection (instead of feature detection) is not reliable, nor is
it very effective. For example, Internet Explorer has changed a lot since IE6.
Blindly doing A for IE and B for non-IE isn't very useful anymore as most (if
not all) of the new features will work fine in IE8, IE9 or IE10.
The opposite is also true. If you do something cool for Chrome, you're missing
other WebKit-based browsers that should get the same awesomeness (Safari,
Chromium, iPhone/iPod/iPad, possibly Android, Flock, etc.) these all share the
exact same engine that backs Chrome). And what if Firefox and IE also start to
support this new awesome feature?
There are many ways to do feature detection. jQuery comes with various detectors
built-in in the object "jQuery.support"[2]. This contains for example "support.ajax",
"support.opacity" and many more[2]. You can also easily make your
own feature detector:
* var supportPlaceholder = 'placeholder ' in document.createElement('input');
* var supportJSON = !!window.JSON;
etc.
If you need any help with feature detection, I'd recommend asking in one
of the following channels on irc.freenode.net:
* ##javascript (recommended)
* #jquery
* #wikimedia-dev
== jQuery.client [3]
If you can't figure out how to detect what you really want to switch for, there
is an elaborate plugin in MediaWiki that does the same thing that jQuery.browser
used to do (and more). This can be used as an alternative migration path. To
give an impression:
> jQuery.browser
< {
chrome: true,
version: "22.0.1229.94",
webkit: true
}
> $.client.profile();
< {
name: "chrome",
layout: "webkit",
layoutVersion: 537,
platform: "mac",
version: "22.0.1229.94",
versionBase: "22",
versionNumber: 22
}
For example:
if ( $.browser.chrome ) {}
Would become:
++ dependency: jquery.client
var profile = $.client.profile();
if ( profile.name === 'chrome ) {}
But:
if ( $.browser.msie ) {
// IE doesn't support opacity
el.style.filter = 'alpha(opacity=50)';
} else { .. }
Should become:
if ( $.support.opacity ) {
el.style.filter = 'alpha(opacity=50)';
} else { .. }
Or better yet, since this is supported by jQuery core for a while now, like
this:
$(el).css('opacity', 0.5);
Which will do the right thing for newer browsers and old IE respectively.
-- Krinkle
[1] http://api.jquery.com/jQuery.browser/
[2] http://api.jquery.com/jQuery.support/
[3] https://www.mediawiki.org/wiki/RL/DM#jQuery.client