MediaWiki-l October 2016

mediawiki-l@lists.wikimedia.org

32 participants
27 discussions

Lis tes messages avant qu'ils ne soient effacés!
by Badoo 31 Dec '23

31 Dec '23

Lis ton message de Nganguem Victor avant qu'il ne soit effacé! Pour lire ton message, suis simplement ce lien: http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6 D'autres personnes sont aussi présentes: Oded (Tel Aviv, Israël) Priya (Udaipur, Inde) RajaYogi BK (Udaipur, Inde) Karuna (Udaipur, Inde) Chika Reginald Onyia (Pnompen', Cambodge) ...Qui d'autre? http://eu1.badoo.com/chatnoirxx/in/p4hxwt052ok/?lang_id=6 Les liens ne fonctionnent pas dans ce message? Copie les dans la barre d'adresse de ton navigateur. Tu as reçu cet email suite à un message envoyé par Nganguem Victor de notre système. S'il s'agit d'une erreur, ignore simplement cet email. La requête sera alors effacée du système. Amuse-toi bien ! L'équipe Badoo Courrier automatique de Badoo suite à l'envoi d'un message à ton attention sur Badoo. Les réponses ne sont ni stockées, ni traitées. Si tu ne veux plus recevoir de message de Badoo, fais-le nous savoir: http://eu1.badoo.com/impersonation.phtml?lang_id=6&mail_code=65&email=media…

3 2

Maps 3.8 has been released!
by Jeroen De Dauw 08 Nov '16

08 Nov '16

Hey all, I'm happy to announce the immediate availability of Maps 3.8. This feature release adds clustering and fullscreen support for Leaflet, a new OSM geocoder and support for the latest changes to the Google Maps API. You can read more about this release at https://www.entropywins.wtf/blog/2016/08/31/maps-3-8-for-mediawiki-released Cheers -- Jeroen De Dauw | https://entropywins.wtf | https://keybase.io/jeroendedauw Software craftsmanship advocate | Developer at Wikimedia Germany ~=[,,_,,]:3

5 5

freeloading off the community
by Greg Rundlett (freephile) 08 Nov '16

08 Nov '16

Wiki-site.com is a wiki hosting company, listed at https://en.wikibooks.org/wiki/Starting_and_Running_a_Wiki_Website/Hosted_Wi… Their "Support Contact" page [1] for paid wikis says: "For wiki management support, we've created a forum at the following address" (links to THIS list!!) Rami Addady, if you're listening, at least you should say something like "You can get help from the amazing community of MediaWiki software users and developers at their public discussion list" NOT "We've created a forum" What do you think? I've often wondered why some list questions seem like people are "demanding" support. Now I know it's because some companies literally tell their customers that this is their support desk. [1] http://www.wiki-site.com/index.php/Support_contact Greg Rundlett https://eQuality-Tech.com https://freephile.org

4 3

Follow Up:What Impact did the Mediawiki Stakeholders Wishlist of Features Have
by chris tharp 03 Nov '16

03 Nov '16

Hi All, As a lone tinker with Mediawiki, who pays some attention to things connected with it, I thought I would ask for a follow up to last year's Mediawiki Stakeholders survey (see: https://www.mediawiki.org/wiki/MediaWiki_Stakeholders%27_Group). An itemized wishlist of most requested features was made (see: https://www.mediawiki.org/wiki/MediaWiki_Stakeholders%27_Group/Tasks/Featur…) with the top four being: 1. Easier installation and upgrade (for both core and extensions). 2. Editing and Visual Editor 3. Skinning and UI 4. Access Controls and Rights I'm asking for this follow up because as far as I can tell little to no process has been made on these issues. Additionally in some ways it seems some things have gotten worse. But I'm hoping I'm wrong and someone with more knowledge will enlighten me. Here's some examples of things not improving, or getting worse: 1. Easier Installation and upgrade a. Three years after the death of the Extension Matrix there still is still no way to tell when a new extension is released. b. Composer is an easier way to install extensions, but for those without command line access it's a nightmare. c. The upgrade process is still the same 2. Visual Editor a. still a nightmare to install -- not in any sense is it an out of the box solution. b. On a shared host forget about the Visual Editor 3. Skinning and UI a. same as extensions -- no easy way to find out about new skins 4. Access Controls and Rights a. The most popular access control extension (Lockdown) only barely works in 1.27 and causes other extensions to not work: Visual Editor, MsUpload, and Upload Wizard (there's no doubt more). b. Almost every other access right extension is unmaintained. c. The two Semantic Mediawiki Access Right extensions are both unmaintained.SemanticACL does not work at all in 1.27. I know, or assume some of these things are being worked on, but still it seems the stakeholders feature wishlist is not being translated into action in anyway. So anyone know something I don't, or don't see on these issues? (Btw, this is not a knock on the hard working developers behind Mediawiki, and/or its extensions. But a desire to see if the desires of third-party users have any impact on the direction of software). Thanks Chris

3 3

OOjs UI help needed
by Huji Lee 03 Nov '16

03 Nov '16

Hello, I am trying to register two different window creation functions in OOjs UI but somehow they conflict with one another. The code is in [1] and you can use it like [2]. If you go to a page with sections (e.g. my talk page) you should see new links in the section heading called "add comment" and "close". The first time you click on each, the respective dialog will be shown. But whichever you click on first will only work once! So for instance, if you first click on "add comment" and then cancel the dialog, then click on "close" and cancel, now only "close" links will work (all of them) and none of the "add comment" links will show a dialog anymore. No error is logged in the console either. I am pretty sure it has to do with the way I am defining my objects, but I am not able to figure out what I am doing wrong. Please advise. Thanks, Huji [1] https://en.wikipedia.org/wiki/User:Huji/close.js [2] https://en.wikipedia.org/wiki/User:Huji/vector.js

2 2

prepared statements, MySQL, Database.php
by Tom Bishop, Wenlin Institute 01 Nov '16

01 Nov '16

The following code and comment appears in includes/db/Database.php: protected function prepare( $sql, $func = 'DatabaseBase::prepare' ) { /* MySQL doesn't support prepared statements (yet), so just * pack up the query for reference. We'll manually replace * the bits later. */ return array( 'query' => $sql, 'func' => $func ); } However, the MySQL 5.7 documentation indicates that prepared statements are supported: http://dev.mysql.com/doc/refman/5.7/en/sql-syntax-prepared-statements.html Is the comment in Database.php outdated, and if so, could MediaWiki be made more secure against SQL injection by supporting prepared statements with recent versions of MySQL? Or does the support already exist, in spite of the comment? Best wishes, Tom Wenlin Institute, Inc. SPC (a Social Purpose Corporation) 文林研究所社会目的公司 Software for Learning Chinese E-mail: wenlin(a)wenlin.com Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546) ☯

3 4

Re: [MediaWiki-l] Security of widgets? Way to limit parameters? OpenSeadragon
by Dr. Michael Bonert 31 Oct '16

31 Oct '16

Thanks for all the comments Bawolff and Daniel! They have confirmed the suspicion I had: using the 'Widget' extension is a way to insert something into Mediawiki... but it puts a hole into the security framework-- especially if you are passing parameters to the Widget. Broadly speaking, the Widgets seem to be an avenue to fulfill the needs of two different constituencies - (1) a constituency that wants to add things the WikiMedia Foundation (WMF) isn't going to develop 'cause it doesn't fit with their mission, and (2) a constituency to add things that the WMF hasn't prioritized but could be useful to the WMF. OpenSeadragon I think fits with the later... and it begs the question: How to generate enthusiasm for getting OpenSeadragon securely integrated into MediaWiki? At a functional level a deep zoom image (DZI) is an image... if implemented it might improve on the current paradigm of a small thumbnail-click for link to WikiCommons-click *again* for full resolution of image; in OpenSeadragon (as implemented with the widget) it is zoom with roller, click for fullscreen with OpenSeadragon. Once again thanks, Michael Quoting "Dr. Michael Bonert" <michael(a)librepathology.org>: [Hide Quoted Text] Hello, I was wondering about the security of Widgets ( https://www.mediawiki.org/wiki/Extension:Widgets ) that get parameters passed to them. Any thoughts? Are the parameters passed through to the widget cleansed of html/scripts? If it isn't -- is it possible to easily enforce typing/boundaries on the parameters? Generally, speaking, I am looking for a discussion around security & widgets. A widget I created (below) takes three parameters (width, height, filename) and feeds those to OpenSeadragon( https://openseadragon.github.io / https://en.wikipedia.org/wiki/Seadragon_Software ). It works on a testing server. OpenSeadragon was discussed in brain storming in 2015 - https://www.mediawiki.org/wiki/Reading/Quarterly_Brainstorming My interest in this is virtual (microscopic) slides (e.g. http://openslide.org/demo/ ) which are often several gigabytes of data each. Thanks, Michael ------------------------ Widget code... Create page: Widget:OpenSeadragon --------------------------------------------------------------------- <noinclude>__NOTOC__   To insert this widget, use the following code: <nowiki>{{#widget:</nowiki>{{PAGENAME}}<nowiki> |image=12881.dzi |width=800 |height=600 }}</nowiki> </noinclude> <includeonly> <div id="openseadragon1" style="width: px; height: px;"></div> <script src="../../openseadragon/openseadragon.min.js"></script> <script type="text/javascript"> var viewer = OpenSeadragon({ id: "openseadragon1", prefixUrl: "../../openseadragon/images/", tileSources: "../../vslide/" }); </script> </includeonly> ------------------------------------------------- Delete | Reply | Reply to All | Forward | Redirect | View Thread | Blocklist | Acceptlist | Message Source | Resume | Save as | Print Move | Copy Back to sent-mail < >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Michael Bonert, BASc (Mech Eng), MASc (Biomed Eng), MD, FRCPC Board Member and Founder Libre Pathology Limited Newfoundland and Labrador Email: michael(a)librepathology.org Mobile: 289 776-8722 Web: http://librepathology.org Twitter: http://twitter.com/librepathology +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

Security of widgets? Way to limit parameters? OpenSeadragon
by Dr. Michael Bonert 30 Oct '16

30 Oct '16

Hello, I was wondering about the security of Widgets ( https://www.mediawiki.org/wiki/Extension:Widgets ) that get parameters passed to them. Any thoughts? Are the parameters passed through to the widget cleansed of html/scripts? If it isn't -- is it possible to easily enforce typing/boundaries on the parameters? Generally, speaking, I am looking for a discussion around security & widgets. A widget I created (below) takes three parameters (width, height, filename) and feeds those to OpenSeadragon( https://openseadragon.github.io / https://en.wikipedia.org/wiki/Seadragon_Software ). It works on a testing server. OpenSeadragon was discussed in brain storming in 2015 - https://www.mediawiki.org/wiki/Reading/Quarterly_Brainstorming My interest in this is virtual (microscopic) slides (e.g. http://openslide.org/demo/ ) which are often several gigabytes of data each. Thanks, Michael ------------------------ Widget code... Create page: Widget:OpenSeadragon --------------------------------------------------------------------- <noinclude>__NOTOC__   To insert this widget, use the following code: <nowiki>{{#widget:</nowiki>{{PAGENAME}}<nowiki> |image=12881.dzi |width=800 |height=600 }}</nowiki> </noinclude> <includeonly> <div id="openseadragon1" style="width: px; height: px;"></div> <script src="../../openseadragon/openseadragon.min.js"></script> <script type="text/javascript"> var viewer = OpenSeadragon({ id: "openseadragon1", prefixUrl: "../../openseadragon/images/", tileSources: "../../vslide/" }); </script> </includeonly> -------------------------------------------------

3 6

The extensions CookiePolicy and CookieWarning has been merged into one extension CookieWarning
by Florian Schmidt 29 Oct '16

29 Oct '16

Hello list members! First of all: If you haven't used one of the extensions (CookieWarning[1] or CookiePolicy[2]) and don't plan to use one of them in the future, you can stop reading here :) tl;dr: The extension CookiePolicy is no longer available and was marked as archived, please use CookieWarning in the future. All functions of CookiePolicy was merged into CookieWarning. We found, that we'd two extensions, which aimed to solve the same problem. Both of them accomplished the goal in slightly different, but basically same, ways. That's why we decided to merge both extensions into one resulting extension. The goal of this merge process is/was to make it less confusing for users. The whole process is tracked in T145723[3] and it's subtasks. This e-mail is to inform you what happened and what you probably need to do now. First of all: As the phabricator task shows, all functions of CookiePolicy and CookieWarning are preserved in the resulting extension CookieWarning. However, if you switch to the CookieWarning extension from CookiePolicy, you'll need to adjust some settings. The same may apply to users of CookieWarning, who upgrade to a newer version.. So please make sure you reviewed the migration steps (available on the extension page of CookieWarning[4]) and the new configuration options, especially its default values. If you currently use CookiePolicy on your wiki, it's strongly suggested to switch to the new CookieWarning extension! Otherwise, you'll don't get any updates anymore. If you find any bugs or have feature requests, feel free to report them in phabricator[5]. For anyone who wants to submit a patch to CookiePolicy or CookieWarning, please make sure, that the mediawiki/extensions/CookiePolicy[6] project in gerrit was marked as read-only and does not accept any changes anymore. Please submit your changes to the mediawiki/extensions/CookieWarning[7] project. Thanks :) If you've any questions, feel free to answer to this e-mail, contact me in IRC or open a new thread on the talk page :) Have a nice weekend, Florian [1] https://www.mediawiki.org/w/index.php?title=Extension:CookieWarning&oldid=22 41035 [2] https://www.mediawiki.org/w/index.php?title=Extension:CookiePolicy&oldid=218 8043 [3] https://phabricator.wikimedia.org/T145723 [4] https://www.mediawiki.org/wiki/Extension:CookieWarning [5] https://phabricator.wikimedia.org/tag/mediawiki-extensions-cookiewarning/ [6] https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/CookieP olicy [7] https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/CookieW arning

1 0

Database Errors When Using Triggers in MariaDB
by Chris 28 Oct '16

28 Oct '16

Greetings, My work group runs a small inter-office wiki (MediaWiki) with a MariaDB backend. One of our side projects is to explore the possibility of integrating the wiki with one of our pre-existing information management systems. W were thinking that a database trigger could be used to call a stored procedure to export the data but we are running into problems implementing this solution. ==The Problem== Every time we try to implement a trigger, the MediWiki instance reports the following error: "A database query error has occurred. This may indicate a bug in the software." ==The Code== A slightly redacted version of the trigger: DELIMITER // CREATE TRIGGER [trigger name] AFTER UPDATE on text FOR EACH ROW BEGIN CALL [name of our stored procedure]; END; // DELIMITER; The stored procedure itself has been tested and functions properly but I am not able to share the code. All I can say is that it builds and executes prepared statements in the course of its operation. ==The Question== Has anyone else run into this problem? If so, what was the solution? Or am I bumping up against a database constraint that I am (obviously) unaware of? Thanks in advance for any replies! Sent from [ProtonMail](https://protonmail.ch) on my PDP-11

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l October 2016