MediaWiki-l December 2014

mediawiki-l@lists.wikimedia.org

40 participants
38 discussions

BlueSpice for MediaWiki 2.23.0 released
by Markus Glaser 10 Dec '14

10 Dec '14

Hello everyone, I am happy to announce the release of BlueSpice free 2.23.0. This MediaWiki enterprise distribution is also used by many non-profit wikis in the web. You can find more information on the new release here: English: http://wp.me/p1L9lX-kr German: http://wp.me/pEDy7-S3 Download on Sourceforge: http://sourceforge.net/projects/bluespice/#BlueSpice Installer version: http://sourceforge.net/projects/bluespice/files/?source=navbar Hopefully others will find this useful as well. Feedback and contributions are highly welcome. Best regards, Markus

1 0

HHVM and 1.23 LTS?
by David Gerard 09 Dec '14

09 Dec '14

So I'm looking at the CPU graphs for the Wikimedia clusters before and after the switch to HHVM, and I'm going "oh my goodness, I'd like that thanks". rationalwiki.org is on 1.19 and I need to get off my backside and upgrade it to 1.23 (only been putting it off approximately since 1.23 came out). (We're sticking to LTS releases for sanity and hit-by-a-bus factor.) I'd quite like to reduce load on the box by that much. 0. Has anyone else tried this? 1. How hard is it to set up MediaWiki to run in HHVM? (is there a handy guide on mediawiki.org?) 2. What should I expect if I try to run 1.23 on HHVM? 3. We have fiddly custom extensions, so what I'll probably do is convert to 1.23 on Zend mod_php, make sure everything's behaving, *then* convert to HHVM. Just how good is HHVM's PHP coverage? What should I expect? I understand it's really very good ... 4. What's memory consumption like? - d.

3 3

drawing toolbar
by Poopak Alaeifar 08 Dec '14

08 Dec '14

Hi there I am looking for an extension to add a drawing toolbar to mediwiki edit pages, NOT coding just toolbar.I have added the SVG drawing but can not using it as i am receiving this message: "The page you requested is hosted by the Toolserver user brion, whose account has expired. Toolserver user accounts are automatically expired if the user is inactive for over six months. To prevent stale pages remaining accessible, we automatically block requests to expired content." I am not concern of using only SVG drawing any drawing toolbar can be helpful. so replies is highly appreciated. Regards,Poopak

2 7

Google Analytics event tracking
by Legault, Phillip [ITSUS] 04 Dec '14

04 Dec '14

I'm not seeing any google analytics event tracking stats Using the following version MediaWiki 1.23.6 Semantic MediaWiki 2.1 alpha Google Analytics Integration 2.1.0 Chameleon 1.1.3-alpha Does any know what the problem may be? Thanks for your help! Phil

1 0

Protocol relative image URLs with Pound and https
by Georg Schönberger 03 Dec '14

03 Dec '14

Hi Meadiawiki Team/Users, I am currently preparing our Mediawiki to run with HTTPS behind Pound and Varnish. The setup went very well so far but now I have troubles with getting mixed content on image urls. As Mediawiki is using protocol relative URLs (for images too?) I thought I don't have to setup much, if the protocol is detected correctly. Pound adds the 'HTTP_X_FORWARDED_PROTO' Header, and I've found the Mediawiki detection in includes/WebRequest.php: if ( ( isset( $_SERVER['HTTPS'] ) && $_SERVER['HTTPS'] == 'on' ) || ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) ) { return 'https'; Therefore I assume that protocol detection works correctly. I have also enabled $wgSecureLogin to see if protocol detection works, and as far as I can see it does. I have also run * echo $this->getRequest()->getProtocol(); on a Special Page, and this prints "https" even behind Pound. So Mediawiki should detect the Pound Header. But images are still used with <img alt="..." src="http://..">, even if the page is called with https://. Are any further steps to get images work with https? (e.g. set $_SERVER variables) Are images using protocol relative paths per default? I am using * Mediawiki 1.23.7 (987edf2) 09:58, 28 November 2014 Thanks a log, Georg Schönberger -- : Georg Schönberger : Web Operations & Knowledge Transfer : Thomas-Krenn.AG | The server-experts : http://www.thomas-krenn.com | http://www.thomas-krenn.com/wiki

1 1

[BREAKING CHANGE] Upcoming jQuery upgrade: Removing jQuery Migrate
by Krinkle 02 Dec '14

02 Dec '14

Hey all, TL;DR: * We did not make the breaking change last week for Wikimedia; it is postponed. * MediaWiki 1.24.0 will ship with jQuery Migrate switched off. * Wikimedia & non-Wikimedia wikis can enable jQuery Migrate if needed. * When MediaWiki 1.24 is released, we will switch off jQuery Migrate for Wikimedia wikis. As we said last month, we are upgrading MediaWiki's jQuery to version 1.11.x [1], which removes some long-deprecated functions. These were done in phase one [2] and two [3] as of last week. However, we have held off with phase 3 (removing the jQuery Migrate plugin) for a while to give migration a little more time. The amount of migration work necessary has been much less than I anticipated. Very few scripts have actually needed changing, probably because these features have been deprecated for quite a while now. Some of newer developers may never have even known of these APIs. Having said that, it does take a while for a message like this to spread out to some members of our large community. While those wiki scripts and gadgets which have active maintainers have been looked into, and (where needed) updated accordingly, a large number of gadgets and scripts in the cluster of Wikimedia wikis have not yet had a chance to get a grip on this, let alone extensions and wikis outside of Wikimedia. While I don't want to set another deadline, I think it makes sense to ship the jQuery Migrate plugin for one release (with MediaWiki 1.24), and then remove it in MediaWiki 1.25. This will give all wikis' communities and extension authors a few more months until the MediaWiki 1.24 branch point (in Autumn 2014) before they will need to make adjustments to work with MediaWiki master. MediaWiki 1.24.0 stable will disable support for legacy jQuery by default. If you find you have scripts, gadgets or extensions still using legacy jQuery APIs, you can enable them with a simple line in LocalSettings.php: $wgIncludejQueryMigrate = true; And of course when you find you need to do this, please make an effort to ensure the maintainers of those items still using these legacy features are aware of this so they may patch the code accordingly (using the upgrade guide[4] and my earlier announcement [5]). When MediaWiki 1.24 is released, we will switch off jQuery Migrate for Wikimedia wikis. — Krinkle [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44740 [2] https://gerrit.wikimedia.org/r/#/c/131494/ [3] https://gerrit.wikimedia.org/r/#/c/133477/ [4] http://jquery.com/upgrade-guide/1.9/ [5] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg75735.html On 7 May 2014, at 18:29, Krinkle <krinklemail(a)gmail.com> wrote: > Hey all, > > TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This > major release removes deprecated functionality. Please migrate away from this > deprecated functionality as soon as possible. > > It's been a long time coming but we're now finally upgrading the jQuery package > that ships with MediaWiki. > > We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple > of years ago due to lack of time and concern about disruption. Because of this, > many developers have needed to work around bugs that were already fixed in later > versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been > the first release in jQuery history that needed an upgrade guide[1][2]. It's a > major release that cleans up deprecated and dubious functionality. > > Migration of existing code in extensions, gadgets, and user & site scripts > should be trivial (swapping one method for another, maybe with a slight change > to the parameters passed). This is all documented in the upgrade guide[1][2]. > The upgrade guide may look scary (as it lists many of your favourite methods), > but they are mostly just addressing edge cases. > > == Call to action == > > This is a call for you, to: > > 1) Get familiar with http://jquery.com/upgrade-guide/1.9/. > > 2) Start migrating your code. > > jQuery v1.9 is about removing deprecated functionality. The new functionality is > already present in jQuery 1.8 or, in some cases, earlier. > > 3) Look out for deprecation warnings. > > Once instrumentation has begun, using "?debug=true" will log jQuery deprecation > warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also > find deprecation notices from mediawiki.js, for more about those see the mail > from last October [8]. > > == Plan == > > 1) Instrumentation and logging > > The first phase is to instrument jQuery to work out all the areas which will > need work. I have started work on loading jQuery Migrate alongside the current > version of jQuery. I expect that to land in master this week [6], and roll out on > Wikimedia wikis the week after. This will enable you to detect usage of most > deprecated functionality through your browser console. Don't forget the upgrade > guide[1], as Migrate cannot detect everything. > > 2) Upgrade and Migrate > > After this, the actual upgrade will take place, whilst Migrate stays. This > should not break anything since Migrate covers almost all functionality that > will be removed. The instrumentation and logging will remain during this phase; > the only effective change at this point is whatever jQuery didn't think was > worth covering in Migrate or were just one of many bug fixes. > > 3) Finalise upgrade > > Finally, we will remove the migration plugin (both the Migrate compatibility > layer and its instrumentation). This will bring us to a clean version of latest > jQuery v1.x without compatibility hacks. > > > A rough timeline: > > * 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts. This > will run for 4 weeks (until June 9). > > * 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run for 3 > weeks (upto June 9). The instrumentation continues during this period. > > * 1 June 2014 (1.24wmf7) Finalise upgrade. > > > == FAQ == > > Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11? > > A: Those are regular updates that only fix bugs and/or introduce non-breaking > enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any > hassle. We'll be fast-forwarding straight from v1.8 to v1.11. > > > Q: What about the jQuery Migrate plugin? > > A: jQuery developed a plugin that adds back some of the removed features (not > all, consult the upgrade guide[2] for details). It also logs usage of these to > the console. > > > Q: When will the upgrade happen? > > A: In the next few weeks, once we are happy that the impact is reasonably low. > An update will be sent to wikitech-l just before this is done as a final reminder. > This will be well before the MediaWiki 1.24 branch point for extension authors > looking to maintain compatibility. > > > Q: When are we moving to jQuery v2.x? > > A: We are not currently planing to do this. Despite the name, jQuery v2.x > doesn't contain any new features compared to jQuery v1 [3]. The main difference > is in the reduced support for different browsers and environments; most > noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which > MediaWiki is still supporting for now, and is outside the scope of this work. > Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new > features. For example, jQuery released v1.11 and v2.1 together[4][5]. > > -- Krinkle > > [1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate- > final-released/ > [2] http://jquery.com/upgrade-guide/1.9/ > [3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/ > [4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/ > [5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/ > [6] https://gerrit.wikimedia.org/r/131494 > [7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md > [8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html > [9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap >

