Jump to content

Manual talk:Extension.json/Schema

About this board

broken link to ParserOutput::setJsConfigVar

3
Summary by Wladek92

done, it was the only broken link of this page.

Wladek92 (talkcontribs)
Cavila (talkcontribs)

You might find more of these direct links that are broken. I've adjusted the link to send the user to the wiki page instead, with the additional benefit that it allows you to pick a recent MW release.

Wladek92 (talkcontribs)
Thanks, I am just a translator and was checking the coherence of the page. Hope it is useful for the readers. --Christian 🇫🇷 FR (talk) 12:36, 22 June 2024 (UTC)

ParserFunctions in extension.json

3
Emwiemaikel (talkcontribs)

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?

Legoktm (talkcontribs)

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?

Emwiemaikel (talkcontribs)

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.

Reply to "ParserFunctions in extension.json"

ParsoidModules extension module is still actual ?

5
Summary by Wladek92

done; thanks.

Wladek92 (talkcontribs)
Shirayuki (talkcontribs)
Wladek92 (talkcontribs)

So what becomes the first url {{Class doclink|class=Wikimedia\Parsoid ....  ?

Shirayuki (talkcontribs)

Yes Done

Wladek92 (talkcontribs)
Tgr (WMF) (talkcontribs)

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)?

MGChecker (talkcontribs)

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.

Tgr (WMF) (talkcontribs)

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.

Jdforrester (WMF) (talkcontribs)

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.).

MGChecker (talkcontribs)

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.

Reply to "Section ordering"

merge strategy for flat arrays?

1
Summary by SamanthaNguyen

https://phabricator.wikimedia.org/T163114 Was resolved in April 2017 and https://phabricator.wikimedia.org/T142663 was declined in September 2017

Jdlrobson (talkcontribs)
Summary by SamanthaNguyen

Seems to be resolved, there was a misunderstanding since the edit summary I made was worded a bit badly

MGChecker (talkcontribs)

@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?

SamanthaNguyen (talkcontribs)

@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.

MGChecker (talkcontribs)

Oh, I didn't think about that. You are right that any extension using a platform key requires MW 1.32 just by doing so.

There are no older topics