Wagtail package directory

Challenge

Wagtail plugins are a bit hard to discover, as they are scattered across several channels:

• https://pypi.org/search/?c=Framework+%3A%3A+Wagtail
• https://djangopackages.org/grids/g/wagtail-cms/
• https://github.com/springload/awesome-wagtail
• https://github.com/search?q=wagtail
• https://stackoverflow.com/search?q=[wagtail]+menu

Proposal

Lets build an official listing of Wagtail community plugins.

Rationale

Having an official ‘Wagtail plugins’ app, linked to the primary Wagtail website, would help new developers find out what is available to help them build their Wagtail site and user experience.

Data model

This is a work in progress, and is subject to change through discussion.

The initial data model would contain at least the following elements.

Package

The main entity in the ‘package directory’. It could be based on the Wagtail Page class, and might have the following fields:

• title: name of the package
• description: rich text
• sourcecode_link: link to a repository page, such as on GitHub or Gitlab
• support_link: link to a place where users can get support, such as GitHub/Gitlab issues pages
• category: selection of one (or more?) category where this plugin should be listed

Automated package analytics

Similar to the Django package index, the Wagtail package directory can collect statistics from the upstream sources, such as GitHub. These statistics could be collected via calls to an API, which would probably need a task runner, like Celery.

Examples for inspiration

• DjangoCMS
• Drupal
• Joomla!
• Mezzanine
• TYPO3, Wordpress

Original discussion

This idea was brought up while discussing issue #4910

[thibaudcolas]

Having worked on both https://github.com/springload/awesome-wagtail and https://madewithwagtail.org/, I find that maintaining such listings takes a lot of effort when they are centrally managed, as opposed to aggregated. It’s not just managing the content, but also maintaining the site (upgrades, bug fixes, user administration). Since packages for Wagtail already exist in a central registry (PyPI), I’d strongly suggest integrating their APIs instead of creating another source of truth.

If creating another listing, IMHO having it versioned and editable via GitHub is one of the best ways to reduce the maintenance burden. Most people making packages will already have GitHub accounts, be aware of the PR workflow, and from the maintainer’s side it’s very easy to manage those submissions. Then you can focus on building a nice UI for the listing, instead of the management workflow.

---

From the wagtail.io side, I think a page pointing to the existing listings would already be super valuable, perhaps also with better documentation on how to create good, discoverable Wagtail packages. At the moment the Developing packages for Wagtail docs are a bit hidden, and very short.

[allcaps]

There has been progress:

Wagtail Packages that are listed on PyPi are added to Djangopackages.org. See https://www.fourdigits.nl/blog/wagtail-packages/.

Djangopackages.org will be the -community editable- data source to feed a Wagtail package directory page on wagtail.io. See https://github.com/wagtail/wagtail.io/pull/74