Wikitech-l June 2019

wikitech-l@lists.wikimedia.org

54 participants
60 discussions

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 27 Jun '24

27 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

Research FAQ gets a facelift
by Dario Taraborelli 25 Jun '24

25 Jun '24

We just released a new version of Research:FAQ on Meta [1], significantly expanded and updated, to make our processes at WMF more transparent and to meet an explicit FDC request to clarify the role and responsibilities of individual teams involved in research across the organization. The previous version – written from the perspective of the (now inactive) Research:Committee, and mostly obsolete since the release of WMF's open access policy [2] – can still be found here [3]. Comments and bold edits to the new version of the document are welcome. For any question or concern, you can drop me a line or ping my username on-wiki. Thanks, Dario [1] https://meta.wikimedia.org/wiki/Research:FAQ [2] https://wikimediafoundation.org/wiki/Open_access_policy [3] https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953 *Dario Taraborelli *Head of Research, Wikimedia Foundation wikimediafoundation.org • nitens.org • @readermeter <http://twitter.com/readermeter>

2 1

bluejeans
by Jeremy Baron 22 Feb '23

22 Feb '23

Hi, On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote: > We will be holding this brownbag in 25 minutes. The Bluejeans link has > changed: > > https://bluejeans.com/396234560 I'm not familiar with bluejeans and maybe have missed a transition because I wasn't paying enough attention. is this some kind of experiment? have all meetings transitioned to this service? anyway, my immediate question at the moment is how do you join without sharing your microphone and camera? am I correct thinking that this is an entirely proprietary stack that's neither gratis nor libre and has no on-premise (not cloud) hosting option? are we paying for this? -Jeremy

9 16

New DB_REPLICA constant; DB_SLAVE deprecated
by Aaron Schulz 04 Jul '20

04 Jul '20

As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA instead of DB_SLAVE, with the old constant left as an alias. This is part of a string of commits that cleaned up the mixed use of "replica" and "slave" by sticking to the former. Extensions have not been mass converted. Please use the new constant in any new code. The word "replica" is a bit more indicative of a broader range of DB setups*, is used by a range of large companies**, and is more neutral in connotations. Drupal and Django made similar updates (even replacing the word "master"): * https://www.drupal.org/node/2275877 * https://github.com/django/django/pull/2692/files & https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023… I don't plan on doing anything to DB_MASTER, since it seems fine by itself, like "master copy", "master tape" or "master key". This is analogous to a master RDBMs database. Even multi-master RDBMs systems tend to have a stronger consistency than classic RDBMs slave servers, and present themselves as one logical "master" or "authoritative" copy. Even in it's personified form, a "master" database can readily be thought of as analogous to "controller", "governer", "ruler", lead "officer", or such.** * clusters using two-phase commit, galera using certification-based replication, multi-master circular replication, ect... ** https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_… *** http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium… -- -Aaron

4 3

Dealing with composer dependencies in early MediaWiki initialization
by Kunal Mehta 19 Jul '19

