MediaWiki-l November 2019

mediawiki-l@lists.wikimedia.org

11 participants
14 discussions

RE: [Mediawiki-l] Re: How to create a new Special page
by Bart Q. Simon 26 Nov '25

26 Nov '25

I distinctly remember there was a way to add a title to a special page simply by entering in a URL, then adding the title to the wiki edit field, and then saving. The new "writing a new special page" how-to is very confusing - and it wants me to write PHP to get the title to show up. There was an easier way... I can't find this how-to anywhere- though I'm sure it used to exist. FX can you walk me through how you've added a wiki page title to a special page? Thanks! -----Original Message----- From: mediawiki-l-bounces(a)Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org] On Behalf Of Rick DeNatale Sent: Thursday, May 19, 2005 2:33 PM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] Re: How to create a new Special page On 5/13/05, FxParlant <f-x.p(a)laposte.net> wrote: > Hello; > There is a paragraph on how to create a special page in the FAQ > > > http://meta.wikimedia.org/wiki/Meta:FAQ#How_do_I_add_my_own_dynamic_cont ent_to_MediaWiki.3F > > It's not so difficult. At the end,it says you have to create a simple > page and write the name of your special page in it. If you forget this > the title of your special page will have < and > around. I haven't > got a clue why creating a page with the name in it solves this, but it works That page seems to have changed, it now just has a pointer to an article about writing an extension which really doesn't seem to build a special page. I just figured out how to build a new special page which is like the Uncategorized pages page, but looks at the Image namespace. I wrote it up at http://meta.wikimedia.org/wiki/Writing_a_new_special_page _______________________________________________ MediaWiki-l mailing list MediaWiki-l(a)Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

3 2

Are there any good resources for writing scripts and gadgets
by Arcane 21 25 Nov '25

25 Nov '25

I'm currently trying to adapt several gadgets that are meant for wikis using the Monobook/Vector skins to the Monaco skin, and so far, I've managed to successfully port over the UTC Clock gadget and Sandbox page gadget to Monaco, but aside from those I've been having trouble since, frankly, my knowledge of Javascript/JQuery is slim and I'm not familiar with all the variables used in writing user scripts. I've fairly decent with CSS style sheets, but I still need help with Javascript, so does anyone know of some good resources I could look into, preferably tailored for writing scripts on MediaWiki? Also, if anyone wants to see what I have done so far (and have released publicly), the wiki I have been testing my live gadget/user script code on is here: https://mediawikitesters.orain.org/wiki/Main_Page

4 3

Recent parser change regarding tildes in comments?
by Thomas Dalton 17 Aug '25

17 Aug '25

Has the parser just been changed with regards to tildes (~~~~) inside HTML comments? It appears they used to be ignored, and are now suddenly being replaced en masse the next time someone edits the page (and can't be easily reverted - it just changes the sig to the reverter's instead). See http://en.wikipedia.org/wiki/Wikipedia:Articles_for_creation/2006-06-02-ear… for an example.

4 3

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

upgrading default password hashing algorithm
by Kevin Zhang 30 Nov '19

30 Nov '19

I noticed that MediaWiki 1.33 includes a stronger hash algorithm (argon2) yet the default password algorithm in use is still pbkdf. The manual page is not updated for this. Does anyone know how to safely convert? Is it advisable to attempt changing to this new hash algorithm? Thanks, Kevin

2 1

(no subject)
by Stevie Schreibvogel 29 Nov '19

29 Nov '19

thank you #srs

1 0

Re: [MediaWiki-l] MediaWiki-l Digest, Vol 194, Issue 9
by Silliam 19 Nov '19

19 Nov '19

Dear Yaron, Uncharted charting territory - very exciting! Thank you for the solution! Absolutely did the trick. -Billy ------ Original Message ------ From: mediawiki-l-request(a)lists.wikimedia.org To: mediawiki-l(a)lists.wikimedia.org Sent: 11/19/2019 5:00:04 AM Subject: MediaWiki-l Digest, Vol 194, Issue 9 >Send MediaWiki-l mailing list submissions to >mediawiki-l(a)lists.wikimedia.org > >To subscribe or unsubscribe via the World Wide Web, visit >https://lists.wikimedia.org/mailman/listinfo/mediawiki-l >or, via email, send a message with subject or body 'help' to >mediawiki-l-request(a)lists.wikimedia.org > >You can reach the person managing the list at >mediawiki-l-owner(a)lists.wikimedia.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of MediaWiki-l digest..." > > >Today's Topics: > > 1. Re: Page Forms multiple-instance coordinate entry (Yaron Koren) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 18 Nov 2019 09:54:34 -0500 >From: Yaron Koren <yaron(a)wikiworks.com> >To: MediaWiki announcements and site admin list > <mediawiki-l(a)lists.wikimedia.org> >Subject: Re: [MediaWiki-l] Page Forms multiple-instance coordinate > entry >Message-ID: > <CAGmQEQH3DQ0bTNgB4XNLpO1-13hPSpWvckkJ5Qa4aVmwzjUWcQ(a)mail.gmail.com> >Content-Type: text/plain; charset="UTF-8" > >Hi Billy, > >Sorry about that problem. You might be the first person who's tried having >map inputs within a multiple-instance template... at least, I haven't heard >of someone doing that before, I don't think. > >Anyway, you did uncover a real bug. I just checked in a fix for this, so if >you get the latest Page Forms code, it will hopefully work better. Please >let me know if you run into any issues after updating the code. > >-Yaron > >On Fri, Nov 15, 2019 at 4:15 PM Billy Sims <500cents700(a)gmail.com> wrote: > >> Hello, >> Has anyone run into issues with using map-picker coordinate entry on a Page >> Forms form with a multiple-instance template ? All three openlayers, >> leaflet, and googlemaps input types work wonderfully until the "multiple" >> parameter is added. Once added, leaflet and openlayers display an >> unresponsive map box in which the map visuals are offset and frozen, while >> googlemaps displays a grey, unresponsive map box. >> >> My best guess is that there is a conflict with the javascript loading the >> map feature first and then handling the multiple instance button. Perhaps >> this would also explain the offset map image (which would seem to be >> properly placed for a single-instance item) >> >> Any help/guesses/solutions are much appreciated! >> >> *SMW 3.1.0* >> >> >> >> *MediaWiki 1.33.1PHP 7.2.24 (litespeed)MariaDB 10.1.40-MariaDB-cll-lveICU >> 63.1* >> >> (and incidentally, though I don't think this is an issue, I'll mention the >> template used generates a subobject in which the coordinates are to then be >> stored. >> >> Best, >> Billy >> _______________________________________________ >> MediaWiki-l mailing list >> To unsubscribe, go to: >>https://lists.wikimedia.org/mailman/listinfo/mediawiki-l >> > > >-- >WikiWorks · MediaWiki Consulting · http://wikiworks.com > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >MediaWiki-l mailing list >MediaWiki-l(a)lists.wikimedia.org >https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > > >------------------------------ > >End of MediaWiki-l Digest, Vol 194, Issue 9 >*******************************************

1 0

Page Forms multiple-instance coordinate entry
by Billy Sims 18 Nov '19

18 Nov '19

