I wonder if that should be documented on https://www.mediawiki.org/wiki/Gerrit/Troubleshooting - edits welcome.
Sun, Sep 16
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.
Sat, Sep 15
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.
Tue, Sep 11
Mon, Sep 10
@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…
Sun, Sep 9
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.
Sat, Sep 8
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.
Fri, Sep 7
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.
Thu, Sep 6
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.
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.
Wed, Sep 5
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.
@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.
Tue, Sep 4
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?