What my tokens mean:
I thought about using 💔 heartbreak for stronger dislikes, but I decided not to since it might be mistaken for "more than invaluable".
Thank you @Habitator_terrae. I actually read the messages a while ago but decided to get a clearer picture before replying. I believe what you got here is a way more detailed and authoritative answer than I could ever provide.
Anyway, I should add that increasing users' awareness of the amount of data being made public about their behavior and proving the ineffectiveness of 'courtesy' opt-in mechanisms were among the goals that led to the development of the Deep User Inspector (later, Deep Wiki Inspector).
If a piece of software is to blame, that is MediaWiki itself. Should there be a ticket? Found T203826 but nothing specifically asking for restricting access to such data.
https://gerrit.wikimedia.org/r/570387 a.k.a. e4d02b5e9a896546d63cd800ce6b0d77ae8ea190 seems to have fixed this, as checked via a local override with that patch reverted. Then the task may belong in WikiEditor (2010) instead.
Recompiling the Sass should not be too hard. Hosting it as part of the tool itself would cause the benefits of the cdnjs to get missed, though, as far as the theme is concerned. Or I might do without the theme entirely. Anyway I'm not placing this up for grabs as it does not make sense for anyone else to work on the Wikidata Slicer in its current state.
Not discouraging anyone from picking the patch up or starting a new one
Not discouraging anyone from picking the patch up or starting a new one
Not going to work on this in the near future
Not going to work on this in the near future
Not going to work on this in the near future
Not discouraging anyone from picking the patch up or starting a new one
Babel AutoCreate still blocked on many wikis. Task likely in need of movement-wide clarification/reevaluation
Glad that the old files are still around and the change has been documented so that browser version data can be gathered again. Hope moving the logs to my local machine once every few years will help freeing up some disk space while complying with the privacy Terms
I seem to recall How we made editing Wikipedia twice as fast having a big impact on the public perception of HHVM. Is a new post in the works? Someone from the broader community is likely interested in the what/why/how of the switch back to Zend.
GitHub PR by GlazerMann https://github.com/wikimedia/mediawiki-oauthclient-php/pull/7 predates task but the repo seems to be using Gerrit.
I still get dropped connections (not 414) with much longer URLs (total header size from 9442 bytes onward). Is that expected?
@Vgutierrez my bad, I meant retrying with a shorter URL.
Thank you all for investigating. What would you recommend as the best practice w.r.t. URL length in client code? E.g. POST requests, hard-coded limits, retrying on 414-coded responses...
Firefox 63, Chromium 70, curl 7.58 all work fine with HTTP/1.1 but fail with HTTP/2 on Wikimedia servers. Other HTTP/2 servers seem not to be affected.
Thank you.
It should be noted that the old-style @codingStandards comments, although deprecated, will continue to work until PHP_CodeSniffer 4.
Are you aware of any critical breaking changes between 3.1.1 and 3.2.0?
I tested the bad commit with one of my own queries while logged in so the star button wasn't there and the browser didn't even try to load the icon font...
Thanks for the quick response.
Appears to have been deployed
Replaced with the CSS version in https://github.com/ricordisamoa/labs/commit/e64c85a243c0db3c808d1bb0bb75bab79eb00405
As you can see, the googleapis request comes from https://tools-static.wmflabs.org/cdnjs/ajax/libs/bootswatch/3.3.7/flatly/bootstrap.min.css. Unfortunately, there doesn't seem to be an easy way to avoid the request without forking or recompiling the CSS.
Placeholder {s} should be for subdomains:
Replaced with the CSS version in https://github.com/ricordisamoa/dewkin/commit/5319d839ecc0734634641a321055587329748304