I wonder if that should be documented on https://www.mediawiki.org/wiki/Gerrit/Troubleshooting - edits welcome.

Sometimes page moves and similar actions change the content model of TemplateStyles pages to wikitext, and currently you're unable to change it back without asking a sysop, which can be kind of annoying.

I'm unable to reproduce this issue, however it's possible that both ParserFunctions and Variables have changed their internal processing in the meantime so this isn't appearing anymore. If you still experience this problem, please provide more detailed steps to reproduce.

Seems like a nice to have feature to me, but you can just change it back if abused? Changing content models is even easier to revert than page moves (because of the redirects).

We should really get this done, know that TemplateStyles is deployed and it's on user level by default. It's really annoying to rely on an admin any time you want to create new template styles or change the content model of a page in your userspace. There is no reason to keep this from autoconfirmed users, especially not from security perspective. It's not really a new thing that you can vandalize wiki pages by creative means.

You're welcome!

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

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

@Yaron_Koren Would you please teake a look on my patchset? Should be ready by now.

Thank you!

In T197535#4571851, @Legoktm wrote:

ext-<name> allows you to require PHP extensions (includes core extensions). Versioning can be quite inconsistent here, so it's often a good idea to set the constraint to *

I think just supporting * for now and using extension_loaded(...) is fine for an initial implementation.

@thiemowmde Any thoughts about this? Kind of feels bad to do this without review…

PHP extensions are kind of weird. It's easy to check if they're loaded at all ( get_loaded_extensions() ), and there is phpversion( $extension ) to check for their version. However, it doesn't work reliably, as many extension developers leave it blank (according to a little research with Stackoverflow) and implement their own creative ways to specify a version…
t

I will start with the php key, maybe adding the ext- keys as well.

According to MediaWiki.org, this is possible since MW 1.30.

I would like to assist at this if it's fine to you. Especially if I'm creating new projects for extensions, I would like to tag their repositoriess accordingly.

Is this worth an entry in the Release notes?

This would be super awesome for third-party system administrators!

Imagine this as a framework to provide functionality extensions of this type often use. For example: Both Variables and Arrays store their data in a simple array in an extension class, which is stored in a Parser attribute afterwards (or with setExtensionData after refactoring, see T203530 for that). I don't want to change much about this path, except for the simple array thing, because all of these extensions have problems with similar things:

• You can't just get data from them, you have to make sure there's no template caching going on producing invalid data. In other words: At each point where you get data, you have to modify the given PPFrame. If doing it like we do it today becomes impossible at some point (Parsoid), it's much simpler to change the way it works in a central place.
• To interact, these extensions define public interaction functions just like these, that look always the same. You would just have to define decorators in the extensions if you start from a ParserStore class like that.

This ParserStore would just be injected by DI into the extensions storage class and be used for all this stuff. Currently, it doesn't do too complicated things, but it makes adjustments to changing parser logic much easier.

Is there any way to change task subtype manually? I think we should document this new future properly on MediaWiki.org really soon. I guess most people don't even know that these feature exists and if/how they can use it.

To make a start, we could move the hook functions to a seperate file. After the MW 1.32 branching point, we could split the parser functions and the actual Variables store as well.

In T203519#4561992, @Kghbln wrote:

I think it's a pity that there's no procedure in place to really maintain popular extensions on Gerrit if they aren't WMF-deployed. Many of these extensions are in desperate need to be updated to modern coding standards, to fix long-standing bugs, and to follow extension best practices. It's not fair to the hundreds of Wikis using them, that they are rotting as soon as the person who wrote the extensions gets off the radar. And it's not like the WMF wouldn't have the resorces to employ someone who is doing this for unmaintained extensions, gives advice to other third-party-extension maintainers and is reviewing there patches. Shouldn't be a big deal

That's a general issue and not specific to this extension. I do not really thing that WMF should maintain the extensions which somehow end up in their repo. However I do strongly believe that there must be an easy way to figure out if an extension is actively maintained or just rotting.

Can we please just set something up here? I would like to add patches to a queue like that for sure.

This is still awaiting review, but I'm unable to do anything about it.

Turns out this is really easy to do.

One question regarding MediaWiki releases: A project like this requires breaking changes at some point, and it's desirable to provide these at a single point after most of the work is done to deliver a consistent experience with a clear upgrading path. Nevertheless nobody wants to do all things that have been proposed here in a single changeset.

In T203519#4559001, @Kghbln wrote:

Do not forget the #arraymaptemplate parser function provided by the PageForms extension. Hmm, usually people using Arrays will most likely also have PageForms installed and vice versa. I personally think it will be great if this extension sees refactoring, maintenance etc. Adding new parser functions which are already provided by other extensions is probably unnecessarily complicating things at this point. I think this will be a second step if at all after the groundwork was done.

In T203511#4558618, @Aklapper wrote:

We should turn all of them into acl* (see e.g. T126953) and then https://phabricator.wikimedia.org/project/query/O1eugK19EhOf/#R would basically fix this?

@Legoktm I wasn't aware of this function, and I agree the mentioned extensions should store their data there instead of using a parser member variable.

I just created MediaWiki-extensions-Arrays . Feel free to join!

I invite people willing to use their skills to bring this extension up to date to add themselves to the task description, stating what they could do.

In T203523#4558328, @Legoktm wrote:

It would be helpful to document why ParserOutput::get/setExtensionData() doesn't meet what you need.

In T203523#4558235, @Dinoguy1000 wrote:

Can you start a complete list of extensions that might benefit from this? In addition to Variables and Arrays, you mentioned Extension:Loops on your de.wp talk page, and IIRC you've also mentioned at least one other extension somewhere? Are there any others you're aware of?

@Dinoguy1000 Would you be interested in helping to organize a project similar to MediaWiki-extensions-Variables or to rewrite the documentation of this extension?

In T203519#4558229, @Dinoguy1000 wrote:

The documentation for Arrays is in horrible shape and desperately needs rewritten IMO. In particular, the function options have never been clearly documented (for example, the #arrayprint syntax documentation shows that options can be provided, but literally nothing else is said about it)! On a behavioral note, requiring a delimiter to be specified for #arraydefine to follow options passed to it is just stupid.

Is it possible to set group-specific rate limits on Phabricator? If yes, I think we should set lower limits for people who aren't part of this project, to hamper vandalizing in the future.

How is this going? Is this done for now?