I am a little weary changing this behavior inside the toolbar itself.

In T225571#5260481, @Mainframe98 wrote:

Will there also be a PHP variant of this widget?

Yup, that would work as well; I wasn't sure if it was okay to change that without some agreement from community if the bot is widespread, which is why I (wrongly) assumed that wasn't an option :)

I was thinking about this -- I don't think OAuth is enough to stop this behavior. We will need to add a check about whether the user is also blocked, potentially from the page they're asking the bot to edit.

In T206163#5238240, @Tchanders wrote:

What name do we prefer? So far the suggestion is CompositeBlock which sounds good to me.

Yes, I don't think that's a problem, that's the intent.

In T224245#5225204, @MaxSem wrote:

Yeah, I've corrected my text.

In T224245#5225176, @MaxSem wrote:

• When such a setting is getting modified, GlobalPreferences intercepts this and, if the option is global and not overridden locally, a local value is set instead. Modifying a locally overridden value transparently should already work as expected (but we need to verify this regardless).

There's not a lot of specifics to test here, but we should just verify that things didn't break with this on beta.

This is an interesting discussion, but it's not quite for this product to make the decision. We read the spec off of TemplateData which allow template owners (and wikis) to set the templates the way they wish they behave for better behavior both on the wiki as well as while being edited by this tool or VisualEditor.

Actually, that's a great catch; this should probably also be the fallback for wikis where Echo isn't installed.

Yeah, this fix is mostly only for the UX of the tool and should not impact the actual SVG file.

PR available: https://github.com/wikimedia/svgtranslate/pull/114

Eh, yes, good point about the API. We can find a solution for that, but to be fair, that might well be acceptable behavior. The API module is split between local and global preferences, since the users of the API don't have core's problem of not having to know about the existence of GlobalPreferences. The explicit product choice (until now at least) was that whoever wants to change the preferences through the API needs to explicitly choose either local API or global.

In T224245#5209567, @dbarratt wrote:

I understand the solution, I'm saying the simpler solution might be to just add another hook / method. The new hook would do something with *all* the options (just like if the form was being saved). This way, code can save the settings locally (unmodified) or globally (modified).

GlobalPreferences is listening to the UserSaveOptions hook, which hands over the $options array that can then be handled. See https://github.com/wikimedia/mediawiki-extensions-GlobalPreferences/blob/master/includes/Hooks.php#L91

One question is also where this wg variable "lives"; GlobalPreferences shouldn't really have a list of options in it, so we can put this in Config, but we will have to make sure that all given options are global (not per wiki). Could use your input on this, @MaxSem

Pinging @Niharika and @MaxSem.

I'm using Chrome Version 70.0.3538.77 (Official Build) (64-bit)

The 'prevents' method is dealt with and had an email sent to wikitech-l.

The problem with flashing will be Varnish; logged-out users "skip" our PHP servers because they're served from cache. That's why most pages will "flash" to them.

To clarify -- the lazy-loading is for whatever JS interface we come up with to toggle, not to initial style loading (it was especially important when we discussed a popup, which involves OOUI assets and is hence not that small)

One more thing, sorry for the flood here, but we might need to lazy-load the CSS styles. If we do, there might be a few milliseconds (potentially a little more to slow connections) between the user clicking the toggle and the CSS/JS being loaded and activated.

Ooh, those look really nice, I think they work better than a popup (and as mentioned, we will have a much easier time making them accessible; the menus tend to be problematic with that)

@MusikAnimal Are we using this ticket to add the initial files (+ linting + folder structure + tests / grunt, etc) for the extension or do you want to use the other ticket to do that?

In T221877#5142740, @MusikAnimal wrote:

In T221877#5142725, @Samwilson wrote:

Is it planned that there will be a query string toggle for this, e.g. ?usedarkmode=1 or something? Because if it's a JS-only feature then maybe the link should be added by the resource module and not in PHP.

Yes I believe we'll want to support a toggling via query string. I only used PHP here because using only JS to manipulate the DOM would cause the links before it in the toolbar to "jump" on page load. I was following Extension:Echo's lead. The design hasn't been finalized anyway... maybe I should just remove the PHP for now?

For the extension files, you can use MWStew: https://tools.wmflabs.org/mwstew/

Merged. Should be in staging in a few minutes.

When did we introduce this? If we introduced it in a previous (and published) release, we might need to deprecate for the upcoming one? ... But if it's in between releases it's probably fine.

This is the quite entangled view of the "Enhanced" recent changes table. The structure is tabular, but this specific cell has several notations in it (like "N" for new page, etc) and in order to align them across the different entries, the line is either with the symbol, or with a space.

PR is here: https://github.com/wikimedia/eventmetrics/pull/262

Just note that browsers started considering these custom messages as security breach. They allow us to display a warning before navigating away, but not to set the text of that warning.

In T218812#5060050, @Krinkle wrote:

Task description:

If a user adds an expiring item to their watchlist, when the expiration date/time is reached, the item is removed from their Watchlist.

This does not require scheduled execution of jobs. We have various features in MediaWiki already that have an expiry of sorts, which are enforced at run-time. One may be concerned with internal storage allocation, but that is entirely unrelated to any user story or product requirement, and we have existing mechanisms in place to address those. Unless and until there is a problem with that, I do not think we should invest in another way to solve the same problem.

Note also that execution of jobs is by no means guarantee to happen at a certain time. We could maybe ensure it won't execute before a certain time, but not that it won't be a day or a week later. This is precisely why you'll still need run-time enforcement. Which we do already for user rights, page protection, blocks and other features.