Extensions directory v2019.10
The main civicrm.org
website currently runs Drupal 7. There's an on-going process to upgrade it around the time of the Barcelona community summit (Oct 2019). (I believe that the new platform is D8, although I'm not certain that's final yet. The linked wiki lists evaluations of possible migrations. At time of writing, I only see a full entry for D8.)
The extension directory was originally built as a set of D7 modules, content-types, views. Migrating to D8 (or WP) is a significant undertaking and an opportunity to reconsider these workflows. This means we're running down a clock and need to reassess/reimplement/port/etc.
The current functionality of the directory includes:
- A public web-page for browsing/filtering extensions and their releases
- A backend web-page for submitting extensions and releases
- Workflow tools for extension reviewers
- A backend job for scanning each extensions' git repo for new releases
- A web-service/feed used by CiviCRM sites to list available/compatible extensions
Concurrently, at the recent sprints, we discussed https://lab.civicrm.org/infra/comex/ - which is working POC micro-service. It provides (4) backend scanner and (5) web-service/feed (independent of the civicrm.org
CMS). It adds some significant functionality (i.e. composer bridge; also, automatic handling of silly info.xml
fields like <releaseDate>
and <stability>
). However, currently, it only works with extensions published via Git (any public git repo is OK), and does not provide (1) public web-page for browsing extensions, (2) backend web-page for submitting extensions, or (3) workflow tools for reviewers.
I've filed this issue specifically because items (1), (2), and (3) need some planning/attention.
List of general approaches
This part of the ticket should try to keep an index of general approaches.
- (P1) Forward Port: Migrate everything (1,2,3,4,5) as full stack into whatever
c.o
uses next. - (P2) Two Tier: For all UIs (1,2,3), use
c.o
CMS tooling. For backend (4,5), use micro-service. - (P3) Gitlab JSON: For managing the canonical extension list (2,3), use Github/Gitlab PRs. For public browsing (1), use CMS tooling (Feeds+Views?). For backend stuff (4,5), use micro-service.
- (P4) Backdrop "Project": Use Backdrop "Project
___
" modules for (1,2,3). Create submodules or alterations for (4,5).