NameTableStore is pretty self-contained, callers (such as the import logic) should have no idea whether the record exists already or not. They just exchange the model name for an ID which might or might not be freshly created. So I would suspect a database-level issue here (writes fail, but somehow without MediaWiki noticing it, or maybe there is some over-eager exception handling happening; the rest of the import works due to NameTableStore having cached the model name / ID pair, but as soon as that cache expires things blow up).
Here's the same on testwiki (where things work as expected) just to make the URLs easier to follow:
I would go with whatever is easiest. No one is going to get surprised that using the extension on Phabricator has no effect; for wikitech it is non-obvious.
TemplateStyles uses Content::prepareSave to reject invalid CSS; if you try to save it, you get an error (much like how you cannot save invalid Lua code). There is no such thing for user CSS - it's not sanitized, it's not parsed, any string is valid. (ResourceLoader might error out when you try to use it, not sure how that would go, but nothing prevents saving it.)
Mon, Nov 30
This is caused by $wgGroupPermissions being incorrect and that patch only touched $wgFlaggedRevsAutopromote / $wgFlaggedRevsAutoconfirm so probably not.
Without the JS parts this would make sense as a TemplateStyles task. (There is a patch that I think does a lot of this but needs to be reviewed.) That is largely independent from the browser support matrix - it is fine to support CSS features not implemented by all browsers if we assume CSS editors will be responsible about providing graceful degradation.
That might be better as a CodeEditor lint rule.
Displaying parser errors is a MediaWiki core feature so this is probably not TemplateStyles specific.
Giving admin-level privileges to people who are not admins would significantly affect the governance structure of the wikis, would require consulting with the affected communities, which costs a significant amount of developer and editor time. I'd rather not do that for a fairly arbitrary request like this.
Thu, Nov 26
I wrote down the interaction between the MediaWiki extension and ElasticsSearch in T268803: Add a link engineering: Search pipeline; please correct me if I got something wrong.
Wed, Nov 25
I can confirm that this is now fixed in production.
Does "animate" mean just that, or some kind of drag mechanics (where the card moves in sync with your finger so it feels like dragging paper)? The latter is common on mobile apps but probably more effort.
Thanks for the thorough investigation!
I tried to write a core patch for this but it didn't feel convincing. The mentor manager in GrowthExperiments is the only thing using this pattern; only GrowthExperiments and flow use UserOptionsUpdateJob in the first place. And UserOptionsManager would require a new caching layer to handle this without breaking the use case that resulted in rMWff50d815a567: UserOptionsManager: take into account $queryFlags when caching which seems like a lot of complexity for something with such marginal utility. It also introduces various risks (what if the job gets lost or fails, but the updated user option gets stored somewhere else, resulting in loss of DB consistency? What if something tries to set the option between scheduling and running the job?) We can accept those risk for the specific use case of MentorPageMentorManager because we know the option is not going to be used in any way where that would be a serious problem, but providing it as a general-use interface seems fragile.
This is the same issue mentioned in T250235#6605155.
Filed T268700: Investigate setting up alerts for Growth dashboards about the alerts.
Tue, Nov 24
This has been a recurring problem with our custom icons (see the icon before the result count at the bottom of the same dialog, the icons on the task card, the difficulty dialog etc), IIRC in other instances we either ignored it or just added some padding to the icon and tweaked the size until it looked right (with default zoom/font settings anyway). Would be nice to figure out what the proper fix is.
What is the URL of the survey, the URL the skip button (or whichever one you click) and the URL of the login page you end up at?
Mon, Nov 23
Sat, Nov 21
I can't seem to get the version pinning right.
vagrant@test:~$ cat /etc/apt/preferences.d/sury-override.pref Package: libpcre2-* php-apcu php-igbinary php-redis php-tideways php-xdebug Pin: release o=deb.sury.org Pin-Priority: 1010
Fri, Nov 20
These are actual events though: add happens when a maintenance script generates recommendations, invalidate happens when a user acts on a recommendation (which can involve making an edit to the page, but doesn't have to). Is it a naming issue? add could be something like evaluate (to better resemble score), maybe? invalidate could be called something like submit? (accept/reject wouldn't work since a single recommendation contains multiple links, and the user could accept some and reject some in the same action.) We want to invalidate in situations other than the user accepting/rejecting, when the page has changed and recommendation is not current anymore, but we can probably use the normal MediaWiki index update mechanism for that.
The ideal solution would be, as in most similar cases, extracting the business logic from SpecialUpload into a separate class that any special page can use. That would, of course, take a fair amount of effort.
Environment variables are strings while configuration settings are often arrays (sometimes deep arrays) so as a general mechanism env vars seem problematic.
We can just install the Stretch backport from from https://packages.sury.org/php/
@Ottomata I imagine the right way to send an event from MediaWiki is using EventBus? That will require configuring the event stream via $wgEventStreams. What's the preferred approach, should that happen in the extension or in mediawiki-config?
The data will be stored in elastic within the predicted_classes field (currently named ores_articletopic, but renaming will happen at some point) along with the the ores predictions already stored there.
After vacillating for a while I went with new events (mediawiki/revision/recommendation/add, mediawiki/revision/recommendation/invalidate) instead of reusing mediawiki.revision.score. Semantically it seemed wrong - the event does not contain any score, it is a notification that a recommendation was generated.
Thu, Nov 19
You shouldn't insert content IDs manually, the import script will do that. If you do insert by hand, you'll probably end up with a stale NameTableStore cache.
Some kind of mechanism for allowing variables in filter messages and/or allowing messages to be tied to wikitext offsets (where the filter author would have to specify what those parameters/offsets are) would probably be ideal, but it seems like a lot of effort to implement that,
This is caused by Vagrant; I'll fix that. That said, a quick search gives these extensions/libraries which depend on Monolog 1:
Wed, Nov 18
I did not enable the v2 protocol.
We found the underlying issue (it was specific to the extension) so the logspam will be fixed soon.
@Pchelolo I apologize for the false alarm; the error was in the extension code after all. The Job contract that we broke is IMO rather obscure, I added two patches that hopefully clarify it.
Tue, Nov 17
It gets scheduled on cache misses, and the cache expires in a week. It also gets stale if the user changes filter settings, but it seems implausible that that would happen a few thousand times a week.
This is happening about 1000 times an hour, which is a pretty crazy rate for a job that's supposed to run once a week for opted-in users on select wikis only.