Cristian Consonni | 1 Aug 00:39 2014
Picon

Spam filter rules on the Wiki Loves Monuments Mailing list not working

Hi all,

(not really sure this is the right place, please redirect me if needed)

Togheter with Effeietsanders I am administering the
wikilovesmonuments-l mailing list[0].
This list is receiveing huge amounts of spam messages (quick
stat: we are talking about 20 messages per hour).

We have tried to implement some spam filter rules following this[1] (a
page which I have edited myself) but basically we were unable to get
any effect of sorts.

Here's the two spam filtering rules I have created:
* Rule 1: X-Spam-Score: [+]{2,99}
* Rule 2: X-Spam-Score: [*]{2,99}

I have added both rules with "+" and "*" to be sure, and I have
specified the numbers (more or equal than 2 and less or equal than 99)
because in my first try the rule with just {2,} (i.e. "more or equal
than 2") was not working.

The fact is that the solution didn't work out in the end (we were
still holding in our moderation queue lots and lots of messages with
an high spam score) and so we are
changing the default policy for the list about non-member messages
from "Hold" to "Reject" (If somebody can make a case for "Discard"
over "Reject" please do so).

This was quite frustrating, but we were unable to fix the problem is
(Continue reading)

Sumana Harihareswara | 31 Jul 13:44 2014
Picon

CentralNotice Caching Overhaul - Frontend Proxy meeting summary

Yesterday we had a wide-ranging discussion of
https://www.mediawiki.org/wiki/Requests_for_comment/CentralNotice_Caching_Overhaul_-_Frontend_Proxy
. We did figure out a few things -- for instance, ESI is very broken with
our currently deployed varnish; it's expected to be working for the 4
upgrade but that's a ways off. For more see the summary at
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-07-30#Meeting_summary
.

Matt is revising the RfC again before he takes off. Then Adam Wight and
Andrew Russell Green will most probably be in charge of it.

There's no online RfC meeting next week because of Wikimania; is anyone
planning a face-to-face architecture meeting at Wikimania?

Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Legoktm | 31 Jul 06:25 2014
Picon

ExtensionDistributor updates on mediawiki.org

Hi,

Tomorrow a major update[1] will be deployed for the ExtensionDistributor
extension on mediawiki.org. We will start fetching branch information
directly from Gerrit instead of relying on Github. Additionally,
tarballs will be served from extdist.wmflabs.org[2] instead of using Github.

There will be a few differences, namely that tarballs are only generated
every hour, instead of on the fly like Github did. These tarballs will
include submodules inside tarballs for extensions like VisualEditor (bug
44022[3]).

If you notice any issues or have any ideas for enhancements, please file
a bug in Bugzilla[4].

Additionally, I'd like to thank ^demon and YuviPanda for their help in
putting this service together.

-- Legoktm

[1] https://gerrit.wikimedia.org/r/#/c/149474/
[2] https://extdist.wmflabs.org/dist/
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=44022
[4]
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=ExtensionDistributor

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
(Continue reading)

Bartosz Dziewoński | 30 Jul 19:19 2014
Picon

Core and non-core skins finally at feature parity ($wgResourceModuleSkinStyles)

For the longest time, core skins had a big advantage: they could use the  
'skinStyles' parameter of a ResourceLoader module definition, in core's  
Resources.php file, to provide different looks for various built-in  
functionality. Non-core skin creators could achieve the same by putting  
the styles in main skin styles, but this has two big disadvantages: the  
styles would be loaded even if not needed on given page, and one often had  
to use ugly hacks to "reset" core styles.

With [1] merged, non-core skins can finally do the same, and do it right,  
using the new $wgResourceModuleSkinStyles global (akin to  
$wgResourceModules):

   // Module defined in core or some extension
   $wgResourceModules['bar'] = array(
     'scripts' => 'resources/bar/bar.js',
     'styles' => 'resources/bar/main.css',
   );

   // Styles defined in the skin
   $wgResourceModuleSkinStyles['foo'] = array(
     'bar' => 'skins/Foo/bar.css',
   );

Documentation is available at  
<https://www.mediawiki.org/wiki/Manual:$wgResourceModuleSkinStyles>.

I have already converted Vector to make use of this [2] and I am in the  
process of doing the same for Minerva [3][4] (the second patch still  
pending, reviews welcome) – MobileFrontend developers were forced to do  
some really bad things by the previous limitations ;)
(Continue reading)

Yuri Astrakhan | 29 Jul 23:33 2014
Picon

Do we have a universal font in production?

I'm trying to render an image which uses characters from all of the
languages supported by WP. Is there a single font deployed on production
servers that include all scripts? Any simple font would do, preferably TTF
arial-style.
Thanks!
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Rob Lanphier | 29 Jul 18:52 2014
Picon

Release Engineering team (new! improved!)

Hi everyone,

I’d like to announce an organizational change at Wikimedia Foundation
in the  Platform Engineering group.  For those that aren't terribly
interested in how WMF's org chart looks, you can skip the rest of this
email.  :-)

Yesterday, we formalized “Release Engineering” as a team, and promoted
Greg Grossmeier to “Release Team Manager” with everyone on the team
reporting to him.

In addition to Greg, the new team comprises:
* Antoine Musso
* Chris McMahon
* Dan Duvall
* Mukunda Modell
* Rummana Yasmeen
* Sam Reed
* Zeljko Filipin

They are broadly responsible for the lifecycle of code from the point
that a developer is ready to check it in through its deployment on our
site, maintaining the processes and tools that reduce negative user
impact of site software changes while simultaneously making software
change deployment efficient and joyful.

