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?

2 Answers 2


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.

  • There are 2 PRs open for review on this function in SOAP so I suspect it does not currently work right ... github.com/civicrm/civicrm-core/pull/8787
    – eileen
    Aug 16, 2016 at 8:43
  • 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.)
    – Tim Otten
    Aug 16, 2016 at 9:56
  • Thanks for both helpful answers. I marked Tim's as accepted because it had a little more detail. Aug 20, 2016 at 14:05

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, 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.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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