I think this is a good idea, as long as it is configurable via LocalSettings. I'm not entirely sure about what the default value for mediawiki should be however. On the one side, maybe sites currently depend on on this and want to keep, but also having mw.org defaults out of sync with wmf defaults, tends to be annoying for system adminitrators as well, so.....

This is rather unavoidable.

1. the introduction of ooui is still in progress
2. the conversion of modules to less (a prerequisite in order to use the style variables) is still in progress
3. there are some very specialized controls included in various components, for which centralization won't make sense, these will always require such overrides
4. there are still a lot of mistakes in modules that core developers will never notice, because they only use one skin.

Possibly same as T255785: Template insertion fails in 2017 wikitext editor (including citation templates via citoid)

This is a code path in the Kaltura JS player.

This would require redoing the sort value formatting. Currently all numeric is formatted with formatDigit and then assigned -Infinity if it is not a number, before being sorted. In order to keep natural sorting here would require applying natural sort on the remaining items that now share -Infinity. Bit hard to do as we just 'removed' that information in the previous step.

I replaced the redirects with a general http -> https redirect protocol upgrade.

https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette

Report status and priority fields summarize and reflect reality and do not cause it. Read about the meaning of the Priority field values and, when in doubt, do not change them, but add a comment suggesting the change and convincing reasons for it.
As a general rule, the fastest way to see a bug resolved is to provide a patch; +2 is one policy for approving proposed code.
Convincing reasons for raising the priority of a bug include evidence that it affects normal, everyday work significantly. Contrived examples or problems that only appear under unlikely circumstances are generally evidence for treating the problem as "low" or "lowest" priority, since the limits of any non-trivial software can be exceeded if you try hard enough.

I suspect this is because of the always added response header: x-clacks-overhead: GNU Terry Pratchett
I suggest that if toolforge wants to add global headers, it should probably also 'globally' add that header to Access-Control-Allow-Headers.

This is in part because the templates use a table inside of a table (infobox). The default CSS doesn't account for that. I also agree that this should be fixed using TemplateStyles on the local wiki.

Good detective work @Gilles !

@Kolossos did you try adding access-control-allow-methods: "OPTIONS,GET" at the same time ?

i haven't been able to find info on tools-static.wmflabs.org.. can someone provide that info and update https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web#Static_file_server

ugh. this is a mess

In T249486#6038532, @sbassett wrote:

In T249486#6032726, @Bawolff wrote:

Note, the flickr thing is part of the uploadwizard extension, not a gadget or anything like that. Most of the other things like that had builtin exceptions, at least in the short term (in the spirit of stabilizing the status quo before changing things)

I'm not seeing anything in the labs CS.php/IS.php for anything outside of the standard Wikimedia domains, nor in the headers when I load any beta pages.

In T208188#6164185, @AlexisJazz wrote:

I don't get it.

Content Security Policy: The page’s settings blocked the loading of a resource at https://api.flickr.com/services/rest/?&api_key=e9d…=json&nojsoncallback=1&method=flickr.photos.licenses.getInfo (“default-src”).

That’s why there is T249486: Change Content Security Policy on betacommons to allow api.flickr.com as well. But it has nothing to do with this ticket.

Thank you @Bawolff

I suspect this was due to cached code being executed after T202121: Update Ace Editor library to a more recent version somehow...

"It's becoming less clear as time goes on why we want to turn PDFs into DjVus anyway!"

One note here.. The software used for TMH (and most of the media processing) runs on servers that are not the same as those rendering the pages. And the pages can only access the software version on the server rendering the page. So there is a potential disjunction here (assuming that ffmpeg is even installed on the web server).

This is a relatively easy fix, which i've not yet made, because i was trying to figure out if there is some sort of historical reason for omitting the innershapes. I couldn't find one.

There's only one way to do that really, and that's documented. To lazy-load, you use mw.loader.using().

origin-when-crossorigin: Safari pre 11.1 (spec implementation error, 2017-2018)
origin-when-cross-origin: Safari post 11.1 and all other modern browsers
Origin: browsers from between 2015 and 2017