1 1

TOC links
by Legault, Phillip [ITSUS] 01 Dec '14

01 Dec '14

Table of Contents Is there something I have done wrong? When I select a link in the TOC it goes past the heading a couple of lines. Is this normal? Thank you for your help! Phil Legault

1 1

MediaWiki Language Extension Bundle 2014.11 release
by Kartik Mistry 01 Dec '14

01 Dec '14

Hello all, I would like to announce the release of MediaWiki Language Extension Bundle 2014.11. This bundle is compatible with MediaWiki 1.23.7 and MediaWiki 1.24.0 releases. It should also work with 1.22.14 but we no longer test against it. * Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2014.11.tar… * sha256sum: 39b397a05561f743962cfb499f59a58219338607ea13ebfcc7a8806105e7dedc Quick links: * Installation instructions are at: https://www.mediawiki.org/wiki/MLEB * Announcements of new releases will be posted to a mailing list: https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n * Report bugs to: https://phabricator.wikimedia.org/ * Talk with us at: #mediawiki-i18n @ Freenode Release notes for each extension are below. -- Kartik Mistry == Babel, CleanChanges and LocalisationUpdate == * Only localisation updates. == CLDR == * Fixed some time displays if CLDR had only partial localisation of time units. == Translate == * Translate WebAPI documentation is now localized. Only works in MediaWiki 1.24 and newer. * Fixed a bug which prevented bootstrapping of shared TTMServer database with the ElasticSearch backend. * If you are using the '''Solr backend '''for the translation memory or the translation search, please let us know. If there are no users for the Solr backend, we will deprecate and later remove it in favor of the better maintained ElasticSearch backend. == UniversalLanguageSelector == * ULS WebAPI documentation is now localized. Only works in MediaWiki 1.24 and newer. * T67516: Removed font-size for ULS language selection panel buttons, which caused tiny font sizes on the Monobook skin. * Small compatibility fix when both ULS and VisualEditor are in use. * About 20 new languages are now supported in the language selector and a couple language names were changes. * A JavaScript error no longer happens on pages without any headings. * Added support for WOFF2 webfont format. Note that there are no WOFF2 webfonts in the font repository yet due to pending issues in WOFF2 font generation. Thanks! -- Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_ {kartikm, 0x1f1f}.wordpress.com

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l December 2014