19 Jul '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I (with Reedy's help) recently started work on librarizing MediaWiki's IP class into a separate composer package (wikimedia/ip-utils[1]). The main motivation was so that the Parsoid PHP port could use it[2]. However, I ran into an unexpected hitch[3], as it seems we're using the IP class before the composer autoloader is even intialized. Here's the basic initialization in Setup.php: - - AutoLoader.php (MediaWiki's) - - Defines.php - - DefaultSettings.php - $wgServer = WebRequest::detectServer() - Calls IP::splitHostAndPort() - - GlobalFunctions.php - - vendor/autoload.php (composer's) My understanding is that composer's autoloader runs late so extensions registering themselves using it can add their stuff to the necessary globals. And we call WebRequest::detectServer() in DefaultSettings.php so that in LocalSettings.php people can use the value of $wgServer for other stuff. I see 3 main ways to move forward: 1. Move vendor/autoload.php earlier in Setup.php, potentially breaking extensions that still rely on composer autoloading for initialization. 2. Set $wgServer = false or something in DefaultSettings.php, and then fill it in later in Setup.php *after* the composer autoloader has been loaded, potentially breaking anyone relying on the value of $wgServer in LocalSettings.php. 3. (status quo) not librarize code that runs before composer autoloader initialization. :( Advice/input welcome. [1] https://packagist.org/packages/wikimedia/ip-utils [2] https://gerrit.wikimedia.org/g/mediawiki/services/parsoid/+/77064cfff717 6493a2828bb4f95f397dfce7d659/src/Utils/Title.php#46 [3] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/519089/ - -- Legoktm -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAl0S1oQACgkQ8QX4EBsF Jpufrg/+J9RUUxRAtgJLEkyACE6GREis0eyEIZnWmMr3s9YpFPoqtWocFrUk6Wsn W7d9Oda/8CW0/d894gGMn8LWIj9oWq2gMPWzCVFpg8uu3r4967qxBp+ba29uMOJw Qpw6DhXtPvVAeUCy8P38Y5vM7TGmV+J1T5jDY21zimT1dRrJsI1KD+u/Ue3nYy/y B1ic3i7vJfhYErdhHgN98ETXfXOaDx4rgd2N7PLjVNx3IYCC8LNiR8wSLuydfdbk PLTT1bA2qi0h2wgcEr7Qtq9YstVotq8899rgKLtGDBwQi3qGNcdOgQGEMFDVfjfO CsiWocj6s4oc3ScVj+Eb9xtvIqhNx+oRbWE1vKd4TmtSdyzpv6xadV60tq5qNFEY I0cBDOWU5UFNHbvbyjK4dqIDEVhJ6LiEgLVBOj81U27s8mR4Dv/yFB3eac0ROk7p gaEeOjfhtVU558XfpEsmu1H05VJT3kXNxK8y0UQOjy11SErzsXv6vDzyzLDJM/W7 WF0I4nyjeqVsBjLBN9li+5AnU3cAKVOCfZ+/aRYyg89Du//nJRjm+4lxnuPrGlaG ES/nVUnkDZ9Yc/xA1yacm3Ytx9hpoY1mIZgxxxveyeU1KsNXAZ2BOGA2T7kU4yUw Uyg+byYwI+1uVOjAVd3BInGV2R2/GmeIn9FOpthBaw8wcz0Y/8c= =tU4+ -----END PGP SIGNATURE-----

9 9

[Tech Talks] July 10, 2019, 4 PM UTC, A Deployment Pipeline Overview
by Subramanya Sastry 10 Jul '19

10 Jul '19

Hi Everyone, It's time for Wikimedia Tech Talks 2019 Episode 6! Next month's talk will take place July 10, 2019 at 4:00 PM UTC. Topic: A Deployment Pipeline Overview Speaker: Alexandros Kosiaris, Senior Operations Engineer Summary: The deployment pipeline project has been ongoing for a while, sometimes with more resources poured into it, sometimes less, but it's finally in a state that is ready to be used (it's already being used!). This tech talk is about a presentation to wider technical audiences, discussing the goals of the project, the implementation decisions and how it's meant to be used and adopted by the deployers of services (and eventually MediaWiki) in the coming months. YouTube stream for viewers: https://www.youtube.com/watch?v=i0FTcG7PxzI During the live talk, you are invited to join the discussion on IRC at #wikimedia-office Those in the SF office can watch this in R124. You can watch past Tech Talks here: https://www.mediawiki.org/wiki/Tech_talks If you are interested in giving your own tech talk, you can learn more here: https://www.mediawiki.org/wiki/Project:Calendar/How_to_schedule_an_event#Te… Subbu. (Standing in for Sarah Rodlund who is currently away on sabbatical)

1 2

今週あなたを幸せにするものは何ですか？ / What's making you happy this week? (Week of 16 June 2019)
by Pine W 30 Jun '19

30 Jun '19

While browsing Japanese Wikipedia, I found this <https://ja.wikipedia.org/wiki/%E4%BD%86%E9%A6%AC%E9%AB%98%E5%8E%9F%E6%A4%8D…> article with beautiful photos. Although I cannot read Japanese, my understanding from an automated translation is that the article describes the Tajima Highland Botanical Garden in Kami, Hyogo prefecture, Japan, and that there are over 2,000 types of plants in these gardens. The botanical garden article reminded me of an English Wikipedia featured article that I enjoyed reading, "*Bonshō* <https://en.wikipedia.org/wiki/Bonsh%C5%8D>". There is a series of photos of a high speed Japanese train that is under consideration for the Featured picture designation on English Wikipedia <https://en.wikipedia.org/wiki/Wikipedia:Featured_picture_candidates/N700_Se…>. By looking at the code for this nomination, I learned about the “frameless” parameter for images <https://www.mediawiki.org/wiki/Help:Images#Size_and_frame>, which I think is new to me. I am a low ranking novice in the subject of continuous integration in software development <https://en.wikipedia.org/wiki/Continuous_integration>, and I understand merely some of this email <https://lists.wikimedia.org/pipermail/wikitech-l/2019-June/092171.html>, but there appears to be good news regarding MediaWiki CI jobs. What’s making you happy this week? You are welcome to comment in any language. Pine ( https://meta.wikimedia.org/wiki/User:Pine )

7 10

New errors with composer update
by James Montalvo 29 Jun '19

29 Jun '19

I'm getting a new error today that was not happening with the identical config yesterday. With MW 1.31.1 and 1.31.2 I'm getting errors after installing dependencies and extensions with Composer. I have the following composer.local.json: ``` { "require": { "mediawiki/semantic-media-wiki": "3.0.0", "mediawiki/semantic-result-formats": "3.0.0", "mediawiki/semantic-compound-queries": "1.2.0", "mediawiki/sub-page-list": "1.5.0", "mediawiki/maps": "6.0.3", "pear/net_smtp": "1.8.0" <-- remove this when using MW 1.31.2 }, "extra": { "merge-plugin": { "include": [ "extensions/SyntaxHighlight_GeSHi/composer.json", "extensions/Elastica/composer.json" ] } } } ``` SyntaxHighlight_GeSHi and Elastica are both tracking their REL1_31 branches, which haven't changed in about a year. Despite that, yesterday running `composer update` caused no issues. Today I started getting the following error: ``` [Wed Jun 26 16:16:18.364715 2019] [php7:warn] [pid 12304] [client my.ip.add.ress:46156] PHP Warning: require(/opt/htdocs/mediawiki/vendor/composer/../jetbrains/phpstorm-stubs/PhpStormStubsMap.php): failed to open stream: No such file or directory in /opt/htdocs/mediawiki/vendor/composer/autoload_real.php on line 70, referer: https://example.com/ [Wed Jun 26 16:16:18.364896 2019] [php7:error] [pid 12304] [client my.ip.add.ress:46156] PHP Fatal error: require(): Failed opening required '/opt/htdocs/mediawiki/vendor/composer/../jetbrains/phpstorm-stubs/PhpStormStubsMap.php' (include_path='/opt/htdocs/mediawiki/vendor/pear/console_getopt:/opt/htdocs/mediawiki/vendor/pear/mail:/opt/htdocs/mediawiki/vendor/pear/mail_mime:/opt/htdocs/mediawiki/vendor/pear/mail_mime-decode:/opt/htdocs/mediawiki/vendor/pear/net_smtp:/opt/htdocs/mediawiki/vendor/pear/net_socket:/opt/htdocs/mediawiki/vendor/pear/pear-core-minimal/src:/opt/htdocs/mediawiki/vendor/pear/pear_exception:.:/usr/share/pear:/usr/share/php') in /opt/htdocs/mediawiki/vendor/composer/autoload_real.php on line 70, referer: https://example.com/ ``` Using MW 1.32.1 and 1.31.2 I did the following: ``` rm -f ./composer.lock && composer install && sudo systemctl reload httpd # no mention of phpstorm-stubs in output # page loads fail rm -f ./composer.lock && composer install --no-dev && sudo systemctl reload httpd # output includes: Removing jetbrains/phpstorm-stubs (dev-master) # page loads succeed (no phpstorm-stubs) composer install && sudo systemctl reload httpd # output includes: Installing jetbrains/phpstorm-stubs (dev-master 9d01ce3): Cloning 9d01ce3476 # page loads succeed (phpstorm-stubs @ 9d01ce3) composer update && sudo systemctl reload httpd # output includes: Updating jetbrains/phpstorm-stubs dev-master (9d01ce3 => 1b99060): Checking out 1b9906084d # page loads fail (phpstorm-stubs @ 1b99060) ``` I need the httpd reload to invalidate opcache in my config. Based upon the above it seems that the phpstorm-stubs that is getting required from non-dev dependencies doesn't have issues, but the one from dev dependencies does. Or perhaps something to do with Composer or with the Composer merge plugin is causing one version of phpstorm-stubs to be checked out but the autoloader to be setup for the other version. Any thoughts? Thanks, James

3 4

TechCom Radar 2019-06-26
by Kate Chapman 28 Jun '19

28 Jun '19

Hi All, Here are the minutes from this week's TechCom meeting: RFC approved: REST route handler extension interface RFC <https://phabricator.wikimedia.org/T221177> RFC on Last Call: Introduce a new namespace for collaborative judgements about wiki entities <https://phabricator.wikimedia.org/T200297> (ending July 6th 05:00 UTC/07:00 CEST/July 5 22:00 PDT) IRC meeting next week in #wikimedia-office Abstract schemas and schema changes: <https://phabricator.wikimedia.org/T191231> (note new time: July 3 2019 14:00 UTC/15:00 CEST/06:00 PDT) You can also find our meeting minutes at <https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes> See also the TechCom RFC board <https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>. If you prefer you can subscribe to our newsletter here <https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar> Thanks, Kate -- Kate Chapman Senior Program Manager, Core Platform Wikimedia Foundation kchapman(a)wikimedia.org

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l June 2019