extensions-directory issueshttps://lab.civicrm.org/extensions/extensions-directory/-/issues2023-09-07T23:46:01Zhttps://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 Endreshttps://lab.civicrm.org/extensions/extensions-directory/-/issues/63Extension directory should not promote alpha/beta relases if the develStage =...2023-03-21T14:27:59ZbgmExtension directory should not promote alpha/beta relases if the develStage = stableCurrently CiviCRM recommends that admins always use the latest version of an extension, regardless if it is an alpha or beta release. This happens in-app and on the extension directory.
Proposal:
If the extension "Development Status" i...Currently CiviCRM recommends that admins always use the latest version of an extension, regardless if it is an alpha or beta release. This happens in-app and on the extension directory.
Proposal:
If the extension "Development Status" is set to "stable" on the ext directory, then ignore alpha/beta releases.
Implementation details: the easiest solution would be that the release-scanner would ignore alpha/beta in those situations.
- On the Extension directory: the big blue "Download" button should link to the latest stable
- In the list of releases: ignore alpha/beta, because they are noise
- Under the list of releases: we could link to the list of releases on Gitlab/Github and say "View all releases on Gitlab"?
Some people may have concerns about the visibility of beta releases, but I have to ask: what are their purpose? If they are for developers, then developers can get notifications via Gitlab/Github, or they might read an issue that says "go test this beta" with a link to gitlab/github.
Similarly, https://civicrm.org/download links to stable releases, and not beta. They are linked at the bottom.
If there are concerns about the level of support that admins/users should expect, I think that is a separate discussion (the short version has always been, as with core, "no expectations").
[discussion on the chat](https://chat.civicrm.org/civicrm/pl/gr1gynmii78bicyygy33ky5gey)https://lab.civicrm.org/extensions/extensions-directory/-/issues/62Improve guidance on transferring extensions from Github2022-08-28T13:33:48ZxurizaemonImprove guidance on transferring extensions from GithubWith reference to this wiki doc:
- https://lab.civicrm.org/extensions/extensions-directory/-/wikis/import-from-github
It currently says:
> * In Github, create a new [personal Github token](https://github.com/settings/tokens)
> * In Gi...With reference to this wiki doc:
- https://lab.civicrm.org/extensions/extensions-directory/-/wikis/import-from-github
It currently says:
> * In Github, create a new [personal Github token](https://github.com/settings/tokens)
> * In Gitlab, create a new project under your own personal project space (ex: lab.civicrm.org/janedoe/myextension)
> * Go to the Import tab, then select Github
> * Enter the access token
> * Careful to only import the given project (do not click that tempting "import all" button)
I propose:
> * In Github, create a new [personal Github token](https://github.com/settings/tokens), granting the **repo** scope.
> * In Gitlab, create a new project under your own personal project space (ex: lab.civicrm.org/janedoe/myextension)
> * Go to the Import tab, then select Github
> * Enter the access token
> * Careful to only import the given project (do not click that tempting "import all" button)
This will inorporate guidance around which permissions are required for the operation..https://lab.civicrm.org/extensions/extensions-directory/-/issues/61"You rock" appears for anonymous user (on extensions without a maintainer)2022-02-16T22:12:02ZAllenShaw"You rock" appears for anonymous user (on extensions without a maintainer)Repro:
1. Log out of civicrm.org
2. Visit an extension page for an extension that has no maintainer, for example:
1. https://civicrm.org/extensions/zaakpay-indian-payment-processor
1. https://civicrm.org/extensions/duration
...Repro:
1. Log out of civicrm.org
2. Visit an extension page for an extension that has no maintainer, for example:
1. https://civicrm.org/extensions/zaakpay-indian-payment-processor
1. https://civicrm.org/extensions/duration
1. https://civicrm.org/extensions/notify-speakers
3. At top of any such page, observe the message "You rock! Thank you for maintaining this extension. You can edit the extension description and other fields by clicking on the links at the top of the screen. To add a new release, ... (etc)"https://lab.civicrm.org/extensions/extensions-directory/-/issues/60extdir scanner does not sort alpha/beta versions correctly2023-03-21T12:59:43Zbgmextdir scanner does not sort alpha/beta versions correctlyCopied from #59
> Is there a specific reason we don't do [semantic versioning](https://semver.org) here, or is it just a matter of changing the sort command? In that case, maybe we can adopt [this solution](https://stackoverflow.com/a/...Copied from #59
> Is there a specific reason we don't do [semantic versioning](https://semver.org) here, or is it just a matter of changing the sort command? In that case, maybe we can adopt [this solution](https://stackoverflow.com/a/40391296)...
The fix would indeed require changing the PHP code in extdir, using something equivalent to what you posted (the shell script is just a wrapper to a PHP snippet, which we could re-use).
Code is here:
https://lab.civicrm.org/marketing/civicrm-website/-/blob/d8/modules/custom/extdir/extdir.drush.inc#L285
We can keep this issue open, and fix it next time it happens (the custom module does not have automatic testing, so it's a bit tedious/risky).
cc @BjoernEhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/59CiviSepa: new 1.5 release not being released on c.o2021-03-22T14:02:30ZbgmCiviSepa: new 1.5 release not being released on c.o> I just released CiviSEPA 1.5 (https://github.com/Project60/org.project60.sepa/releases/tag/1.5), but the release doesn't show up in the extension directory (https://civicrm.org/extensions/civisepa-sepa-direct-debit-extension).
cc @Bjo...> I just released CiviSEPA 1.5 (https://github.com/Project60/org.project60.sepa/releases/tag/1.5), but the release doesn't show up in the extension directory (https://civicrm.org/extensions/civisepa-sepa-direct-debit-extension).
cc @BjoernEhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/58Proposal: Require internationalization for "automatic distribution"2022-08-28T17:54:02ZbgmProposal: Require internationalization for "automatic distribution"Currently the review requirements state that internationalization (i18n) is suggested, but not required.
I propose that we change this to required.
* CiviCRM is difficult enough as it is, and it's even more difficult to get started wit...Currently the review requirements state that internationalization (i18n) is suggested, but not required.
I propose that we change this to required.
* CiviCRM is difficult enough as it is, and it's even more difficult to get started with for non-English users, let's remove any barrier we can, by making sure code supports i18n out of the box.
* It creates an extra incentive to send a merge-request to improve i18n, if a bug is found, knowing that the maintain must work towards a fix.
* Incorrect use of strings that do not translate well are often "code smells", clever hacks that often don't age well.
* When extensions are made available for automatic distribution, the strings are automatically extracted and sent to Transifex. For developers, it's fairly easy to wrap strings in `E::ts` & JS/tpl equivalents.
cc @AllenShaw @MikeyMJCOhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/57`privatefields` extension is generating a new release node every day2021-03-16T23:37:06ZDaveD`privatefields` extension is generating a new release node every dayPutting this here instead of against the extension itself since maybe it's a problem with the extdir scan. If you look at https://civicrm.org/extensions/allow-have-private-custom-fields-event-arent-displayed-info-page and cross-reference...Putting this here instead of against the extension itself since maybe it's a problem with the extdir scan. If you look at https://civicrm.org/extensions/allow-have-private-custom-fields-event-arent-displayed-info-page and cross-reference with the log at https://test.civicrm.org/view/Sites/job/Extdir%20Scan%20(civicrm.org) it seems like it's creating a new release node every day. Also not sure if the extensions nodes have pagers on the release tables so it's hard to tell how many copies there are or if it just cuts off.
Came across this as a separate issue while I was trying to troubleshoot why I got some notifications "on-demand" for some extension releases I did but for other extension releases I did around the same time it came overnight.https://lab.civicrm.org/extensions/extensions-directory/-/issues/56Cleaning up the Extensions Directory?2022-08-30T13:53:06Zaydunsaidan.saunders@squiffle.ukCleaning up the Extensions Directory?The role of the Extensions Directory has evolved a bit. I'm not sure whether we have a good description of what it is or should be beyond the intro on the page:
> "Extensions are installable packages which give CiviCRM new functionalit...The role of the Extensions Directory has evolved a bit. I'm not sure whether we have a good description of what it is or should be beyond the intro on the page:
> "Extensions are installable packages which give CiviCRM new functionality, and this directory provides a centralized list of extensions which the CiviCRM community has created."
https://lab.civicrm.org/extensions says:
> CiviCRM extensions repositories. See also the official extension directory on civicrm.org. | ExtDir meta
But it really doesn't look very 'official'!
There are many other extensions not in this directory so it is not a centralized list of all extensions. It seems to be evolving towards a somewhat curated list of extensions that are installable in-app or in some way approved. This is the place we point to if people want to see what else they can do with Civi and forms part of our marketing.
How do we clean up the directory?
We have things like [notify-speakers](https://civicrm.org/extensions/notify-speakers) listing compatibility as 4.2, status of alpha and with a broken download link. This one looks like it may have been an example from Tim at some point but that's just one and there are a many others that could be culled. How do we get rid of these?
We also have many without a meaningful summary, even on the first page of the directory.
Maybe a simple start would be to mail all maintainers of extensions in that directory including links to the edit pages, asking them to review whether the extension should still be listed at all, and if so, to make sure the summary is useful to those browsing the directory.
Thoughts?https://lab.civicrm.org/extensions/extensions-directory/-/issues/55extdir automatic releases ignore unpublished nodes2020-11-26T13:22:21Zbgmextdir automatic releases ignore unpublished nodesReported by @artfulrobot
> "Each day the system generates a new release node for GoCardless 1.10.0beta (it's configured to do this as a draft because the ext requires packaging, if that makes a difference). I have no way (except for tr...Reported by @artfulrobot
> "Each day the system generates a new release node for GoCardless 1.10.0beta (it's configured to do this as a draft because the ext requires packaging, if that makes a difference). I have no way (except for trawling emails) to find a list of all the nodes, but basically they all need deleting; beta testers have downloaded from github so I don't need it released."https://lab.civicrm.org/extensions/extensions-directory/-/issues/54Better default for notification settings when a repo is created for you?2021-02-10T21:57:42ZDaveDBetter default for notification settings when a repo is created for you?Related to https://lab.civicrm.org/extensions/extensions-directory/-/issues/47, can it automatically set the notification setting to "Watch" for the repo when it creates one for you? It sets it to use your global settings. I don't know h...Related to https://lab.civicrm.org/extensions/extensions-directory/-/issues/47, can it automatically set the notification setting to "Watch" for the repo when it creates one for you? It sets it to use your global settings. I don't know how many people have "watch" as their default for the entire extensions project. If most extension authors do then nevermind.https://lab.civicrm.org/extensions/extensions-directory/-/issues/53Proposal: review approval indicated with tag or "@somebody please release", etc.2022-08-28T17:58:57ZAllenShawProposal: review approval indicated with tag or "@somebody please release", etc.The ticket at https://lab.civicrm.org/extensions/extension-review-requests/-/issues/10 shows we're getting more people to do reviews, which is great! As that number increases, more of those reviewers will be able to generate an `approved...The ticket at https://lab.civicrm.org/extensions/extension-review-requests/-/issues/10 shows we're getting more people to do reviews, which is great! As that number increases, more of those reviewers will be able to generate an `approved` review but not actually mark the extension for in-app distribution on c.o.
@bgm or others: Is there a step we can formally ask of reviewers, similar to a "please merge" comment on PRs, that would alert us that the review is completed and approved so we can make that change on c.o?https://lab.civicrm.org/extensions/extensions-directory/-/issues/52Update "labels" wiki page to clarify it's talking about "topics" not labels2023-03-08T13:03:09ZDaveDUpdate "labels" wiki page to clarify it's talking about "topics" not labelsThis page https://lab.civicrm.org/extensions/extensions-directory/-/wikis/extension-gitlab-labels mentions labels but they are actually "topics" which you set in your extension repo under Settings - General.
Labels in gitlab are just fo...This page https://lab.civicrm.org/extensions/extensions-directory/-/wikis/extension-gitlab-labels mentions labels but they are actually "topics" which you set in your extension repo under Settings - General.
Labels in gitlab are just for issues and merge requests.
Gitlab also calls these topics "tags" but that's confusing too because git itself has tags which are a different thing.
I don't have access to edit the wiki page and this repo doesn't seem like it accepts merge requests, so making a ticket here.https://lab.civicrm.org/extensions/extensions-directory/-/issues/51Add a link to create a new extension on the wiki docs2020-07-01T16:53:23ZJonGoldAdd a link to create a new extension on the wiki docsThe wiki docs for [requesting a new extension repo](https://lab.civicrm.org/extensions/extensions-directory/-/wikis/how-to-request-a-new-extension-project-on-gitlab) were unclear to me; I think that it would be helpful to add this to the...The wiki docs for [requesting a new extension repo](https://lab.civicrm.org/extensions/extensions-directory/-/wikis/how-to-request-a-new-extension-project-on-gitlab) were unclear to me; I think that it would be helpful to add this to the wiki as the last step of [Requesting a New Project Space](https://lab.civicrm.org/extensions/extensions-directory/-/wikis/how-to-request-a-new-extension-project-on-gitlab#requesting-a-new-project-space):
* If you have the "blog and extension" permission, you can select [Add an extension to this directory](https://civicrm.org/node/add/extension) from the [main directory page](https://civicrm.org/extensions).https://lab.civicrm.org/extensions/extensions-directory/-/issues/50Can't edit extension nodes on c.o2020-07-01T19:15:28ZJonGoldCan't edit extension nodes on c.oI created a new extension, then wanted to update its status from "WIP" to "Stable". It doesn't seem like there's a mechanism for me to edit this. Then again, I'm not sure if I had an elevated permission to do this on the D7 c.o, or it ...I created a new extension, then wanted to update its status from "WIP" to "Stable". It doesn't seem like there's a mechanism for me to edit this. Then again, I'm not sure if I had an elevated permission to do this on the D7 c.o, or it was just standard.https://lab.civicrm.org/extensions/extensions-directory/-/issues/49CiviDesk says they're no longer maintaining com.cividesk.email.sparkpost - sh...2022-08-28T13:51:43ZherbdoolCiviDesk says they're no longer maintaining com.cividesk.email.sparkpost - should it be marked deprecrated?On https://github.com/cividesk/com.cividesk.email.sparkpost it says:
> As the number of voluntary donations to maintain & support the extension can still be counted with a single hand, maintenance of this extension is officially discont...On https://github.com/cividesk/com.cividesk.email.sparkpost it says:
> As the number of voluntary donations to maintain & support the extension can still be counted with a single hand, maintenance of this extension is officially discontinued. You can still contract Cividesk, or any other CiviCRM provider, for any needed maintenance. Thanks for your understanding.
Should this extension be marked as deprecated? Or should someone else take over?
What happens with the domain if someone else takes over? I assume it can't be under com.cividesk.email.sparkpost.https://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/47Automatically create a repo on lab.c.o when a new extension is added on c.o2023-03-08T13:01:16ZbgmAutomatically create a repo on lab.c.o when a new extension is added on c.oRecap of some online or Barcelona-2019 discussions:
* Currently to create new extensions on Gitlab, we have to ping @bgm on Mattermost. This was meant to be temporary until we find a better procedure (and validate that we want to use Gi...Recap of some online or Barcelona-2019 discussions:
* Currently to create new extensions on Gitlab, we have to ping @bgm on Mattermost. This was meant to be temporary until we find a better procedure (and validate that we want to use Gitlab).
* While Gitlab projects can have tags/labels and there is a search, it's not sufficiently user-friendly for most users. It's unlikely to ever replace the official extension directory on our website.
* We want to encourage using Gitlab:
* Grow our developer community, as a community, i.e. encourage collaboration between developers/shops, reduce shop-centric development silos.
* More user-friendly for CiviCRM users, who are more likely to have a Gitlab/civicrm.org account than a Github account.
Things we can improve:
* Make sure that creating new extensions is as simple as possible (some unused fields have been removed as part of the Drupal8 migration).
* When we create a new extension on civicrm.org, automatically create a Gitlab repository
* Automatically set the description of the project on Gitlab.
* We could eventually do things such as setup a webhook to run extdir-scan when a new tag/release is pushed.
cc @sluc23 @MikeyMJCO @artfulrobot @mattwirebgmbgmhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/46Mosaico is not available for in-app installation2020-05-29T20:28:27ZbgmMosaico is not available for in-app installationTo reproduce:
* Go to Admin > System > Extensions
* Add new -> look for Mosaico.
Flexmailer seems to be there.To reproduce:
* Go to Admin > System > Extensions
* Add new -> look for Mosaico.
Flexmailer seems to be there.bgmbgmhttps://lab.civicrm.org/extensions/extensions-directory/-/issues/45Automatic releases and extension third-party libraries2020-11-26T13:23:17ZbgmAutomatic releases and extension third-party librariesMany (and increasingly) extensions rely on third-party extensions (PHP or JS), which should not be committed to the extension repository (as they may create conflicts, have license issues, add management overhead, or simply clutter the g...Many (and increasingly) extensions rely on third-party extensions (PHP or JS), which should not be committed to the extension repository (as they may create conflicts, have license issues, add management overhead, or simply clutter the git repository).
Examples: Mosaico, [gocardless](https://github.com/artfulrobot/uk.artfulrobot.civicrm.gocardless), [civiexportexcel](https://lab.civicrm.org/extensions/civiexportexcel/-/releases).
When the nightly release manager runs, it links to the tag associated with the release. By default, on Gitlab and Github, those zip files do not includes third-party libraries.
For extensions using libraries, we should explore relying on Gitlab's CI, since:
* Previously, we assumed that extension maintainers would add the releases manually on civicrm.org (this has been deprecated from c.o since the d8 upgrade).
* It also assumes that the release is created before the nightly extdir job runs.
* While the extdir job could check for the presence of release assets, it would assume that maintainers create the assets before the job runs.