extensions-directory issueshttps://lab.civicrm.org/extensions/extensions-directory/-/issues2021-03-17T11:38:06Zhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/40Add hook to check info.xml version number on pushing tags2021-03-17T11:38:06Zsluc23Add hook to check info.xml version number on pushing tagsAdd gitlab upgrade hook to check if info.xml version metadata is the same as the tag pushed, if not reject the tagAdd gitlab upgrade hook to check if info.xml version metadata is the same as the tag pushed, if not reject the tagsluc23sluc23https://lab.civicrm.org/extensions/extensions-directory/-/issues/19Condense Installation x 3 to a single header with more explanation2017-11-08T23:03:41ZMichael McAndrewCondense Installation x 3 to a single header with more explanationSee https://lab.civicrm.org/extensions/extensions-directory/issues/13
https://github.com/totten/civix/blob/master/src/CRM/CivixBundle/Resources/views/Code/readme.md.php has three different headers for installation instructions. A single...See https://lab.civicrm.org/extensions/extensions-directory/issues/13
https://github.com/totten/civix/blob/master/src/CRM/CivixBundle/Resources/views/Code/readme.md.php has three different headers for installation instructions. A single header with 'delete as appropriate' is probably more user friendly for both the extension author and consumer.https://lab.civicrm.org/extensions/extensions-directory/-/issues/38Extensions directory v2019.102019-07-24T13:15:05ZtottenExtensions directory v2019.10The main `civicrm.org` website currently runs Drupal 7. There's an on-going process to [upgrade it](https://lab.civicrm.org/marketing/civicrm-website/wikis/2019-cms-upgrade) around the time of the Barcelona community summit (Oct 2019). (...The main `civicrm.org` website currently runs Drupal 7. There's an on-going process to [upgrade it](https://lab.civicrm.org/marketing/civicrm-website/wikis/2019-cms-upgrade) 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:
1. A public web-page for browsing/filtering extensions and their releases
2. A backend web-page for submitting extensions and releases
3. Workflow tools for extension [reviewers](https://docs.civicrm.org/dev/en/latest/extensions/lifecycle/#formal-review)
4. A backend job for scanning each extensions' git repo for new releases
5. 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).https://lab.civicrm.org/extensions/extensions-directory/-/issues/39GitLab CI for basic extension review checks.2021-03-16T21:29:25ZhomotechsualGitLab CI for basic extension review checks.Placeholder for further discussion and examples/fleshing out a possible approach to GitLab CI for extension review...Placeholder for further discussion and examples/fleshing out a possible approach to GitLab CI for extension review...homotechsualhomotechsualhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/42Make searching GitLab (Extensions) easier with an external search integration...2022-08-28T17:58:26ZhomotechsualMake searching GitLab (Extensions) easier with an external search integration...Options include:
* ElasticSearch
* SourceGraph
... (to be updated!)Options include:
* ElasticSearch
* SourceGraph
... (to be updated!)homotechsualhomotechsualhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/48Should Civi core provide a secure, standardized approach if extensions want t...2021-03-17T15:25:57ZherbdoolShould Civi core provide a secure, standardized approach if extensions want to provide automatic self-updating? (Such as what CiviMobileAPI does)CiviMobileAPI provides functionality for automatic self-updating (e.g. https://lab.civicrm.org/extensions/civimobileapi/-/blob/master/CRM/CiviMobileAPI/Utils/Extension.php). Some of it is using core API, but some of it is doing its own t...CiviMobileAPI provides functionality for automatic self-updating (e.g. https://lab.civicrm.org/extensions/civimobileapi/-/blob/master/CRM/CiviMobileAPI/Utils/Extension.php). Some of it is using core API, but some of it is doing its own thing with hardcoded values:
```
/**
* Get latest version of extension download link
*/
public static function getLatestVersionDownloadLink() {
$version = CRM_CiviMobileAPI_Utils_VersionController::getInstance();
$downloadUrl = 'https://lab.civicrm.org/extensions/civimobileapi/-/archive/';
$downloadUrl .= $version->getLatestFullVersion() . '/civimobileapi-' . $version->getLatestFullVersion() . '.zip';
return $downloadUrl;
}
```
As far as I know Civi doesn't do any package signing to make this process more secure. At the very least, I think Civi should centralize this process to make this more secure.
Some things that would make this more secure:
* package signing
* put the toggle for automatic updates on the main extensions page. Perhaps a toggle for each extension.
* provide core API for the whole process so extensions don't need to roll their own approach.
* ensure that an extension is using an official path.https://lab.civicrm.org/extensions/extensions-directory/-/issues/9Support extension dependencies2022-08-28T10:49:42Zmattwiremjw@mjwconsult.co.ukSupport extension dependenciesWe need to support dependencies for extensionsWe need to support dependencies for extensionshttps://lab.civicrm.org/extensions/extensions-directory/-/issues/64Support PHP version constraints in info.xml2023-09-07T23:46:01ZBjörn EndresSupport PHP version constraints in info.xmlWe (at SYSTOPIA) would like to be able to list known compatible and incompatible PHP versions in the extensions' ``info.xml``.
Our current idea is to base the format on the CiviCRM Core version compatibility, which is expressed as a li...We (at SYSTOPIA) would like to be able to list known compatible and incompatible PHP versions in the extensions' ``info.xml``.
Our current idea is to base the format on the CiviCRM Core version compatibility, which is expressed as a list of positive/compatible examples. This way this section of the ``info.xml`` would look something like this:
```
...
<compatibility>
<ver>5.63</ver>
</compatibility>
<phpCompatibility>
<ver>8.0</ver>
</phpCompatibility>
<phpIncompatibility>
<ver>7.4</ver>
</phpIncompatibility>
...
```
Please note that we added the ``phpIncompatibility`` too, so we could express specific known incompatibilities.
Of course, the of new tags ``phpCompatibility`` and ``phpIncompatibility`` would be optional.
Since I've received moderately positive, but diffuse feedback on the [extension channel](https://chat.civicrm.org/civicrm/pl/rhywwtb9n7nn5knrsoxwapg39r) about the details, I've opened the discussion here.Björn EndresBjörn Endres