I don't think this is much of an actual problem. I'm pretty sure that it is just the pink/purple highlight (for amenity:hospital and amenity:university) being applied to the buildings instead of to the plot of land. Between z17 and z18, buildings become flat (instead of 3d'ish) and (transparent) landuse and amenity highlighting starts applying. Because the amenity highlight is applied to the building, instead of the 'plot of land', the transparent highlight and the building occupy the same space and it looks like it 'disappears'.

I don't think there is any intention to support this going forward. It was never what the functionality was supposed to be used for and near impossible to support reliably across multiple platforms (like iOS/Android apps for instance).

@Aklapper no more than what is in the mediawiki page. I guess the WMF team decided that it wasn't worth their time to continue to work on this.

I do have a patch for this.. somewhere...
I believe I never completed it, because i had wanted to use templated html instead, but then I never finished that rework.

@Krinkle for the origin-when-crossorigin fallback.. The spec compliant origin-when-cross-origin has been supported since March 2018, starting with Safari 11.1. So in order to remove that, the question to answer would be: How much traffic we still get for Safari versions older than 11.1 and does Analytics care about being able to accurately track 'internal referrers' for that number of browser sessions.

where are b and c ?

So Template:Citylist (implemented using module:itemlist), wrapping listing templates, wrapping marker templates, which in turn invoke the Map module. The list function re-sorts, but has no way of passing this information to the individual items.

If ppl are really interested in undoing this, in my opinion, you need to do a better job at explaining why you have NOT set your editor font to a sans-serif font, leaving it monospace, yet require a sans-serif font in diffs.

@Nemo_bis yes its because of the tables. Chrome (which PDF printing via Proton is based on) automatically compresses the size of pages to fit tables that are too wide to otherwise fit on the page

should be in GMT and not UTC.

The analysis by Anomie is correct:

With CodeEditor, it looks like there's currently a race where WikiEditor is triggering the "doneInitialSections" event before CodeEditor registers for it, so CodeEditor never manages to register its hashchange listener.

0,0 (aka null island) is just the default position of the map, and in this case basically means that the query to OSM for a map relations tagged with wikidata:Q683705 returned no results.

Kartographer doesn't care about what is in WikiData. It gets its shapes from Openstreetmap. So that means that likely someone broke the shape in OSM.

This issue really only surfaced in VE+static img maps. On livepreview, we always use dynamic maps and then the wikipage.content loop of staticframe usually only triggers once. Except when using VE.

@Fuzheado @Keilana there is a csv/excel import/export gadget for that that I made a couple years back. https://commons.wikimedia.org/wiki/MediaWiki:Gadget-TabularImportExport.js

Confirmed. this issue is blocked on Parsoid/WE2017 not supporting JS modules in preview (unless the old page version already has these loaded).

1. That's not a Kartographer map on that page, just a simple image.
2. Preview seems to work for me.

Fyi, I run a nominatim proxy on toollabs to make sure other toollabs projects using nominatim can use it without leaking userinfo.

I think this is mostly fixed now..
Unfortunately I also think these were multiple issues happening at once. Probably the php7 parser and broken Json inclusion. But also cached out of date static images and possibly the bug with mobile static images not working.

I had sent this by mail as well but, this is not a resourceloader problem.

This is because stroke-width takes a number, not a string:

<mapframe width="200" height="200">
[{
  "type": "Feature",
  "properties": { "fill": "#ff3333", "stroke-width": 5 },
  "geometry": { "type": "Polygon", "coordinates": [] }
}]
</mapframe>

@Andyrom75 just wondering what the status of this is. Is there anything still needed to fix your problem ? Do you have an example page with the problem ?

This is basically the same as T125263: Interactive maps get resized to a thumbnail

Note for later. Keep in mind T168601: Wikicode in map data is always rendered in enwiki if data is from Sparql

    // TODO: we shouldn't use it directly,
    // but instead refactor out mwapi lib from node_service_template
    // and use the proper host
const mwapi = core.getConfiguration().mwapi_req;
config.mwapi = (mwapi && mwapi.uri) || 'https://en.wikipedia.org/w/api.php';

https://github.com/wikimedia/mediawiki-services-kartotherian/blob/4592692ddc14dc2fb3f20f5756fa2cf92dc6023a/packages/geoshapes/index.js#L43

Confirm that this is still a problem. Kartotherian seems to do all its parsing against en.wikipedia.org, instead of the domain it should be using...

This requires implementation in Kartotherian, Kartographer has no idea about Wikidata (or any non-local source honestly). Should be relatively easy to wrap wkt as geojson. Open question.. can there be more than one column of wkt ?

Possibly Kartographer should ignore fill value for geolines?

i'm calling this resolved. Wether or not communities use it or not.

tracking categories seem to have been removed a while ago. (probably in favor of statistics tracking?)

This might be fixed next week because of