Page MenuHomePhabricator

Display autogenerated extension information in Template:Extension
Open, Needs TriagePublic

Description

Module:ExtensionJson contains all the data harvested from extension.json but currently very little of it is used by the extension infobox template. This should be improved.

Event Timeline

Pppery added a subscriber: Pppery.

Is this (and the corresponding edit to the module) good enough to call this task resolved? (Note: I forgot to include "rights" in the edit summary)

Is this (and the corresponding edit to the module) good enough to call this task resolved? (Note: I forgot to include "rights" in the edit summary)

Assuming this is resolved given the lack of response to my above post.

Thanks a lot for your work on this, @Pppery!

I think the fields from extension.json that should be used in the infobox:

  • type
  • version
  • license
  • requires
  • author (maybe; might be differences in wikitext handling)
  • description (maybe; might be differences in wikitext handling)
  • SessionProviders (for categorization)
  • AuthManagerAutoConfig (for categorization)
  • CentralIdLookupProviders (for categorization, maybe display as well)
  • namespaces
  • TrackingCategories (maybe? we can't display the category name though)
  • AvailableRights
  • GrantPermissionGroups (to show new grants)
  • ContentHandlers
  • MediaHandlers
  • SpecialPages
  • Hooks / HookHandlers
  • JobClasses (maybe)
  • LogTypes
  • Actions
  • APIModules etc
  • RestRoutes
  • ParsoidModules (maybe)
  • ServiceWiringFiles

Currently the template supports license and hook information (and configuration parameters, which are definitely useful to extract automatically, but the infobox might not be the best place for them), so I think there is still a long way to go.

Thanks a lot for your work on this, @Pppery!

I think the fields from extension.json that should be used in the infobox:

  • type

This doesn't appear to mean the same thing in extension.json as it does in the infobox. (ex, for AbuseFilter, the repo type is "antispam", whereas the type on wiki is "User activity, Special page, API "

  • version

Already supported (although the related parameter "update", specifying the date the version was released, isn't supported because the data doesn't exist in the module, so I often prefer to update it manually)

  • license

Already supported

  • requires

The "MediaWiki" key can't be supported because most WMF maintained extensions use backward-compatibility branches, and the module only contains data from the master branch. Information about which extensions depend on each other could be added, but (as I explain below) I didn't because there's no way of handling that data within the current wikitext infobox.

  • author (maybe; might be differences in wikitext handling)
  • description (maybe; might be differences in wikitext handling)

This can't be supported because what extension.json actually supplies is a message key, which can't be expanded into human-readable text unless the extension is actually installed on MediaWiki.org

  • SessionProviders (for categorization)
  • AuthManagerAutoConfig (for categorization)

Could you explain in more detail what categories you want to populate? All extensions defining Session/Authentication providers?

  • CentralIdLookupProviders (for categorization, maybe display as well)
  • namespaces
  • TrackingCategories (maybe? we can't display the category name though)
  • AvailableRights

Already supported

  • GrantPermissionGroups (to show new grants)
  • ContentHandlers
  • MediaHandlers
  • SpecialPages
  • Hooks / HookHandlers

Hooks is already supported. HookHandlers isn't yet, because I wrote that code before the new hook system, and in any case that property doesn't appear to be used by any extensions on Gerrit yet.

  • JobClasses (maybe)
  • LogTypes
  • Actions
  • APIModules etc
  • RestRoutes
  • ParsoidModules (maybe)
  • ServiceWiringFiles

Currently the template supports license and hook information (and configuration parameters, which are definitely useful to extract automatically, but the infobox might not be the best place for them), so I think there is still a long way to go.

(each inline comment only applies to the line directly above it)

Most of the remaining fields (that I didn't comment inline about) aren't currently supported by the infobox as wikitext arguments, which is why I didn't implement them, because I didn't want to make the editorial judgement of what information should be supported. That's also why I implemented automatic retrieval of configuration parameters in the infobox; because there was currently a field for them.

For namespaces, what format should they be displayed in? (There seems to be no consistent format among pre-existing Wikitext Extension pages: some specify the PHP constant (like NS_BLOG_PAGE), whereas others show the human readable name (like Module); some pages omit the talk namespace, and some others include them)

As I said above, I'm willing to implement the task "make Template:Extension automatically populate certain parameters" from Module:ExtensionJson. I'm not willing to work on "add new information to the infobox that isn't presently supported in Wikitext", which this task appears to have morphed into.

(Unassigning myself because I'm not currently working on this, although I may be convinced to do more work on it later)