My extensions provides a couple of new parser functions. I would expect, that it should be possible to specifiy this in extension.json. Currently I still have to add
$parser->setFunctionHook( 'example', [ self::class, 'renderExample' ] );
in sth. that gets called by onParserFirstCallInit.
Is it only me, or is there a real reason why not to support ParserFunction registrations directly in extension.json?
No one had ever really asked and the ParserFirstCallInit hook is more expressive and flexible than what can be done in JSON. It doesn't really eliminate much boilerplate mostly because you need a PHP/Hooks file anyways for the actual parser function/tag.
What do you think the advantage would be in registering directly in JSON?
Of course you are right, we need PHP classes to implement the parser function. But the same holds for special pages, which can be registered in extension.json.
I was just wondering if I overlooked something or if there actually is a difference. Thanks for confirming.
done; thanks.
Hi all,
/* ParsoidModules */ url not found: https://doc.wikimedia.org/mediawiki-core/master/php/classWikimedia_1_1Parsoid_1_1Ext_1_1ExtensionModule.html
Can someone update/realign this paragraph since included URL is no longer working. Thanks.
Christian 🇫🇷 FR (talk) 08:57, 1 August 2021 (UTC)
ExtensionModule is an interface: https://doc.wikimedia.org/Parsoid-PHP/master/interfaceWikimedia_1_1Parsoid_1_1Ext_1_1ExtensionModule.html
So what becomes the first url {{Class doclink|class=Wikimedia\Parsoid .... ?
ok, thanks {{Class doclink|... was not appropriate.
Christian 🇫🇷 FR (talk) 07:55, 2 August 2021 (UTC)
This page needs a saner section ordering. Special (lowercase) properties up front, attributes lexicographic? Importance? Thematic (which used to be the case but not really anymore)?
I would consider it appealing to have the same order here as in the schema files. However, we can adjust the order there as well.
I would actually keep the schema files alphabetical (the only reason to interact with them is typically to insert / modify field schemas, and that's easier when they are sorted in an obvious way), and would probably use some kind of thematic / reader-oriented grouping here (and take advantage of the fact that we can add higher-level section headers to make the grouping explicit). I don't think there's any disadvantage of the schema files being in a different order.
We've been talking about using the schema sort order in LibraryUpgrader to enforce the order to something meaningful (keeping attributes together, putting the RL things together, etc.).
The schema file is currently not sorted alphabetically though.
Considering how keeping documentation up to date here usually goes, I think this page will often be outdated in comparison to the actual schema. This is why I prefer using the same ordering here, as it makes it much easier to sync the page with the current schema file.
https://phabricator.wikimedia.org/T163114 Was resolved in April 2017 and https://phabricator.wikimedia.org/T142663 was declined in September 2017
We've got a few cases where we need to empty flat arrays e.g. https://phabricator.wikimedia.org/T163114 and https://phabricator.wikimedia.org/T142663
How are these supposed to work?
Here we want to substitute the array not merge it in any way.
Seems to be resolved, there was a misunderstanding since the edit summary I made was worded a bit badly
@SamanthaNguyen While I think I have a quite good understanding of platform requirements (I built the feature), I don't understand what you mean with your edit. Could you please elaborate?
@MGChecker: I apologize for I might have misunderstood; from my understanding, the `platform` property was not backported to MediaWiki 1.31. Because of that, I'm pretty sure core can't enforce the listed requirements under `platform`, because that was only introduced in MediaWiki 1.32. I hope that makes sense. Maybe something can be cleared up? If that's wrong, please feel free to revert the edit.
