I was going to say that perhaps we could search the template data that's stored in page_props, but it's compressed isn't it so that probably doesn't work?

Thanks!

It seems like it might be nice to add an option to the TemplateData API, e.g. extend the doNotIgnoreMissingTitles parameter to also return guessed parameters, or add an new guessmissing that does the same. No metadata about these parameters would be available of course.

This seems to be a deeper bug than it first looks (see also T150455). Number fields are type="number" and browsers hide non-numerical values for those (i.e. .val() returns an empty string).

There aren't preferences any with variable names (that depend on the user), but the presence of a few depend on the user (e.g. those to do with email are not present for users who don't have sendemail) and so with the current system we can't retrieve all the preference names.

I haven't been able to replicate this.

This seems to be because we're using the Special:Redirect/logid/123 method to link to a log entry, and the markasread parameter isn't forwarded with the redirect.

It's not only Echo that has an array preference, it's core as well (email-blacklist). So really, GP should only have to convert the core one (and do whatever else core does to preference values when loading) when it loads global preferences.

Could this be related to looking up the central ID? I've attempted to reproduce the bug locally by running 1000 requests, and do see considerable increase in Handler_read_next:

Also reported at https://www.mediawiki.org/wiki/Topic:Ubb4rq1ajetfbxc2

I don't think this is related to GlobalPreferences. The closest current issue is T190902: Usernames remain disabled when enabling local exception for email-blacklist, so I wonder if there are just some peculiarities about that widget.

I am unable to log in as well. The login form is has a link to log in via HTTPS (as though it doesn't know that it already is).

The above patch depends on T192057 being resolved.

Thanks @Anomie that's super useful. I've made the changes you suggest https://gerrit.wikimedia.org/r/#/c/425941/ and this task's two problems are fixed (and the TemplateWizard patch is passing). :-)

Should we add a check to Echo to ensure GlobalPreferences isn't loaded? Because we can't check in GlobalPreferences to make sure Echo is loaded, because it may not be installed at all.

I don't think this has anything to do with VisualEditor, Herald. But whatever you reckon, you go for it. :)

@Simetrical is this something you know about? (You added the above failing test I think.)

The first part of this will be covered by T191264, because empty required fields are treated as a type of validation exception and so are caught along with misformed values etc.

We didn't see any more of these errors in the last deployment.

So it looks to me like (for a logged-in user's request) the user three times: once when loading the session, once when setting $wgUser, and once in the ResourceLoaderContext.

If a log entry has an associated revision ID, it uses that.

Could the above slides be attached here as a PDF?

This should be working now, thanks to @kaldari: https://en.wikipedia.org/w/index.php?title=User%3ASamwilson%2FTemplateWizard.js&type=revision&diff=835798273&oldid=834272150

I think the main problem, and the (slightly indirect) reason that this hook needs to exist, is that it is not possible to determine valid preference names without doing so for a particular user. This is why the cleanup script treats anything that is $wgDefaultUserOptions as 'unknown' (along with userjs- preferences).

It happens on Firefox too, on Wikisource. I can't get it to happen with the extension though, so haven't really looked into what load order or other confusion is causing it. The gadget is loading oojs-ui-core which should be enough, but I guess sometimes other things are happening. :-(

So if we're sticking with Gerrit forever, then the work to implement this might be worth it? (I'm not not volunteering to do it, by the way.)

The purple-numbers idea is about adding anchors to every paragraph or list-item (etc.) as little purple-coloured hashes or pilcrows at the end of the block. I don't suppose it would ever be considered on a Wikimedia wiki as it's often considered a bit annoying to readers, and anyway seems to have died out in recent years.

It's probably fine to leave the deprecation warning in, but maybe there's a way around.

Thanks. Will do.

Yeah, it does seem a strange choice for a log type name, but it looks like it's not used for anything other than flow-* actions: https://quarry.wmflabs.org/query/26144

@Esanders this is a good idea, and would certainly make some things a bit simpler. However, after discussion, we've decided to at least try to avoid a dependency on Parsoid. This is mainly because we want to be able to support 3rd party MediaWiki installations, and not many of them have Parsoid installed. Also, the (possible?) future shifting of Parsoid to be in core or at least in PHP adds a bit of uncertainty (although, I guess the API endpoints wouldn't change, so that's maybe less of a worry). We'll of course re-visit this if it seems we're going down a long tail of annoying bugs! :-)

It shows default if there is one, and then example if there's no default. Doesn't show both.

VE does this with placeholders for both example and default: e.g. $1 and Default: $1. Shall we do the same?

Oops! I think I even knew that about endswith, but forgot. It feels like the sort of method that must have existed for ages. Wasn't there an endswith in Visual Basic? ;-)

The Timeless oddity I mentioned: