Answers.Body: <p>The <code>ext</code> 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.</p>
  
  <p>See also <a href="https://docs.civicrm.org/sysadmin/en/latest/customize/extensions/#enabling-extensions" rel="noreferrer">https://docs.civicrm.org/sysadmin/en/latest/customize/extensions/#enabling-extensions</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-05T20:19:42.587Z
Answers.Text: That’s a good point!
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-05T18:41:27.643Z
Answers.LastActivityDate: 2019-12-05T18:41:27.643Z
Answers.UserDisplayName: Demerit
Answers.Body: <p>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. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-05T18:44:09.527Z
Answers.LastActivityDate: 2019-12-05T18:44:09.527Z
Answers.UserDisplayName: KarinG - Semper IT
Answers.Body: <p>There are several things in play at different levels with regard to the CiviCRM extensions directory location. The concepts to be aware of are:</p>
  
  <ul>
  <li>CiviCRM shipping codebase</li>
  <li>Drupal multisite</li>
  <li>Drupal's files directory</li>
  </ul>
  
  <h2>CiviCRM bundled extensions</h2>
  
  <p>As <a href="https://civicrm.stackexchange.com/a/33990/149">@Demerit's answer states</a>, <code>sites/&lt;sitename&gt;/modules/civicrm/ext</code> 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.</p>
  
  <p>(Would be good to add a link here to <em>which</em> extensions are bundled with core? This list will vary over time but presumably there's a <code>core-extensions.json</code> or something like that in the build process. IDK.)</p>
  
  <h2>Drupal multisite directory</h2>
  
  <ul>
  <li><code>sites/default</code></li>
  <li><code>sites/all</code></li>
  <li><code>sites/example.org</code></li>
  </ul>
  
  <p>This level of the structure relates to <a href="https://www.drupal.org/docs/7/multisite-drupal/multisite-mapping-with-drupal" rel="nofollow noreferrer">Drupal's multisite mapping</a>. Drupal will read modules, themes, etc from two of these: whichever best matches the current site, and <code>sites/all</code>. 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 <code>sites/all/civicrm</code> and <code>sites/example.org/civicrm</code> 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.</p>
  
  <p>Above and below, the active multisite directory and the shared directory (<code>default</code>, <code>example.org</code> etc and <code>all</code> also) will be referred to as <code>&lt;sitename&gt;</code>.</p>
  
  <h2>Drupal files directory</h2>
  
  <p>Drupal's <code>sites/&lt;sitename&gt;/files</code> 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 <a href="https://www.drupal.org/docs/7/install/setting-up-the-files-directory" rel="nofollow noreferrer">Drupal public file directory documentation</a> for more.</p>
  
  <p>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 <a href="https://civicrm.stackexchange.com/a/33991/149">KarinG's answer is referring to</a>. Others will prefer the convenience of allowing applications to self-manage and therefore self-update.</p>
  
  <p>CiviCRM's default placement of extensions in <code>sites/&lt;sitename&gt;/files/civicrm/extensions</code> reflects the latter position, as CiviCRM can then download and run extensions from within that directory.</p>
  
  <p>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 <code>sites/&lt;sitename&gt;/civicrm/extensions</code>, <code>sites/&lt;sitename&gt;/civicrm-ext</code> etc. Since this isn't a Drupal practice there's no established standard for the structure.</p>
  
  <h2>CiviCRM ain't Drupal</h2>
  
  <p>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 <code>/tmp/whatever</code> and CiviCRM would function quite fine. Only convention, if you subscribe to it, dictates that the extensions might live alongside Drupal modules, themes etc.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-08T09:13:06.967Z
Answers.Text: 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.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-08T21:08:22.577Z
Answers.Text: Thanks Chris! Can I use this to update Docs?
Answers.UserDisplayName: Joe McLaughlin
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-09T03:08:50.100Z
Answers.Text: 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.
  `
Answers.UserDisplayName: Joe McLaughlin
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-10T22:49:10.310Z
Answers.Text: 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.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-12-08T09:12:37.540Z
Answers.LastActivityDate: 2019-12-10T22:50:59.883Z
Answers.LastEditDate: 2019-12-10T22:50:59.883Z
Answers.UserDisplayName: Chris Burgess
Body: <p>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. </p>
  
  <p>Why is that? </p>
  
  <p>I don't see that recommendation/practice in the docs anywhere, or at least not at <a href="https://docs.civicrm.org/sysadmin/en/latest/customize/extensions/" rel="nofollow noreferrer">https://docs.civicrm.org/sysadmin/en/latest/customize/extensions/</a> </p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-12-05T18:01:42.780Z
Comments.Text: 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?
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-12-05T18:15:54.077Z
Comments.Text: 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.
Comments.UserDisplayName: Joe McLaughlin
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-12-05T18:21:21.523Z
Comments.Text: 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.
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-12-05T18:29:37.667Z
Comments.Text: 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?
Comments.UserDisplayName: Joe McLaughlin
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-12-05T18:37:43.320Z
Comments.Text: Docs are here https://docs.civicrm.org/sysadmin/en/latest/customize/extensions/#suggested-directory-location. I'll add an answer.
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-12-05T18:39:54.543Z
Comments.Text: Thanks Demerit there is this in the docs, but it is not explicit about the utility of using another extensions directory - `Other Extension Locations
  
  CiviCRM will find, use and (via the web interface) manage extensions in the url and path location defined above, the "default" extension location for your install.
  
  But CiviCRM will also find and use extensions in other locations. These locations might be populated by other mechanisms - e.g. a vetted subset of all extensions that are made available by default by a hosting provider.`
Comments.UserDisplayName: Joe McLaughlin
Tags: <drupal><extension>
Title: Why should I use an ~/extensions directory rather than the default ~/ext for new extensions?
ThreadText: # Why should I use an ~/extensions directory rather than the default ~/ext for new extensions?
  
  (Asked by: username_0 on 2019-12-05)
  
  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/>
  
  **Tags:** drupal, extension
  
  > **Comments:**
  > **username_1**: 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?  
  > **username_0**: 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.  
  > **username_2**: 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.  
  > **username_0**: 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?  
  > **username_2**: Docs are here https://docs.civicrm.org/sysadmin/en/latest/customize/extensions/#suggested-directory-location. I'll add an answer.  
  > **username_0**: Thanks username_2 there is this in the docs, but it is not explicit about the utility of using another extensions directory - `Other Extension Locations  CiviCRM will find, use and (via the web interface) manage extensions in the url and path location defined above, the "default" extension location for your install.  But CiviCRM will also find and use extensions in other locations. These locations might be populated by other mechanisms - e.g. a vetted subset of all extensions that are made available by default by a hosting provider.`  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2019-12-08. Score: 5 | Accepted answer
  
  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 [@username_2's answer states](https://civicrm.stackexchange.com/a/33990/149), `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](https://www.drupal.org/docs/7/multisite-drupal/multisite-mapping-with-drupal). 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](https://www.drupal.org/docs/7/install/setting-up-the-files-directory) 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 [username_3's answer is referring to](https://civicrm.stackexchange.com/a/33991/149). 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.
  
  > **Comments:**
  > **username_1**: 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.  
  > **username_0**: Thanks username_1! Can I use this to update Docs?  
  > **username_0**: Also username_1 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. `  
  > **username_1**: 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.  
  
  ---
  
  ### Answer by username_2 on 2019-12-05. Score: 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>
  
  > **Comments:**
  > **username_3**: That’s a good point!  
  
  ---
  
  ### Answer by username_3 on 2019-12-05. Score: 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.
  
  
  ---
  
  