Unstripping using mStripState is done after wikitext is parsed to HTML, but after parser functions and templates are evaluated (first, signatures and substs are parsed to the actual wikitext to evaluate, then the preprocessor inserts the wikitext produced by the templates, than this wikitext is translated to HTML).

As the documentation in insertFinalizedVars suggested, wikitext is not parsed properly if we use the default strip process. I don't think we can fix this, as even parsing the wikitext ourselves, which might be possible, will probably yield further ugly issues. However, the solution I implemented here works just fine for subst, as this is done before wikitext is parsed.

T123078 contains some information about how this works.

Well, this does not really surprise me, as substitution does not really like this extension. (T201857) I guess this won't be easy to fix, but I believe the reason why this is happening is quite simple: While ExtVariables->reqestFinanlizedVar is called without any problems and the strip markes inserted, the InternalParseBeforeSanitize function is not called in the subst parser run, so ExtVariables->reqestFinanlizedVar is never called.

After a little searching a little with code search, I believe the only place this is used is https://github.com/SemanticMediaWiki/SemanticGlossary/blob/master/SemanticGlossary.php#L25 .

Is the ParserDiffTest class still needed? This patch removes its last actual appearance according to MediaWiki Codesearch.

@Legoktm I think we should get this merged in time for MW 1.33. Their shouldn't be any remaining issues in the code.

In T220432#5098647, @Smalyshev wrote:

Just my two cents, but wouldn't it make sense to reserve all one-, two-, and three-letter URLs for future use?

Yes, this looks like a good idea - start issuing actual short URLs from 4 characters, and permanently reserve 1-3 letter short URLs for internal use. Then we can decide what we do with them much more freely I think.

I think we should just archive String Functions and leave it as is.

See also T209086.

As I understand the task title, Jayprakash considers extensions where noone in the corresponding Gerrit group (so, excluding people with +2 in mediawiki/*) has +2ed a patch in a year or two. I agree that this could be quite interesting.

This line of thought sounds quite reasonable. I doubt creating an additional tag for these few tasks is warranted, if no additional users request one.

It is a pity that extensions like this one tend to end up unmaintained. @Florian has outlined something similar in core in T155155, which has the goal to introduce a special page listing the current wiki configuration, that could maybe be extended to allow configuration changes as well in the future.

I do not really get how this is related to the impact of the vandal. as he basically states a single claim that would have to be denied or confirmed anyway at some point. I do not think we can link information about the incident and impact of the vandal here.

In T218507#5030499, @Dereckson wrote:

@thiemowmde Did you try your username in lowercase?

I don't think removing these comments is a good idea, as people subscribed to this task recieve the respective email notifications anyway and are left with even more questions than before. If the intention is to deny the claims of @JruwJN, I would consider it the better approach to just say so, if the intention is to keep this hidden for now, it simply is not working. So I don't think these deletions do any good.

In T218490#5030131, @Aklapper wrote:

Is there any reason we need logging of sending thanks by Extension:Thanks?

Yes: People cannot send a thanks twice if they already sent one. (This task lacks a problem description.)

People use these to do statictics, that is basically the only reason for public logging. And as you can filter the thanks by actor and recipient, it is not quite that useless in practice.

@MaxSem This shouldn't matter, as the code is fine. I would be willing to adopt this change.

Making deleted content of whatever kind available to a larger group than sysops has been declined by WMF over and over for legal reasons. Even my proposal to allow access to the history of edits you made yourself has been declined in Community Wishlist. That's why I'll be bold and just close this one, especially since it not only targets a specific wiki, but MediaWiki defaults.

There is a problem with Milestones: Phabricator orders Milestones by creation date in Workboard and Navigation, a behavior that can not be changed. As PAWS (JupyterHub 0.9) has been created before this Milestone, these Milestones would be displayed out of order.

@aaron, @Bawolff, @Umherirrender As you are listed as maintainers for Multimedia and Logging, I would love this to be reviewed by you.

@Legoktm I would love to get this into MW 1.32.2 or something like that, so this feature is finally complete.

Oh, now I see the difference.

I plan to take care of this in a few weeks when my schedule clears up. However, if someone else wants to do this, feel free to claim this task!

……

A special case that should maybe be adressed: Are there special policies for extensions that are not deployed by Wikimedia, but bundled with MediaWiki? T191741: Bundle Replace Text extension with MW 1.31 provides an example for this, where self-merges are forbidden as part of the process. (T191741#4179808)

Wouldn't be #Tool-status the better choice? Status seems like a quite generic tag name to spend here.

@Legoktm Do you know when you will have time to take another look at this change? I implemented your feedback.

Requested public project User-crusnov has been created: https://phabricator.wikimedia.org/project/view/3884/

Marking this as Resolved for the time being.

@Krinkle I don't think it is supposed that change project scopes are changed without consultig with Project-Admins first, especially as the scope of this project has been the result of a discussion here.

Requested public project User-EBernhardson has been created: https://phabricator.wikimedia.org/project/view/3865/

While I'm not involved in deciding this, I would appreciate you doing actual code contributions first. The commits you linked here are still more on the trivial side of things.

Requested public project User-DannyS712 has been created: https://phabricator.wikimedia.org/project/view/3849/

In T213880#4883399, @mmodell wrote:

Maybe we should archive MediaWiki-extensions-Other first, then create projects for extensions on an as-needed basis.

In T213880#4883219, @Aklapper wrote:

Thanks for filing this.

Leaving a talk page message for the authors to watch the relevant projects.

This needs to happen before creating a project tag, and getting consent and agreement from the developer/maintainer that they want to use Wikimedia Phabricator for tracking tasks and especially that there is not already an issue tracker somewhere else. I do not want to create a place in Wikimedia Phabricator where people file tasks while the maintainer/developer of a codebase expects those tasks to be filed somewhere totally else.

I agree that it doesn't really matter if tasks are filed as long as there is not separate project for them, as noone will ever find them anyway. However, if noone is active at maintaining a project, I don't know if this will really solve the issue.

In T213875#4883103, @Nuria wrote:

Rather than focusing on the bad actor why not focus in the target giving them tools to protect interactions? For example: they can protect their talk pages such to post you need to know the "secret" word (similar to a captcha), this way interactions are "whitelisted"

I agree with @Mainframe98 here.

@Legoktm Do you know when you will have time to review this change?

Thank you very much!

While I read the code in a way that you shouldn't be able to set this permission with the userights permission (because of the way User->getAllGroups works), is this displayed on ListGroupRights correctly? It might be ignored there as well an could look weird with no permissions assigned.

@Bawolff Can you please take another look on the patch?