Answers.Body: <p><strong>Context</strong>: When reading data from the CMS, one can either read directly from their database (via <code>DB::connect()</code> and <code>SELECT * FROM user ...</code>) or you can use the CMS's PHP APIs (e.g. <code>user_load(...)</code>). In one sense, reading from SQL directly is more robust (no dependency on complicated PHP code); in another sense, reading from a PHP API is more robust (because it handles all the weird edge-cases of jerry-rigged SQL schema that Drupal allows).</p>
  
  <p><strong>Speculation</strong>: My strong <em>suspicion</em> is that early versions of Civi (like 1.x or 2.x) relied heavily on SQL-based integration. (Witness: the installation process and <code>civicrm.settings.php</code> prominently solicit <code>CIVICRM_UF_DSN</code>), but this doesn't work well in jerry-rigged SQL schema, and it's unpleasant for Civi to be coupled to the CMS SQL, so... it was gradually killed as people fixed bugs.</p>
  
  <p><strong>Current Reality</strong>: I can only find one function that hits the CMS user table directly via SQL -- <code>CRM_Utils_System_*::authenticate()</code>. The details of this are a bit weird and vary by CMS:</p>
  
  <ul>
  <li>In Joomla, WordPress, and D8, <code>authenticate()</code> uses the CMS's PHP APIs. They don't hit SQL directly.</li>
  <li>In D6, <code>authenticate()</code> always queries via <code>DB::connect()</code> and SQL.</li>
  <li>In D7 and Backdrop, <code>authenticate()</code> sometimes queries via <code>DB::connect()</code> and SQL. The way it's written... it's hard to tell if it's ever used. From some grepping... if it is used... it's probably the CiviMail-SOAP adapter (<code>extern/soap.php</code> and <code>CRM/Utils/SoapServer.php</code>).</li>
  </ul>
  
  <p>However, I don't believe this is a hard requirement -- considering that Joomla/WordPress/D8 don't use it. You could probably figure a patch to <code>CRM_Utils_System_*::authenticate()</code> and <code>CRM/Utils/SoapServer.php</code> which allows us to completely remove <code>CIVICRM_UF_DSN</code> and <code>userFrameworkUsersTableName</code>. The main cost would be re-testing the SOAP return-channel in each CMS.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-16T08:43:07.537Z
