@matmarex if I understand it correctly, this patch overrides any explicit size set in audio files and forces it to 120px. Thus, the following code doesn't work anymore:

[[File:Example.ogg|15px|noicon]]

(I'll obviate the noicon part) This would output just the play/stop button and omit the rest of the player's layout. Such a shrinked version of the player had a purpose on eswiktionary, now it's shown in full length.

Hi, @jcrespo, thank you for your quick response. I'm just starting to develop some simple tools for a relatively small project and their usage is still scarce. By now, I'll happily follow your recommendations, keep an eye on the resource usage and contact you if needed.

I've disabled connection pooling by enforcing the number of idle connections to zero with an immediate eviction. In case someone finds this useful, I'm putting here the specific <Resource> attributes in Tomcat's context.xml that had to be set (in my case) in order to disable pooling:

• minIdle="0"
• maxIdle="0"
• initialSize="0"
• minEvictableIdleTimeMillis="0"

@jcrespo in spite of that policy, would it be acceptable to keep a minimal pool of short-lived idle connections (let's say 1-5 minutes, only one idle connection per finished active connection), leaving it empty if there is no activity? Does said policy apply to databases created on the shared server (tools.labsdb), too? Are there any other configuration aspects related to resource saving that should be considered (e.g. maximum number of connections)?

I'm sorry, this shouldn't have happened. I've killed those processes and disabled any scripts and webapps that had access to that db until I fix this issue.

Thanks! I'm including this possibly relevant comment on IRC, the mentioned outage happened in June 2015 (I presume it was 20150617-LabsNFSOutage since I gained access to Labs on 19/06):

@coren: I hit a similar issue when trying to create a database with my tool (pbbot):

$ cat replica.my.cnf | grep user
user='s52584'
$ sql local
MariaDB [(none)]> create database s52584__test;
ERROR 1044 (42000): Access denied for user 's52584'@'%' to database 's52584__test'

Apparently, I don't have the necessary grants to perform this action (per http://dev.mysql.com/doc/refman/5.7/en/grant.html#idm139794624158480) despite what says the help page:

MariaDB [(none)]> show grants;
+-----------------------------------------------------------------------------------------------------------+
| Grants for s52584@%                                                                                       |
+-----------------------------------------------------------------------------------------------------------+
| GRANT SHOW VIEW ON *.* TO 's52584'@'%' IDENTIFIED BY PASSWORD '__EDITED__' |
| GRANT SELECT, SHOW VIEW ON `%\_p`.* TO 's52584'@'%'                                                       |
+-----------------------------------------------------------------------------------------------------------+
2 rows in set (0.02 sec)

I launched a forcerecursivelinkupdate purge API action on 03/10 at 02:40 UTC affecting all pages on plwiktionary, a smaller peak is clearly visible on Grafana right after that. The jobs counter of this project continued growing for the next days when it usually stops after a few hours. Could this have any connection?

@matmarex: I'm reopening, we have recently hit this issue on plwiktionary (report, answer). The steps to reproduce this are still the same:

1. Disable the preference Show edit toolbar.
2. Open any page in edit mode and try to insert a character contained in the Edittools box.
3. TypeError: mw.toolbar is undefined

I'm seeing this now on eswiktionary's entry güirro and there were confirmed cases on plwiktionary, too (reported in January).

In T126407#2014160, @Addshore wrote:

So as far as I can tell this is just about summaries?

See also T126139.

It turns out that the change-tags buttons and checkboxes are hidden through CSS on test.wikipedia. Sorry!

@lfaraone: just tested on test.wikipedia.org, I'm seeing these buttons on Special:Log even if no checkboxes are present (which is strange because even if I'm not allowed to revdel I should see the option to add/remove edit tags, now missing - possibly a regression?). BTW I wonder if the buttons could also apply to edit tags on history pages (right now the condition to be met is $user->isAllowed( 'deleterevision' ), this excludes non-sysops).

Possibly related code in Linker.php:

In T121047#1868381, @Rillke wrote:

Actually, it is pre-pended and I confirm this is a regression that has been recently added.

You are right, I watched [[Wikipedia:CatWatchTest]] and then it showed up on my watchlist (CatWatch is currently enabled on test WMF wikis, we'll have to wait for its arrival on eswikt). Thanks for investigating this issue :).

I have just noted that there are no logs of page additions/deletions to said category on my watchlist, not sure why. Other categories are shown there as expected.

It might be worth noting that Cite won't raise this kind of error unless a <references> tag is provided: with (error) and without (no error).

@Nemo_bis: this patch has introduced a stray newline character below the results list (pl.wikisource).

This seems to have been fixed with 1.26wmf24.

In T109638#1558652, @csteipp wrote:

@PeterBowman, are those IP addresses in the screenshots your own? Or do we need to remove those from this task before we make it public?

In T109638#1557384, @csteipp wrote:

@PeterBowman, can you link to the lua module that is being used for this?

The ts_rc_id column on the tag_summary table is empty for those revisions: http://quarry.wmflabs.org/query/3762.

Another issue I have encountered at the same time:

1. Navigate to the history page on which you have recently performed an API tagged edit (see #1 above, it seems to work on pre-23/05 edits), select that revision and click on Edit tags of selected revisions.
2. Remove the tag and apply changes. Nothing was changed, actually.

@Florian: the code on mediawiki.special.preferences.js#277 (204538) is not working as intended, there should be no parentheses:

Great, thanks!

I may have spotted another issue: expanding subcategories make other elements "jump" between columns, sometimes even the expanded entry itself. Test page, Firefox 36.
Before:

Related: T55918