Sorry to hijack, but since this thread is coming up on google for “disable mobile media viewer”, can I ask:

Change 479873 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] DateTimeInputWidget: Use 'clear' icon to clear input

I'm also having the same issue and my setup looks exactly the same. I am using Vagrant, https://meta.wikimedia.org/w/api.php as the schema api url, enabled EventLogging role and /vagrant/logs/eventlogging.log is empty.

Hello there，

Aha, the code is still in a pull request. I've left some comments, but basically this code needs more work. Is the Wikidata team aware of this project?

Looks good to me! Checked with this file: https://tools.wmflabs.org/svgtranslate-test/File:First%20Ionization%20Energy.svg

Before the new RC page (the makeover), the URL didn't used to change when you changed the limit. The limit from the URL was respected up to 5000. Ever since the RC makeover, the URL always displayed up to 1000, but the page did show up to 5000 recent changes (this inconsistency bugged me, but it wasn't a big deal). However, this ticket was raised when the 1000 hard limit was imposed, which I think doesn't make sense for smaller projects.

Change 479871 merged by Milimetric:
[analytics/wikistats2@master] Update tooltip text and infrastructure

Change 479871 had a related patch set uploaded (by Milimetric; owner: Milimetric):
[analytics/wikistats2@master] Update tooltip text and infrastructure

I've updated the staging site.

This came up in community conversation on this page: https://www.mediawiki.org/wiki/Talk:Growth/Focus_on_help_desk

But it's not ready yet.

Moving this to Blocked to indicate 'Development done and waiting for other tasks for the prototype to be completed, but does not need QA'.

An idea brought up in this community conversation is to also allow users to report that their question has not been answered on time.

This looks good to me in beta.

@SBisson @Etonkovidova @RHo -- I was able to replicate the issues in both Variation C and in the standard component library that @SBisson linked me to. I created videos of it, and they're in our team drive as Variation_C_iPhone_Safari_2018-12-14.mov and Standard_components_iPhone_Safari_2018-12-14.mov. I think you should view them in that order.

@Samwilson Any grey is fine. I used one randomly.

In T210693#4825092, @bd808 wrote:

In T210693#4824836, @Milimetric wrote:

I'm not sure for the cloud users use case, you'd have to look at common or slow queries against the _compat views to decide.

I don't think that there honestly is a Cloud wide use case for these tables until we have a solution that keeps them in close sync with the live data. Trying to explain to our end users that there are parallel tables with different names that are up to a month behind the live data will be a customer relations headache.

This seems to be fine in most cases. If you do try to put in a massive category, like Living people, it can break things. I tried "Living people" for just a 3-day period, and the number of pages was so high it wouldn't fit into a BLOB, even after using bzcompress.

I have a paper due tonight :|. I put a reminder on my calendar for the 16th.

Uhh, I had drafted a comment and never pressed "Submit". Better late than never!

Change 464469 merged by jenkins-bot:
[mediawiki/extensions/Dashiki@master] Fix problems with last change

@Volker_E what other things need to be done here? (Besides making a gerrit patch, which I can do quickly)

The tag is attached to Help panel question, it's properly displayed in 'View history', and is preset in Tags on RC/Watchlist filters.

@aezell done, you have been added to the wmf group. It should work now to login.

In T204502#4825116, @Volker_E wrote:

Nothing has changed since my last comment, even with @bd808's hints. I have good feelings about what's in there, but really relieving would be to either connect to them and have a look (which I had several issues with already in the past and the credentials are probably vanished) or to get file/db backups.

Mentioned in SAL (#wikimedia-operations) [2018-12-14T23:59:43Z] <mutante> LDAP: added aezell to wmf group (T211945) for grafana access

Change 479868 merged by Dzahn:
[operations/puppet@production] admins: add Alex Ezell to ldap_only admins (wmf)

Bumping this thread. Maybe making this configurable would be the best option (i.e. via LocalSettings.php or such)? With external links being blocked by default?

In T204502#4763757, @Volker_E wrote:

@aborrero As I've stated in my comment, I'd either need guidance on connecting to these instances or to get a file backup bundle to make an informed decision.

This has not seen a reply for more than three months hence proposing to unfortunately decline this task.
(Anyone can reopen this task at any time again by setting the status of this report back to "Open" via the Add Action... → Change Status dropdown.)

Change 479868 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/puppet@production] admins: add Alex Ezell to ldap_only admins (wmf)

@kostajh - entering more than 1000 for ?limit= in the url will result in self-correcting ?limit=1000 value when RC page is loaded (I do not remember the original behavior for url with ?limit= >1000). Since this task is just reverting the fix, it seems that the original behavior was not displaying in the url values for limit above 1000.

@Puneethchanda: Hi! As you claimed this task, how is it going? Do you need any help?

rsvg-convert is also a requirement for T211637: Render image previews via RSVG.

No reply from @AbdellahSADIQUI for six weeks hence closing this task as declined.

Hi @valerio.bozzolan , could you please edit the task summary and summarize a specific problem to solve in this task?
Otherwise basically every task could be an "XYZ needs further thought" task and tasks become indistinguishable. Thanks in advance! :)

Unfortunately closing this report as no further information has been provided.

Alright, just updated the patch to use uca-it-u-kn for napwikisource's $wgCategoryCollation

In T210693#4824836, @Milimetric wrote:

I'm not sure for the cloud users use case, you'd have to look at common or slow queries against the _compat views to decide.

This has been quiet since. No root cause identified though.

Done. :)

@cmadeo @schoenbaechler What should help option point to? Currently I have made it point to the Description editing help page we have in the app.

Let's try to replace the patch cable. Please sync up with me so I can drain traffic first.

To pile on that, LibreNMS can be queried instead of Puppetboard for network devices:
eg:
curl -H 'X-Auth-Token: TOKEN' https://librenms.wikimedia.org:443//api/v0/devices/cr3-ulsfo.wikimedia.org
Create token on https://librenms.wikimedia.org/api-access/
Doc on: https://docs.librenms.org/API/

@Etonkovidova - note that you can see which articles transclude a {{NOINDEX}} template at https://en.wikipedia.org/wiki/Category:Noindexed_articles.

Enabled the bot on enwikivoyage. Non-English wikis need to translate the messages before they can get it.

@Etonkovidova - Here's how it should all pan out after the patch is deployed:

• Unreviewed article, less than 90 days old, no {{NOINDEX}} transclusion: outputs <meta name="robots" content="noindex,nofollow"/>
• Reviewed article, less than 90 days old, no {{NOINDEX}} transclusion: doesn't noindex
• Unreviewed article, more than 90 days old, no {{NOINDEX}} transclusion: doesn't noindex
• Reviewed article, more than 90 days old, no {{NOINDEX}} transclusion: doesn't noindex
• Unreviewed article, less than 90 days old, {{NOINDEX}} transclusion: outputs <meta name="robots" content="noindex,nofollow"/>
• Reviewed article, less than 90 days old, {{NOINDEX}} transclusion: outputs <meta name="robots" content="noindex,nofollow"/>
• Unreviewed article, more than 90 days old, {{NOINDEX}} transclusion: doesn't noindex
• Reviewed article, more than 90 days old, {{NOINDEX}} transclusion: doesn't noindex

In T205899#4824856, @crusnov wrote:

Ahh Yes, so the report would include the failures and they'd be fixed manually and then it would no longer include the failures.

We can go from Netbox to PuppetDB yes.

Change 479858 merged by RobH:
[operations/puppet@production] decom einsteinium

Change 479857 merged by RobH:
[operations/dns@master] decom einsteinium production dns entries

Confirmed that this is resolved since v6.1.1