extensions-directory issueshttps://lab.civicrm.org/extensions/extensions-directory/-/issues2023-03-21T14:27:59Zhttps://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/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/29Meta-Level Question: GSOC Projects - include them on GitLab or GitHub/make th...2023-03-08T13:49:45ZCM ToolanMeta-Level Question: GSOC Projects - include them on GitLab or GitHub/make them more accessible?Wasn't sure where to put this! It's basically a meta-level question about GSoC projects.
There's been some neat work done on old GSoC projects, but I don't seem to see those extensions pulled into the CiviCRM ecosystem somewhere, for f...Wasn't sure where to put this! It's basically a meta-level question about GSoC projects.
There's been some neat work done on old GSoC projects, but I don't seem to see those extensions pulled into the CiviCRM ecosystem somewhere, for further development. Even assuming the extensions might need more work/polishing before being officially released on https://civicrm.org/extensions , right now it seems like they're sort of 'floating' in the informal institutional memory in Mattermost chat channels, rather than being put somewhere were a developer not on the GSoC original project might naturally come across them and continue to develop them.
https://github.com/siddharthg/org.civicrm.civisocial
https://gitlab.com/asludds/civicrm-turfcutter
Is there some way to bring these into the CiviCRM gitlab/github ecosystem? I'm particularly looking at these two, because I'm volunteering with a political advocacy group, and even just some development on these areas would be of interest on us (and I only found these by stumbling across the channels in Mattermost). I don't know if there are other GSoC projects floating out there, but I'd love to know! :)https://lab.civicrm.org/extensions/extensions-directory/-/issues/20Automated release system email warning about older release2023-03-08T13:05:12ZxurizaemonAutomated release system email warning about older releaseI have this email from the automated release system:
> This is a message from the automated release system on civicrm.org. Congratulations on releasing version v1.1 of extension 'Environment Indicator Integration'.
>
> Unfortunately we...I have this email from the automated release system:
> This is a message from the automated release system on civicrm.org. Congratulations on releasing version v1.1 of extension 'Environment Indicator Integration'.
>
> Unfortunately we have found a few errors while processing your release:
> - The version numbers in the info.xml ("1.0") and in the git tag ("1.1") do not match.
>
> You will need to correct these errors before we can accept this release.
The current release of that extension is 1.2 at https://civicrm.org/extensions/environment-indicator-integration
Is there a way to prevent these notifications for releases other than the current release of an extension?
* Download URL: https://github.com/fuzionnz/nz.co.fuzion.environmentindicator/archive/v1.2.zip
* Version in release: 1.2
* Repo: https://github.com/fuzionnz/nz.co.fuzion.environmentindicator
* Uploaded info.xml: https://civicrm.org/sites/civicrm.org/files/extensions/info_315.xml
* CiviCRM extension node: https://civicrm.org/extensions/environment-indicator-integration
AFAICT there isn't a node on CiviCRM.org for v1.0 or v1.1https://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/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/44Proposal: Simpler review process for trusted developers (for automatic in-app...2022-10-11T15:23:05ZbgmProposal: Simpler review process for trusted developers (for automatic in-app distribution)Considering:
* The extension review process is fairly simple, but can create delays because there are few people doing reviews.
* The depth of our reviews is based on trust
* We also trust that, once an extension is approved, an author ...Considering:
* The extension review process is fairly simple, but can create delays because there are few people doing reviews.
* The depth of our reviews is based on trust
* We also trust that, once an extension is approved, an author will not publish a malicious update.
I hereby propose that we maintain a list of "trusted" extension developers who may fast-track the review process:
* Extension authors would still have to open an issue in the review queue: https://lab.civicrm.org/extensions/extension-review-requests/-/issues/
* Reviewers can use the review criteria to explain why they are approving the extension for automatic distribution, but would not be required to do in-depth testing of the extension or review of the code.
To become a trusted reviewer:
* Open an issue in the review queue: https://lab.civicrm.org/extensions/extension-review-requests/-/issues/
* Explain why you would like to be a trusted developer.
* Approval by EXT-WG leads (who may ask for more information if necessary).
Criteria for trusted developers:
* At least 1 year experience writing CiviCRM extensions or core PRs (provide a link/details)
* and published at least 1 other extensions that has some traction (an extension with over 100 users, according to stats)
* and provides community support for existing extensions (relatively responsive on issue trackers).
cc @AllenShaw @MikeyMJCOhttps://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/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/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/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/16Prepare specification of information that will assist users in deciding wheth...2022-08-28T13:47:44ZginkgofjgPrepare specification of information that will assist users in deciding whether to install an extensionPer @mattwire, some work to prepare such a document was done at the recent London sprint. I've reached out to the author (clairew) to request access. Ultimately, we'd like to use this user input to build a specification for the new in-ap...Per @mattwire, some work to prepare such a document was done at the recent London sprint. I've reached out to the author (clairew) to request access. Ultimately, we'd like to use this user input to build a specification for the new in-app extensions UI.ginkgofjgginkgofjghttps://lab.civicrm.org/extensions/extensions-directory/-/issues/17Add link to further documentation2022-08-28T13:45:36ZMichael McAndrewAdd link to further documentationFollowing on from https://lab.civicrm.org/extensions/extensions-directory/issues/13, it would be good to add a header to the boiler plate along the lines of
```
### Documentation
(*FIXME: Where can one find full documentation for this...Following on from https://lab.civicrm.org/extensions/extensions-directory/issues/13, it would be good to add a header to the boiler plate along the lines of
```
### Documentation
(*FIXME: Where can one find full documentation for this extension? If all the
documentation that this extension requires is contained in this readme, feel
free to delete this heading.*}
```https://lab.civicrm.org/extensions/extensions-directory/-/issues/13boilerplate for extension readme and documentation2022-08-28T13:37:50ZMichael McAndrewboilerplate for extension readme and documentation@mattwire is going to implement boilerplate for extension documentation. Anne Smale and Claire Williams have worked on some user oriented guidelines that can be used for writing this documentation (which they can add to this ticket).
I ...@mattwire is going to implement boilerplate for extension documentation. Anne Smale and Claire Williams have worked on some user oriented guidelines that can be used for writing this documentation (which they can add to this ticket).
I appreciate that this is the extensions directory project but I wasn't aware of a better place for it. I'd be happy to move if you let me know where.https://lab.civicrm.org/extensions/extensions-directory/-/issues/8Support multiple authors for extensions2022-08-28T13:36:21Zmattwiremjw@mjwconsult.co.ukSupport multiple authors for extensionsSupport specifying multiple authors in the extension info.xml.
We can't add multiple author/email tags as (the core extension browser) parses those as a string and will display "Array (Array)" if you specify more than one.
So my proposa...Support specifying multiple authors in the extension info.xml.
We can't add multiple author/email tags as (the core extension browser) parses those as a string and will display "Array (Array)" if you specify more than one.
So my proposal is that we add authors/emails tags that UI components parse as a string/array in which you can specify additional authors:
```
<maintainer>
<author>Mr Ben</author>
<email>ben@example.org</email>
<authors>Bob</authors>
<emails>bob@example.org</emails>
<authors>Bert</authors>
<emails>bert@example.org</emails>
</maintainer>
```
See https://github.com/mattwire/civicrm-core/tree/extension_multiple_authors for a PR that makes this work in the core extensions browser.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/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/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/7Investigate point-release compatibility for extensions2021-03-16T21:37:19ZginkgofjgInvestigate point-release compatibility for extensionsWhat are the barriers to flagging an extension as compatible with 4.7.13+, for example?
Brain dump:
* Presently the notation in info.xml supports explicit version numbers, not patterns like you see elsewhere in composer.json, etc. (It ...What are the barriers to flagging an extension as compatible with 4.7.13+, for example?
Brain dump:
* Presently the notation in info.xml supports explicit version numbers, not patterns like you see elsewhere in composer.json, etc. (It would be really tedious as an extension maintainer to have to update info.xml for each point release if there are no other code changes.)
* There is presumably some service which tells CiviCRM instances out in the wild which versions of which extensions are compatible with their instance. This would need to be updated.
* We'll need to support the old way of doing things, of course. Can't go breaking the service for people who aren't on the bleeding edge.
* We may want to update the extdir module which fetches release metadata from GitHub, publishes extension releases, etc. to display human-readable version-compatibility strings.
Useful links:
* [extdir](https://github.com/civicrm/civicrm-org-platform/tree/master/sites/all/modules/custom/extdir) - module responsible for scraping GitHub and updating the extensions directory
* [mock extdir build](https://github.com/civicrm/civicrm-extdir-example) - buildkit build type which mocks (to some extent) the URL used to refresh the extension cache (e.g., https://civicrm.org/extdir/ver=4.7|cms=Drupal)AllenShawAllenShaw