Oops, moved this post by mistake

Removing patch-for-review; all patches linked are merged

Although I have no objection on working on this task, how exactly is it "blocked by https://gerrit.wikimedia.org/r/#/c/401189/"?

This was already done by https://gerrit.wikimedia.org/r/#/c/398799/

There's no code right now that removed users who were de-publishered from the subscribers list, so removing that from the things this should est.

Closing task as resolved because all subtasks have been done

(patch was merged a more month ago)

Oops, ignore that, made a typo in my bug id

As far as I can tell, nothing resyncs the subscriber count, so it will be out of sync until someone runs the updateSubscriberCount.php maintenance script.

This task is looking a bit more complicated than I had originally reported it as.

Ok, there does seem to have been a misunderstanding. I was referring to manual edits to subscribers via Special:Newsletter/id/subscribers (T154080), not (un)subscribing oneself via Special:Newsletters

<adding parent task because the presence of multiple classes in the same file is a phpcs violation>

not fully done, there are still three sniff violations remaining

Hit three-hour limit. There are three disabled sniffs remaining:

Oops, forgot to specify bug ID in https://gerrit.wikimedia.org/r/#/c/394234/

In T48115#486504, @Anomie wrote:

The problem is that "expandtemplates" is a bit of a hack: it half-parses the wikitext to get new wikitext. But this half-parsing can't include calling tag hooks, because the tag hook returns HTML rather than wikitext. And it can't necessarily parse the text passed to the tag hook, because the tag hook might do almost anything with it (e.g. <syntaxhighlight> doesn't expand any templates, <ref> does, and it's theoretically possible to create a tag hook that would run inline Lua code or the like. So it just outputs the tag contents as-is.

It sometimes breaks in other ways, too. Consider, for example, what it does to something like "{{#tag:ref|Ref A<ref>Ref B</ref>}}".

Bug 28616 is similar: Special:ExpandTemplates half-parses the wikitext, and then parsed the half-parsed wikitext. This two-step parse can give different results.

The solution in that case is to make it impossible to protect newsletters in the first place, whereas it currently is possible to protect them, without effect.

First, you're missing a } in there. Try {{#invoke:Preprocess|main|<nowiki>-{{{argname}}}</nowiki>}} instead.

Yes, I did make a typo in my steps, but the same bug still exists even with the } added.

One more bug fixed - again