Hello, Has anyone run into issues with using map-picker coordinate entry on a Page Forms form with a multiple-instance template ? All three openlayers, leaflet, and googlemaps input types work wonderfully until the "multiple" parameter is added. Once added, leaflet and openlayers display an unresponsive map box in which the map visuals are offset and frozen, while googlemaps displays a grey, unresponsive map box. My best guess is that there is a conflict with the javascript loading the map feature first and then handling the multiple instance button. Perhaps this would also explain the offset map image (which would seem to be properly placed for a single-instance item) Any help/guesses/solutions are much appreciated! *SMW 3.1.0* *MediaWiki 1.33.1PHP 7.2.24 (litespeed)MariaDB 10.1.40-MariaDB-cll-lveICU 63.1* (and incidentally, though I don't think this is an issue, I'll mention the template used generates a subobject in which the coordinates are to then be stored. Best, Billy

2 1

[Cargo] table format for _pageData and _fileData
by Jan Böhme 12 Nov '19

12 Nov '19

Hi, for our production system I’m using a MariaDB Galera cluster as RDMS backend. Though there is a feature to enable (experimental) replication of MyISAM tables, this doesn't play well with Cargo. Certain operations involving _pageData tables caused the cluster to reach an inconsistent data state, thus stopping replication and ultimately falling apart. I could isolate the cause to the following transaction (which is embedded between two inserts for the same thing): BEGIN /* Wikimedia\Rdbms\Database::begin */ SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE 'cargo\_\_staff\_\_NEXT' SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE 'cargo\_\_staff\_\_\_files' DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo__staff` WHERE `_pageID` = '273' DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo___pageData` WHERE `_pageID` = '273' COMMIT /* Wikimedia\Rdbms\Database::commit */ cargo__staff table being InnoDB, cargo___pageData being MyISAM. Unfortunately this leads to the delete statement on the InnoDB table not being replicated, while the delete on the MyISAM table is. Thus on the following insert the row already exists, causing a unique key violation and inconsistent cluster state. Is it really still necessary to use MyISAM for these tables? Full text indices are available on InnoDB for quite some time now, so I’m wondering whether this still needs to be supported or if it would be possible to make both choices available. Best: Jan. -- idea-sketch Jan Böhme & Uwe Schützenmeister Lößnitzstr. 14 01097 Dresden www.idea-sketch.com <http://www.idea-sketch.com/> Tel.: +49 . (0)351 . 810 74 250 Mobil: +49 . (0)179 .53 41 641

2 2

Re: [MediaWiki-l] MediaWiki-l Digest, Vol 194, Issue 5
by toàn vlogs 09 Nov '19

09 Nov '19

Huutoanbui3(a)gmail.com Toi chua nhan duoc mot khoan tien nao ca .neu nhu muon hop tac lau dai thi xin mong la moi nguoi hay lam ciec theo mot cach thuc te .va dung doi hoi nheu qua .xin cam on Vào 19:03 Th 7, 09 thg 11 2019 <mediawiki-l-request(a)lists.wikimedia.org> đã viết: > Send MediaWiki-l mailing list submissions to > mediawiki-l(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > or, via email, send a message with subject or body 'help' to > mediawiki-l-request(a)lists.wikimedia.org > > You can reach the person managing the list at > mediawiki-l-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of MediaWiki-l digest..." > > > Today's Topics: > > 1. Re: [Cargo] table format for _pageData and _fileData (Yaron Koren) > 2. GitHub's "Automated Security Fixes" have been disabled on the > Wikimedia Org (Sam Reed) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 8 Nov 2019 11:00:38 -0500 > From: Yaron Koren <yaron(a)wikiworks.com> > To: MediaWiki announcements and site admin list > <mediawiki-l(a)lists.wikimedia.org> > Subject: Re: [MediaWiki-l] [Cargo] table format for _pageData and > _fileData > Message-ID: > <CAGmQEQFfb--cRyPLFZik63su2qM-Nk73+0jyT+hc= > zOjf39C+w(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Jan, > > Oh, that's too bad. I didn't know that MyISAM doesn't support database > clustering. (You might be the first person to run Cargo on a clustered > database - it's good to know that it seems to be working, other than this > one problem.) > > You're right that the MyISAM requirement is only for old database versions > - the last version of MySQL that had this problem was 5.6, and that version > came out in 2013, and will stop being supported in a little over a year. I > could have added a new setting like > $wgCargoUseMyISAMForTablesWithSearchtextFields, but that seemed like > overkill, so I decided instead to just remove this code that forces the use > of MyISAM. Hopefully there aren't too many people who (a) are using Cargo > with MySQL <= 5.6 (or its MariaDB equivalent), (b) use InnoDB by default, > (c) use the _pageData or _fileData tables, and (d) will recreate these > tables in the future. If there are, they'll have to either manually re-add > this code in, or update to a more recent DB version. > > Anyway, if you get the latest version of the Cargo code, and recreate these > tables, the problems will hopefully be gone. > > -Yaron > > On Fri, Nov 8, 2019 at 6:52 AM Jan Böhme <jan(a)idea-sketch.com> wrote: > > > Hi, > > > > for our production system I’m using a MariaDB Galera cluster as RDMS > > backend. Though there is a feature to enable (experimental) replication > of > > MyISAM tables, this doesn't play well with Cargo. Certain operations > > involving _pageData tables caused the cluster to reach an inconsistent > data > > state, thus stopping replication and ultimately falling apart. > > > > I could isolate the cause to the following transaction (which is embedded > > between two inserts for the same thing): > > > > BEGIN /* Wikimedia\Rdbms\Database::begin */ > > SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE > > 'cargo\_\_staff\_\_NEXT' > > SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE > > 'cargo\_\_staff\_\_\_files' > > DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo__staff` WHERE > > `_pageID` = '273' > > DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo___pageData` > > WHERE `_pageID` = '273' > > COMMIT /* Wikimedia\Rdbms\Database::commit */ > > > > cargo__staff table being InnoDB, cargo___pageData being MyISAM. > > Unfortunately this leads to the delete statement on the InnoDB table not > > being replicated, while the delete on the MyISAM table is. Thus on the > > following insert the row already exists, causing a unique key violation > and > > inconsistent cluster state. > > > > Is it really still necessary to use MyISAM for these tables? Full text > > indices are available on InnoDB for quite some time now, so I’m wondering > > whether this still needs to be supported or if it would be possible to > make > > both choices available. > > > > > > Best: Jan. > > > > > > -- > > idea-sketch > > > > Jan Böhme & Uwe Schützenmeister > > Lößnitzstr. 14 > > 01097 Dresden > > > > www.idea-sketch.com <http://www.idea-sketch.com/> > > > > Tel.: +49 . (0)351 . 810 74 250 > > Mobil: +49 . (0)179 .53 41 641 > > > > _______________________________________________ > > MediaWiki-l mailing list > > To unsubscribe, go to: > > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > > > ------------------------------ > > Message: 2 > Date: Fri, 8 Nov 2019 18:42:37 -0700 > From: Sam Reed <reedy(a)wikimedia.org> > To: wikitech-l(a)lists.wikimedia.org, mediawiki-l(a)lists.wikimedia.org > Subject: [MediaWiki-l] GitHub's "Automated Security Fixes" have been > disabled on the Wikimedia Org > Message-ID: > <CAOCnLWYP_A9ugC+q3U= > mF70mFOhvWygdAea3ewxHdKoMCZEemg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Just a heads up that "Automated Security Fixes" have been disabled on the > Wikimedia GitHub org. See [1] > > The reason for this is that it generates pull requests on non canonical > repositories (ie where Gerrit is the default development location) that > require developers to close them. > > If this is a feature you want on your repo generally, because you > canonically develop on GitHub, you can re-enable these on your repo by > clicking the "Security" tab, and then selecting "Automated Security Fixes" > in the top right corner. See [2] for more info. If you do develop > canonically in GitHub, please let us know at [3]. > > Note, this doesn't affect the security alerts related to outdated packages > etc in a repo. > > Thanks! > > > Sam > > [1] https://phabricator.wikimedia.org/T237337 > [2] > > https://help.github.com/en/github/managing-security-vulnerabilities/configu… > [3] https://phabricator.wikimedia.org/T237470 > [4] > > https://help.github.com/en/github/managing-security-vulnerabilities/viewing… > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > MediaWiki-l mailing list > MediaWiki-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l > > > ------------------------------ > > End of MediaWiki-l Digest, Vol 194, Issue 5 > ******************************************* >

1 0

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 November 2019