Answers.Text: There are 2 PRs open for review on this function in SOAP so I suspect it does not currently work right ... https://github.com/civicrm/civicrm-core/pull/8787
Answers.UserDisplayName: eileen
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-16T09:56:50.560Z
Answers.Text: Yeah, I share the general sentiment of "there-be-dragons" in this area. The PR seems to imply that `WordPress::authenticate()` works as long as you bootstrap the CMS. The overwrought bit (tying into Chris's note) is it's a bit of mess understanding which use-cases will boot the CMS. My feeling is that basically everything except `extern/open.php` and maybe `extern/url.php` should enable CMS boootstrap. (Note, though, that this is similar-but-different to making the CMS the sole entry-point.)
Answers.UserDisplayName: Tim Otten
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-20T14:05:18.063Z
Answers.Text: Thanks for both helpful answers. I marked Tim's as accepted because it had a little more detail.
Answers.UserDisplayName: universalhandle
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-16T03:37:40.127Z
Answers.LastActivityDate: 2016-08-16T03:37:40.127Z
Answers.UserDisplayName: Tim Otten
Answers.Body: <p>There are scripts in <code>extern/*.php</code> (like <code>extern/ipn.php</code>) which fire up CiviCRM without the CMS bootstrapped. I believe the plan is to replace them with callbacks (like <code>civicrm/payment/ipn/%id</code>) which eliminate instances where CiviCRM is bootstrapped without the CMS. (<a href="https://civicrm.stackexchange.com/a/14310/149">Some links here</a>, but don't think there's a JIRA issue on it?)</p>
  
  <p>So: Perhaps in the few places where CiviCRM doesn't have Drupal bootstrapped, eg <em>new user create during PayPal IPN on successful event rego</em>? (I made up this case as a potential place CiviCRM might need it, and not be able to deduce from bootstrapped CMS.)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-16T02:21:15.203Z
Answers.LastActivityDate: 2016-08-16T02:21:15.203Z
Answers.LastEditDate: 2017-04-13T12:53:13.017Z
Answers.UserDisplayName: Chris Burgess
Body: <p>I've got a CiviCRM 4.7.9 install running in a Drupal multisite. I have a ton of databases, named something like this:</p>
  
  <ul>
  <li>CiviCRM: org_dev_crm</li>
  <li>Drupal default site: org_dev_cms</li>
  <li>Drupal site 2: org_dev_cms_other</li>
  <li>Drupal database for tables shared across sites: org_dev_cms_shared</li>
  </ul>
  
  <p>The users table is shared across instances in the last database, and Drupal settings.php file contains the following line:</p>
  
  <pre><code>$databases['default']['default']['prefix']['users'] = '`org_dev_cms_shared`.';
  </code></pre>
  
  <p>Since the <code>users</code> table is in an unusual place, I thought I'd have to tell CiviCRM about it by going to <em>Administer > System Settings > CMS Database Integration</em>. On a lark, however, I decided to test if this was necessary. I ran the user-to-contact sync (<em>Administer > Users and Permissions > Synchronize Users to Contacts</em>), and it worked just fine. If there ever was a way to test CiviCRM's ability to access Drupal's user table, I figured this was it.</p>
  
  <p>So, to wrap this up:</p>
  
  <ul>
  <li>What is this setting used for, if not synching?</li>
  <li>Do we still need this setting, or has CiviCRM learned how to read Drupal config?</li>
  </ul>
  
Tags: <drupal>
Title: Do we still need "Drupal Users Table Name" setting on CMS Database Integration screen?
ThreadText: # Do we still need "Drupal Users Table Name" setting on CMS Database Integration screen?
  
  (Asked by: username_0 on 2016-08-16)
  
  I've got a CiviCRM 4.7.9 install running in a Drupal multisite. I have a ton of databases, named something like this:
  
  * CiviCRM: org\_dev\_crm
  * Drupal default site: org\_dev\_cms
  * Drupal site 2: org\_dev\_cms\_other
  * Drupal database for tables shared across sites: org\_dev\_cms\_shared
  
  The users table is shared across instances in the last database, and Drupal settings.php file contains the following line:
  
  ```
  $databases['default']['default']['prefix']['users'] = '`org_dev_cms_shared`.';
  
  ```
  
  Since the `users` table is in an unusual place, I thought I'd have to tell CiviCRM about it by going to *Administer > System Settings > CMS Database Integration*. On a lark, however, I decided to test if this was necessary. I ran the user-to-contact sync (*Administer > Users and Permissions > Synchronize Users to Contacts*), and it worked just fine. If there ever was a way to test CiviCRM's ability to access Drupal's user table, I figured this was it.
  
  So, to wrap this up:
  
  * What is this setting used for, if not synching?
  * Do we still need this setting, or has CiviCRM learned how to read Drupal config?
  
  **Tags:** drupal
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2016-08-16. Score: 3 | Accepted answer
  
  **Context**: When reading data from the CMS, one can either read directly from their database (via `DB::connect()` and `SELECT * FROM user ...`) or you can use the CMS's PHP APIs (e.g. `user_load(...)`). In one sense, reading from SQL directly is more robust (no dependency on complicated PHP code); in another sense, reading from a PHP API is more robust (because it handles all the weird edge-cases of jerry-rigged SQL schema that Drupal allows).
  
  **Speculation**: My strong *suspicion* is that early versions of Civi (like 1.x or 2.x) relied heavily on SQL-based integration. (Witness: the installation process and `civicrm.settings.php` prominently solicit `CIVICRM_UF_DSN`), but this doesn't work well in jerry-rigged SQL schema, and it's unpleasant for Civi to be coupled to the CMS SQL, so... it was gradually killed as people fixed bugs.
  
  **Current Reality**: I can only find one function that hits the CMS user table directly via SQL -- `CRM_Utils_System_*::authenticate()`. The details of this are a bit weird and vary by CMS:
  
  * In Joomla, WordPress, and D8, `authenticate()` uses the CMS's PHP APIs. They don't hit SQL directly.
  * In D6, `authenticate()` always queries via `DB::connect()` and SQL.
  * In D7 and Backdrop, `authenticate()` sometimes queries via `DB::connect()` and SQL. The way it's written... it's hard to tell if it's ever used. From some grepping... if it is used... it's probably the CiviMail-SOAP adapter (`extern/soap.php` and `CRM/Utils/SoapServer.php`).
  
  However, I don't believe this is a hard requirement -- considering that Joomla/WordPress/D8 don't use it. You could probably figure a patch to `CRM_Utils_System_*::authenticate()` and `CRM/Utils/SoapServer.php` which allows us to completely remove `CIVICRM_UF_DSN` and `userFrameworkUsersTableName`. The main cost would be re-testing the SOAP return-channel in each CMS.
  
  > **Comments:**
  > **username_2**: There are 2 PRs open for review on this function in SOAP so I suspect it does not currently work right ... https://github.com/civicrm/civicrm-core/pull/8787  
  > **username_1**: Yeah, I share the general sentiment of "there-be-dragons" in this area. The PR seems to imply that `WordPress::authenticate()` works as long as you bootstrap the CMS. The overwrought bit (tying into username_3's note) is it's a bit of mess understanding which use-cases will boot the CMS. My feeling is that basically everything except `extern/open.php` and maybe `extern/url.php` should enable CMS boootstrap. (Note, though, that this is similar-but-different to making the CMS the sole entry-point.)  
  > **username_0**: Thanks for both helpful answers. I marked Tim's as accepted because it had a little more detail.  
  
  ---
  
  ### Answer by username_3 on 2016-08-16. Score: 4
  
  There are scripts in `extern/*.php` (like `extern/ipn.php`) which fire up CiviCRM without the CMS bootstrapped. I believe the plan is to replace them with callbacks (like `civicrm/payment/ipn/%id`) which eliminate instances where CiviCRM is bootstrapped without the CMS. ([Some links here](https://civicrm.stackexchange.com/a/14310/149), but don't think there's a JIRA issue on it?)
  
  So: Perhaps in the few places where CiviCRM doesn't have Drupal bootstrapped, eg *new user create during PayPal IPN on successful event rego*? (I made up this case as a potential place CiviCRM might need it, and not be able to deduce from bootstrapped CMS.)
  
  
  ---
  
  