this is not wikidata specific, and already hit the "early upgrade" wikipedias such as cawiki and hewiki. for details and links, see T338405

this is an old, practically abandoned story.

In T315639#8204471, @Jdlrobson wrote:

We simply wouldn't be able to change anything if we had to retain all existing CSS selectors and IDs. I don't know if you do development yourself, but if you do I'd urge you to take a moment to think
about how a constraint of not being able to change any ID would impede you with developing a MediaWiki interface.

In T315639#8175177, @Jdlrobson wrote:

....
Impact doesn't seem quite so bad. I'm only seeing 1408 cases across all wikis for JS files (I don't think it's worth focusing on CSS here).

In T315539#8166643, @MusikAnimal wrote:

They should instead file a Wikimedia-Site-requests to change the thresholds for semi-protection.

IMO, the exploit should not be exposed, to avoid causing more pain to sites running vulnerable versions.

just to clarify: the issue is that this was allowed until last version, which means there are already "live" templates which violate the assertion.
this caused significant disruption: specifically, one of these templates was the hewiki equivalent of "Cite journal" - as a result, editors could not create automatic citations of articles using DOI, and could not even create manual such citations using VE (and thanks to mediawiki devs, many editors don't even know how to use source editor - kudos!).
we went and amended those templates on hewiki (can't be sure we found them all - see below :) ), but it's more than likely similar issue still exists on other projects.

we should distinguish between visualeditor and templatedata.
templatedata provides a syntax to describe the template behavior, and is used not just by visualeditor, but other tools too.

just realized that this error does not add the template to any tracking category. make it 2 demerits.

beg to differ.
when ply is not defined, the final state of the game may or may not be useful to readers not using the interactivity, but the opening board is guaranteed to have zero value.
if you are 100% against showing the last ply, it would be better to declare ply= "mandatory" parameter, and show error when not defined, rather than defaulting to absolutely useless real estate on the page.

no need, thanks.
your explanation clarified it, and the comment is junk.

@4nn1l2 - please see update to story and consensus, and my comment on gerrit.

speaking of the algebraic notation, i would like to suggest some css tweaks to make it clearer that the plys are clickable.
cursor:pointer comes to mind.
another css change i request: please replace the bike and ped icons for fast/slow with dear/snail, as in the prototype. turtle would be even better.

description should be expanded to cover ply and swap.

i think you should obtain a simpler PGN with NAGs and test it with it.
the game on my user page was copied from one of the test cases in the extension's repo, but i do not know that it's valid.

@Wugapodes : can you see why 3rd game in https://en.wikipedia.beta.wmflabs.org/wiki/User:%D7%A7%D7%99%D7%A4%D7%95%D7%93%D7%A0%D7%97%D7%A91/ChessBrowser_test_cases still fails to parse?
i copied it from one of the test cases in the repo.

(critique based on the screenshot only)

@Wugapodes
now it seems that it does not like the question mark in the doc, and complains about

@param array? $fenParts The ....

on lines 149 and 214 of includes/ChessParser.php

@Wugapodes :
it says

looked at the beta.
saw for the first time how "flip" also rotates the board itself, not just the button. super cute.

In T281649#7084227, @Wugapodes wrote:

....
suggest we make these optional features that each wiki can configure as-needed.
.....
Thoughts?

In T281649#7084227, @Wugapodes wrote:

....
suggest we make these optional features that each wiki can configure as-needed.
.....
Thoughts?

interestingly, the first implementation of the standalone introducing speed control used slider.
never got it to be satisfactory.
if i may, i think it will be better and more useful to have a single "speed control" button, which will allow the reader to enter the delay numerically.

lichess is not the model.
look for any site which holds large library of games in PGN format, and look at the interactive game interface. first i stumbled on (from enwiki article) https://www.chessgames.com/perl/chessgame?gid=1129672
autoplay is useful feature. talk with chess aficionados. at the very least we should consult the authors. i asked on their talk page. (see enwiki:Wikipedia talk:WikiProject Chess ).

several comments:

@sbassett : currently, the beta deployment task, T244075 depends on this task.
iiuc, there is kind of agreement that the extension can be deployed to test wiki, maybe under some conditions.
can you please update the beta task, and clarify if it can progress despite declining this task, and if so, what needs to be done?
maybe it's clear to everyone but me...
peace.

(not very useful comment):

In T269222#6716104, @Aklapper wrote:

Please contact the Chrome/Chromium developers (or use another browser).
In my understanding, there is nothing we can do/fix on our side hence closing this ticket.
See also T269222#6681319.

I added a wishlist item to add this extension to wmf wikis.

fwiw, i added to mediawiki:minerva.js on hewiki the following line, and the pencils are visible again.

first of all, this is different than the error i see in the console when adding debug=1, which is

can someone please explain

on further examination, it's a bit more complicated than than.

i would add specific chess cases, to verify correct pgn parsing:

1. en passant
2. castling
3. promotion

currently, on wikimedia sites, the parsing _is_ lax, despite what the documentation says.

In T167423#3990447, @brion wrote:

3D has been deployed to Commons, but not yet to the other wikis, so files can be uploaded but not yet used in articles. It'd be real nice to have mobile support working when that further deployment goes out so we don't have a bifurcated experience for our users -- is there any current work on this?

another user have copied the whole content of her console:

In T220706#5107219, @Aklapper wrote:

Could you please try this with safemode=1? This allows you to test if a problem is because of your user scripts or personal gadgets without uninstalling them. See https://www.mediawiki.org/wiki/Help:Locating_broken_scripts for more information.

additional information:
user reports that on enwiki, and on hewiki with "uselang=en", she _does_ sees the "Save" button, but not with hebrew ui.

In T217087#5103885, @aezell wrote:

In T217087#5101989, @Jonesey95 wrote:

Here's a link to a broken page:
https://en.wikipedia.org/w/index.php?title=Template:Imagemap_Germany_district_AW&oldid=566491718

A couple of minor enhancement requests:

1. Add a tracking category, e.g. Category:Imagemap with invalid coordinates, so that gnomes can find and fix these errors instead of having to encounter them randomly.
2. Tweak the error text, which complains about the input not being a "number", even when the input is a number that happens to be negative.
3. Best option: If negative numbers are truly invalid, deprecate the use of negative numbers but continue the old behavior of replacing the negative number with a zero, but add a tracking category so that gnomes can fix these templates. Give the job queue some time to populate the error category (see also T157670, which means that it may take many months or years for the error category to populate fully), then remove support for negative numbers once all pages are null-edited.

In T217087#5102461, @aezell wrote:

....., I think we can agree that negative coordinates aren't logical in the coordinate system used for polygonal image maps.

legit maps on many wikis are still broken. i believe this story should be reopened - i could not understand the status of the patch, but in production sites (wikipedias of all languages), this is still borked.

this seems to be duplicate of T216318

@Aklapper - while T218393 is of higher quality and contains enough information to fix the problem, i still take some (modest) amount of pride at being first.... ;)

@IKhitron - if it's not chrome, then can you ask them for browser+version? you sure it's the same report?

so it's not necessarily related to mw update - more likely chrome change.

@Aklapper :
the url in devtools is: