Jdlrobson removed a project: MediaWiki-Platform-Team.

In T367103#9878184, @Od1n wrote:

development of https://github.com/leafo/lessphp seems to be almost stale for 10 years…

Keeping on radar, as I did testing and code review for this and the other stacked patches related to it.

As part of a review at https://gerrit.wikimedia.org/r/c/mediawiki/libs/less.php/+/1038745/6/test/Fixtures/lessjs-3.13.1/override/math/strict/css.css#72, I found a change related to calc() that might be relevant or useful. Ignore if not but give it a look so you have it in mind in case you're end up looking for something that looks like this.

Can/does the site in question communicate their enforced limit in an HTTP standardised and machine-readable way? For example, a 429 Status with Retry-After header, or (even better, to avoid hitting a failure first) a crawl limit in robots.txt.

We've previously removed commands when promoting them to the default. Installing both sounds good to me as well. I'd suggest literally installing twice for simplicity and portability of the installer.

@Ahecht Are you thinking of using this in the context of a gadget? If so, note that libraries don't need to ship with MediaWiki core in order to use them in a gadget. You're free to (yourself, or ask an interface admin on-wiki) to import any jQuery plugins and other libraries as-needed into wiki pages alongside your gadget. These can then be listed as scripts in the gadget definition before your other scripts.

Fixed in https://gerrit.wikimedia.org/r/c/fresh/+/1034847. Thanks @hoo!

Based on the title and task description, I believe you're asking for an in-container cache. However, as far as I know, we allow npm to cache within a given session already, such that repeat commands etc do not need to re-download things.

I discussed this interoperatbility upstream with the TC39 members in their Matrix channel. TC39 is the committe that authors the JavaScript/ECMAScript spec. While there was some interest in specifying this behaviour (so as to require consistency across browsers), it is currently expected that "non-well formed" comparator functions behave differently as it depends a lot on the sort algo which items will be mis-positioned.

Ref T366299: Investigate MediaWiki test failure (QUnit) - VisualEditor: prefixsearch ordering

@Phispi To avoid surprises in the future, I recommend running ESLint in your extension. If you already use this, make sure that you set ecmaVersion: 2016 ("ES7") in your ESLint config, which is what MediaWiki 1.39+ supports. There is also the eslint-config-wikimedia package from npm, which would automatically follow other (optional) MediaWiki's code conventions as well. I recommend using the same version as the oldest MW release branch your extension supports: https://github.com/wikimedia/mediawiki/blob/REL1_39/package.json#L24

Based on https://wikitech.wikimedia.org/wiki/Debugging_in_production:

See also:

• T304362: Pageview definition relies on X-Analytics to determine special pages
• T240676: Develop a consistent rule for which special pages count as pageviews

@Hokwelum has published the v4.4.0 tag, which should be the last Less.php 4.x release.

No problem. Thanks for reporting!

Marking resolved as patch is merged and task is not on any other team workboards.

Thanks for the heads-up and visibility into patches. I assume we're only tagged for awareness of on-going work (which I am indeed happy to follow and keep up to date with via IRC notifs), but I understand nothing is currently actively needed from us. Let us know if otherwise!

@Od1n Can you provide an example page/wiki, which browser you use, and whether you have JS disabled?

• The patches under T365752 add generic support for private modules as a new feature in REST. It seems non-trivial to maintain and support in a generic way. A simpler approach might be a feature flag specific to JobRunner, in which case one could communicate disablement via an HTTP status code from RunSingleJob, rather than by being absent from the registry. This might make sense since as that way the manifest isn't variable by user, which would risk/complicate internals around caching, and e.g. generating Swagger specs as we'd need to be careful not to let the cache be infected by a jobrunner. For special pages and API modules, we don't vary their registration by permission. The pages that are installed are always existent, but they may return a permission error. Anyway, more than the registry aspect pro/con, my main question here is about cost/benefit of an early abstraction now (which delays the main work of this task, and means there will be multiple moving pieces when we deploy/test this) vs later if/when there is more than 1 user for it (which would contain the business logic in a single class, and allow us to move more rapidly).

@Ottomata I've confirmed the same just now as well, on mwdebug1002. The Slack thread describes placing it in a new directory in the document root, which might differ. I've tested it by placing it in beacon/thing/index.php and confirming that that works as well for a URL like /beacon/thing/?test. I tried beacon/event/index.php but that did not work because traffic is diverted for that URL in Varnish before the routing for WikimediaDebug.