On a more detailed level, here’s just a few things the group is responsible for:
* Code and bug report hosting - currently Gerrit and Bugzilla, but in
the glorious future, Phabricator
* Test infrastructure - the team maintains the Beta Cluster, with help
(Continue reading)

Osama Khalid | 29 Jul 14:43 2014
Picon

Anyone with downloaded pagecount-raw dumps?

Hello Wikimanaias,

This is Osama Khalid, from the Arabic Wikipedia and Wikimedia Commons.

I was wondering whether anyone here has a good number of the raw
pagecounts downloaded so I can copy them to a hard disk during
Wikimania 2014.  They have been very helpful for me in trying to
determine which articles need the most attention, but my sample size
has always been too small since they are very huge and
dumps.wikimedia.org restricts parallel downloads.

If you have a bunch of them that you can bring it, please let me know.

Regards,
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Yury Katkov | 29 Jul 12:19 2014
Picon

MW+vagrant - js files loads with error

Hi!

I have the following setup: I develop on my local machine (PHPstorm) and I
save the files in one of the Vagrant shared folders. I load my js files
like that:
    public static function onBeforePageDisplay( OutputPage &$out, Skin
&$skin ) {
        $out->addModules("ext.Pydio");
    }

The thing is that sometimes after I make a change I see that my javascript
files is either not fully loaded (and I have undexpected end of file
error), or loaded with some invisible characters (\u0) right after the end
of the file (and I have "unexpected toke ILLEGAL" error). It looks like
this:
http://i.imgur.com/GGxtD89.png - my code in phpstorm
http://i.imgur.com/I8UR8Ly.png  - my error in Chrome developer tools

The javascript itself is totally ok. In fact the problem can appear even
when I just add a comment to the file.

My first thought was that it's vagrant shared folders bug. It doesn't seem
to be true - the file on the virtual machine looks normal.
Can it be the ResourceLoader issue? Did anyone see this behavior before?

Cheers,
-----
Yury Katkov
_______________________________________________
Wikitech-l mailing list
(Continue reading)

Greg Grossmeier | 29 Jul 01:23 2014
Picon

MediaWiki third-party release managers

I am pleased to announce (after far too long of a delay, my apologies),
that Mark Hershberger and Markus Glaser will take on the task of
managing the third-party releases of MediaWiki for another year.

Congrats Mark and Markus!

I'd like to explicitly thank the International Consortium team for their
proposal. The choice was indeed a hard one to make and I'm glad we had
the second proposal to add context and perspective to Mark's and
Markus's.

There will be a few changes to this work this coming year, mostly in
terms of transparency. Mark and Markus have agreed to conduct quarterly
reviews for their work and the output of those meetings will be publicly
shared. That means you'll (soon) be able to see the quarterly goals and
their progress. Also, we hope to see more collaboration between Mark and
Markus and the wider community in the supportive work; the work that
everyone can help with to make the releases as good as they can be.
We'll be monitoring this collaboration in review process over the course
of the year and we currently plan to call out collaboration goals in
next year's call for proposals.

I look forward to another year of working with Mark and Markus!

Best,

Greg

--

-- 
| Greg Grossmeier            GPG: B2FA 27B1 F7EB D327 6B8E |
(Continue reading)

Tyler Romeo | 28 Jul 22:34 2014
Picon

MediaWiki now supports PBKDF2 and Bcrypt

Hi everybody,

I was on the brink of celebrating the one-year anniversary of a patch I submitted being open, but today it was
finally merged!

https://gerrit.wikimedia.org/r/77645

The old User::comparePasswords() and User::crypt() functions have been replaced with a new password
hashing API. This means MediaWiki now natively supports Bcrypt and PBKDF2 as replacement password
hashing algorithms. Furthermore, the system allows seamless transitioning, meaning users’
password hashes will be updated automatically the next time they log in.

This means that MD5 is almost out the door, which is a big win (a follow up
patch, https://gerrit.wikimedia.org/r/149658, changes the default to PBKDF2, which would mean any
wiki that upgrades to 1.24 would automatically switch away from MD5).

I’d like to thank Aaron Schulz, Chris Steipp, Krinkle, and many others who helped get this through.

-- 
Tyler Romeo
0x405D34A7C86B42DF
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Bartosz Dziewoński | 28 Jul 20:53 2014
Picon

Moving Vector and MonoBook to separate repositories and what it means for you

tl;dr: I am going to break your workflow and your wiki. Skip to the
last section and read on.

== Background ==

As you know, I've been working on a GSoC project to better separate
skins and core MediaWiki [1]. Moving Vector and MonoBook to separate
repositories is the final step of it, and it's exactly as scary as it
sounds.

Until recently MediaWiki was heavily interconnected with the core
skins, particularly Vector – right now it is only slightly
interconnected and I have some patches pending to make it not so
at all [2].

[1] https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki
[2] https://gerrit.wikimedia.org/r/#/q/topic:skinning,n,z

== The plan ==

* Fix up some remaining issues with Vector being required
   (I have already fixed most)
* Stop always loading MonoBook and Vector
   [patch pending: https://gerrit.wikimedia.org/r/148509 + dependencies]
* Use a special fallback when no skins are installed
   [patch pending: https://gerrit.wikimedia.org/r/148508]
* Move MonoBook and Vector to separate repositories
* Ship MonoBook, Vector and some more skins with the installer tarball
* Enable them during the installation
   [patch merged: https://gerrit.wikimedia.org/r/138652]
(Continue reading)


Gmane