4

It seems like not an uncommon practice - or at least, by two CiviCRM partner shops that I know of :) - to use an ~/extensions directory for adding new extensions, rather than the default ~/ext directory.

Why is that?

I don't see that recommendation/practice in the docs anywhere, or at least not at https://docs.civicrm.org/sysadmin/en/latest/customize/extensions/

  • What do you mean by ~/extensions? Can you give an example using a site's docroot? & when you say "common practice" - how did you come by that understanding? – Chris Burgess Dec 5 '19 at 18:01
  • For example - /var/www/joe-demo/htdocs/sites/all/civicrm-custom/extensions. By common practice - I know of at least two Civi partner shops that seem to follow the practice. So OK maybe it's not 'common'. Updating. – Joe McLaughlin Dec 5 '19 at 18:15
  • And by ~/ext do you mean the ext dir that's in the tarball download that includes extensions shipped directly with core like IATS? If you put new ones in there they're likely to get wiped during upgrade, so it's common to put them somewhere outside the civi folder. – Demerit Dec 5 '19 at 18:21
  • Yes I mean the default /ext directory. So the answer is "[new extensions] are likely to get wiped during [an] upgrade, so it's common to put them somewhere outside the civi folder." Cool. Want to add that as an Answer and I'll accept it? And is that anywhere in the docs and I have just not found it? – Joe McLaughlin Dec 5 '19 at 18:29
  • Docs are here docs.civicrm.org/sysadmin/en/latest/customize/extensions/…. I'll add an answer. – Demerit Dec 5 '19 at 18:37
5

There are several things in play at different levels with regard to the CiviCRM extensions directory location. The concepts to be aware of are:

  • CiviCRM shipping codebase
  • Drupal multisite
  • Drupal's files directory

CiviCRM bundled extensions

As @Demerit's answer states, sites/<sitename>/modules/civicrm/ext contains the extensions which ship with CiviCRM core. Don't put custom / additional extensions here; they may get deleted or overwritten on upgrade of the CiviCRM codebase.

(Would be good to add a link here to which extensions are bundled with core? This list will vary over time but presumably there's a core-extensions.json or something like that in the build process. IDK.)

Drupal multisite directory

  • sites/default
  • sites/all
  • sites/example.org

This level of the structure relates to Drupal's multisite mapping. Drupal will read modules, themes, etc from two of these: whichever best matches the current site, and sites/all. CiviCRM has a (non-Drupal) concept of multisite, but doesn't care about this level of the structure AFAIK. Your Drupal site developers likely do so if you have sites/all/civicrm and sites/example.org/civicrm you might infer that the latter is applied only to the example.org sites, but you'd need to check CiviCRM configuration to be certain.

Above and below, the active multisite directory and the shared directory (default, example.org etc and all also) will be referred to as <sitename>.

Drupal files directory

Drupal's sites/<sitename>/files directory is configured to be writable to the PHP application (and it's recommended to configure the webserver to prevent direct execution of PHP code in that folder). See Drupal public file directory documentation for more.

Many developers resist having a web application's files writable to the webserver - preventing a web application modifying its own code is a defense against attacks which persist over time by introducing malicious code to files which will be executed by the application later. This is what KarinG's answer is referring to. Others will prefer the convenience of allowing applications to self-manage and therefore self-update.

CiviCRM's default placement of extensions in sites/<sitename>/files/civicrm/extensions reflects the latter position, as CiviCRM can then download and run extensions from within that directory.

Developers who prefer to manage their codebase through tools such as Git may prefer to use the former model and relocate the extensions directory to sites/<sitename>/civicrm/extensions, sites/<sitename>/civicrm-ext etc. Since this isn't a Drupal practice there's no established standard for the structure.

CiviCRM ain't Drupal

It's worth noting that CiviCRM doesn't require you to keep extensions in the webroot at all, unless an extension requires direct access (probably not a good sign?). So you could merrily set the extensions directory to /tmp/whatever and CiviCRM would function quite fine. Only convention, if you subscribe to it, dictates that the extensions might live alongside Drupal modules, themes etc.

| improve this answer | |
  • Understanding UNIX filesystem permissions and code deployment processes will help clarify the why's and hows of all the above too. Hope this helps, sorry about adding a third answer which includes the other two, but it's the best I can do in SE format! Hope I covered all the essentials, please feel free to edit / amend if I've missed anything. – Chris Burgess Dec 8 '19 at 9:13
  • Thanks Chris! Can I use this to update Docs? – Joe McLaughlin Dec 8 '19 at 21:08
  • Also Chris you wrote: CiviCRM's default placement of extensions in sites/<sitename>/files/civicrm/extensions reflects the latter position, as CiviCRM can then download and run extensions from within that directory. Do you mean this: CiviCRM's default placement of extensions in sites/<sitename>/files/civicrm/ext reflects the latter position, as CiviCRM can then download and run extensions from within that directory. – Joe McLaughlin Dec 9 '19 at 3:08
  • Sure, if that's where CiviCRM puts it. I've avoided using the sites/default/files/ext(ensions)? directory so I'll trust you on its location :) And yeah you're welcome to crib from this for docs if it's helpful. – Chris Burgess Dec 10 '19 at 22:49
5

The ext dir that ships in the tarball is for extensions bundled directly with core like IATS. If you put other extensions in there they will get wiped when you upgrade, so it's common to put them somewhere outside the civicrm folder.

See also https://docs.civicrm.org/sysadmin/en/latest/customize/extensions/#enabling-extensions

| improve this answer | |
4

The reason we do that with client sites is because I don’t think it’s a good idea to put code under /files. It belongs at the level of /modules. Permission requirements for code and /files are quite different. Another benefit is that it allows me to more easily put the code for a project in git.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.