Uploaded image for project: 'CiviCRM'
  1. CiviCRM
  2. CRM-1291

Move CiviCRM Configuration Settings into DB and Provide Admin Interface


    • Type: New Feature
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Fixed/Completed
    • Affects Version/s: None
    • Fix Version/s: 1.6
    • Component/s: CiviMail
    • Labels:


      This functionality is designed to make it easier to configure CiviCRM by moving most of the configuration settings from civicrm.settings.php into the DB, and providing an adminstrative UI for viewing and updating the values.

      For the first implementation, we will keep security-sensitive settings (passwords and DSNs) in the settings file.... along with a few settings that are needed to actually load the module/component.

      All other settings will be stored as a serialized configuration object. We will extend the existing civicrm_domain table with "text" columns to hold the serialized data (as each domain has it's own configuration settings in a multi-site/multi-domain installs). In order to support Joomla's backend vs. frontend settings, each domain table row will have a backend and a frontend configuration property.

      The configuration object properties will "organized" into sections for the purpose of UI display/editing. For the first implementation, all sections will be accessed from a single large form with separate collapsible fieldsets. However, we will upgrade this to use Ajax to retrieve sections on demand - so each section should be implemented as a separate php form file and template.

      Keep These Variable in the Settings File
      These settings need to stay in settings FILE so the module can load:
      $civicrm_root = '';
      define( 'CIVICRM_TEMPLATE_COMPILEDIR', '' );
      define( 'CIVICRM_UF_BASEURL' , '' );

      define( 'CIVICRM_UF' , 'Drupal');
      define( 'CIVICRM_UF_VERSION' , '4.7' );
      define( 'CIVICRM_UF_URLVAR' , 'q' );
      define( 'CIVICRM_UF_USERSTABLENAME', 'users' );

      define( 'CIVICRM_UF_DSN' , 'mysql://DBUSER:PASSWORD@HOSTNAME/DATABASE?new_link=true' );
      define( 'CIVICRM_DSN' , 'mysql://DBUSER:PASSWORD@HOSTNAME/DATABASE?new_link=true' );

      define('CIVICRM_DOMAIN_ID' , 1 );

      In addition, all passwords will remain in the settings file for now (security issue). We'll look for a better solution after we get the basics in place:
      define( 'CIVICRM_SMTP_PASSWORD', 'smtp_password' );
      define( 'CIVICRM_CONTRIBUTE_PAYMENT_KEY' , '' );

      Schema Changes
      Add columns to civicrm_domain:

      • config_backend TEXT
      • config_frontend TEXT

      Configuration Object
      The configuration object will be a serialized representation with name/value pairs. We should be able to maintain the variable names currently used. It may be useful to add a "section" layer to the object which models the UI presentation ??

      Settings Initialization (defaults)
      We'll need to set meaningful defaults for many of the config variables. We should discuss how/where this happens. Some settings can just have hard-coded defaults - for example:

      define( 'CIVICRM_MYSQL_VERSION', 4.0 );

      These can possibly be handled in civicrm_data.mysql (and the 1.6 upgrade).

      Other settings should be derived from the "environment" / from the base settings in the settings file at install AND / OR through the Joomla installation process. For example:
      define( 'CIVICRM_UF_RESOURCEURL' , '' );
      define( 'CIVICRM_IMAGE_UPLOADURL' , '' );

      Loading the Config Values
      This should simply be a matter of modifying Core/Config.php to retrieve and deserialize the DB-stored settings and append to the "base" settings still derived from civicrm.settings.php

      Administrative UI - Editing Settings
      Add "Global Settings" icon/link to Setup group in Administer CiviCRM.
      This links to a new form with several sections (collapsible fieldsets). The page should initially load with all sections collapsed (check out Drupal >> admin >> settings for a similar example). There is one set of buttons at bottom (Save / Cancel ).

      Implement each section as a separate <form>.php and <form>.tpl file - so we can easily move this to an Ajax - load form section on demand - implementation.

      Sections and the settings (fields) for each are:

      • Components
        define( 'ENABLE_COMPONENTS', 'CiviMail, CiviMember' );
      • File System Paths
        define( 'CIVICRM_UPLOADDIR' , '' );
        define( 'CIVICRM_IMAGE_UPLOADDIR' , '');
        define( 'CIVICRM_CUSTOM_FILE_UPLOADDIR' , '' );
      • Site URLs
        define( 'CIVICRM_UF_RESOURCEURL' , '' );
        define( 'CIVICRM_IMAGE_UPLOADURL' , '' );
        define( 'CIVICRM_CUSTOM_FILE_UPLOADURL','' ); ?? is this still used ??
      • SMTP Server
        define( 'CIVICRM_SMTP_SERVER' , '' );
        define( 'CIVICRM_SMTP_PORT' , 25 );
        define( 'CIVICRM_SMTP_AUTH' , false );
        define( 'CIVICRM_SMTP_USERNAME', '' );
      • Mapping and Geocoding
        define('CIVICRM_MAP_PROVIDER' , '' );
        define('CIVICRM_MAP_API_KEY' , '' );
        define('CIVICRM_MAP_GEOCODING' , 1 );
        define('CIVICRM_GEOCODE_METHOD', '' );
      • Online Payments
        define('CIVICRM_ENABLE_SSL', 0 );
        define( 'CIVICRM_CONTRIBUTE_PAYMENT_EXPRESS_BUTTON', 'https://www.paypal.com/en_US/i/btn/btn_xpressCheckout.gif');
        define( 'CIVICRM_CONTRIBUTE_PAYMENT_PAYPAL_EXPRESS_TEST_URL', 'www.sandbox.paypal.com');
        define( 'CIVICRM_CONTRIBUTE_PAYMENT_PAYPAL_EXPRESS_URL', 'www.paypal.com');
      • Localisation
        define( 'CIVICRM_LC_MESSAGES' , 'en_US' );
        define( 'CIVICRM_MONEYFORMAT', '%c %a' );
        define( 'CIVICRM_LC_MONETARY', 'en_US' );
        define( 'CIVICRM_COUNTRY_LIMIT' , 'US' );
        define( 'CIVICRM_PROVINCE_LIMIT' , 'US' );
        define( 'CIVICRM_LEGACY_ENCODING', 'Windows-1252' );
      • Address Formatting
        define( 'CIVICRM_ADDRESS_FORMAT' , ' {street_address} {supplemental_address_1} {supplemental_address_2} {city} {, } {state_province}

        { }

        {postal_code} {country}

        ' );
        define( 'CIVICRM_MAX_LOCATION_BLOCKS', 2 );

      • Date Formatting
        define( 'CIVICRM_DATEFORMAT_DATETIME', '%B %E%f, %Y %l:%M %P' );
        define( 'CIVICRM_DATEFORMAT_FULL', '%B %E%f, %Y' );
        define( 'CIVICRM_DATEFORMAT_PARTIAL', '%B %Y' );
        define( 'CIVICRM_DATEFORMAT_YEAR', '%Y' );
        define( 'CIVICRM_DATEFORMAT_QF_DATE', '%b %d %Y' );
        define( 'CIVICRM_DATEFORMAT_QF_DATETIME', '%b %d %Y, %I : %M %P' );
      • Miscellaneous
        define('CIVICRM_VERSION_CHECK', true);
        define( 'CIVICRM_CAPTCHA_FONT_PATH', '/usr/X11R6/lib/X11/fonts/' );
        define( 'CIVICRM_CAPTCHA_FONT' , 'HelveticaBold.ttf' );
      • Error Handling and Debugging
        define( 'CIVICRM_DEBUG', 0 );
        define( 'CIVICRM_BACKTRACE', 0 );
        define( 'CIVICRM_FATAL_ERROR_TEMPLATE', 'CRM/error.tpl' );
        define( 'CIVICRM_FATAL_ERROR_HANDLER', '');

      HTML Input Elements for Editing Config Variables

      • Address_format is a textarea.
      • Boolean values should use a radio button element (e.g. CIVICRM_VERSION_CHECK)
      • All values which have a known set of options should be presented as SELECT elements IF only one option can be selected. Examples include:
        CIVICRM_LC_MESSAGES (limited to l10n's sub-dirs)
      • Values which allow multiple selections should use the 2-box selector control (same as the "Include Groups in Mailing" element in CiviMail). Examples include:
      • All other values are presented as TEXT fields (input type="text")




            • Assignee:
              rupam Rupam Jaiswal
              dgg David Greenberg
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: