CiviCRM 5.79, which will be released around November 7 2024, will include a slightly different experience for administrators who wish to install extensions. On the surface, it is a rather small change which will make CiviCRM easier to use though it may have a bigger impact for CiviCRM hosting providers and for extension developers.
The change: administrators will now be able to install in-app any CiviCRM stable extension that is available in the extension directory, instead of only those that were tagged as reviewed. This was already possible in the past, but it required changing a setting using the API Explorer.
Here is what it will look like when installing an unreviewed extension:
Notice the big red warning, as well as the warning indicator next to the version. Extensions that have been reviewed display a green trophy, similar to the extension directory on civicrm.org. A similar warning will soon be added to civicrm.org as well.
We also changed the sort order of the extensions. Previously, they were sorted in the order that they were added to the extension directory. Now, reviewed extensions are displayed first, then unreviewed. In both lists, they are sorted by their reported number of installs (popularity).
To keep the old behaviour, you can modify the civicrm.settings.php file and add the following line:
$civicrm_setting['domain']['ext_repo_url'] = "https://civicrm.org/extdir/ver={ver}|ready=1";
The above can be added at any time, it will not have any impact on CiviCRM prior to 5.79.
Why did we do this change? There are a few reasons. The bottom line is that we wanted to make CiviCRM easier for both administrators and for developers.
The initial reason was that if an administrator installed an unreviewed extension manually, they then would not receive notifications about new versions. This was a regular topic of confusion on the CiviCRM chat. It was documented in the issue core#3035 almost 3 years ago. It caused serious issues, because admins would not be aware of new versions, which might fix serious bugs, security issues, or compatibility with newer versions of CiviCRM or PHP.
Of course, there are solutions to that. For example, we could have added more settings, more code, so that CiviCRM can check a list of extensions that is different than the list available for installation.
In parallel, there were a few conversations going on with extension developers who want their extensions to be easy to install, directly from within the CiviCRM admin interface. In order for an extension to be displayed in that list, it required going through a review. However, there are few reviewers and the process was complicated, despite regular reforms. The initial aim of having reviews, was for security reasons, but it became increasingly a marketing tool. It can be hard to determine if a new extension is secure, unless the reviewer is familiar with the developer's work.
So we had to think about why CiviCRM was behaving that way. Was the additional friction necessary? Why do we have reviewed extensions?
Is the review process going away? No, and we are raising the bar. It's an important criteria for promoting quality extensions. It means that the extension is well-maintained, is stable, and is likely to work in future versions of CiviCRM. This is difficult to evaluate unless the extension has a rather high number of users and has been around for some time. In the past months, we have been putting more pressure on extension developers so that they fix important CiviCRM or PHP compatibility issues. A few developers have taken the habit of testing important changes against extensions in the directory, so that they can be proactively fixed before the next release if necessary (h/t @eileen and @coleman).
Has the security model changed? Not really. Administrators could already use the API Explorer in order to change the setting which controls which extensions are displayed from the Manage Extension screen.
Are unreviewed extensions dangerous? Maybe. Maybe not. They could be buggy, but so can reviewed extensions. As new versions of CiviCRM are published every month, and when developers update their extensions (or forget to do so), there is no guarantee that the new combination will not crash a CiviCRM installation.
However, it doesn't mean that suddenly, code written by malicious developers will be deployed to any CiviCRM instance. To do so, it would require a developer to create an account on civicrm.org. Accounts are then manually approved. Then to add an extension to the directory, developers must ask for permission on the CiviCRM chat. We then review again, based on the history of that person, whether we trust them. It also gives them blogging permission. Then they can add their extension, which triggers an email alert to a few administrators. Since extensions are sorted status and popularity, the extension is then at the complete bottom of the list. So the odds of it being installed by accident are quite small.
Won't beta versions crash sites? A while back, we stopped adding alpha and beta versions of extensions to the directory, exactly for this reason. Only versions tagged as stable are added, and trigger an update notification. If someone wants to try a beta, they have to manually download it from Gitlab or Github.
What about buggy extensions? If you can, open an issue on their Gitlab/Github issue queue, and post a link to that issue on the extension channel of the CiviCRM chat. We can work with the extension developers to fix the issue or we might change the status to "work in progress", so that it is no longer available from the Manage Extensions screen. This will also help anyone who browses the extensions directory on civicrm.org and install extensions manually.
What if I don't trust administrators? Well, administrators can delete pretty much any type of data, mess around with Financial Accounts in ways that will make your head hurt, export data to CSV files and leave them unsecure on their computer, misconfigure permissions on profiles, SearchKits or Reports, change CMS permissions, etc. Installing unreviewed extensions is probably the less risky of anything an administrator can do. Typically, the worst case scenario is that something crashes (maybe all the site, or maybe just a form), and then someone will have to remove the extension using ssh/ftp, if the site is completely unresponsive.
The good news, is that CiviCRM has a very granular permission system. A while back, the "Administer CiviCRM" permission was split into two: "Administer CiviCRM data" and "Administer CiviCRM system" (h/t @guyiac). However, many parts of CiviCRM do not yet use those more granular permissions.
What if I don't want my extension to be installable from CiviCRM? On civicrm.org, you can change the status of your extension to "work in progress".
In conclusion... it's a small but important change to be aware of. It has already received a lot of feedback from developers and administrators, and we tried to address most of those concerns. Let's make CiviCRM easier to use to the average admin. As CiviCRM has grown and evolved, we sometimes neglect the experience for the newbie techie who just wants to try it out. Yet, that is how many of us started using CiviCRM. For large organisations, they have the tooling and expertise to handle edge cases that concern them. And if an extension is buggy or insecure, let's fix it.
