Proposal: CiviCRM Installer

Civi_Install_InstallerInterface.php

<?php
namespace Civi\Install;

interface InstallerInterface {
  /**
   * @param array $options, e.g.
   *  - source: string, path to CiviCRM source tree
   *  - settings: string, path to civicrm.settings.php
   *  - civi_dsn: string
   *  - uf_dsn: string
   *  - uf: string
   *  - templatesc_dir: string
   *  - locale: string
   * *  ...(expect about a dozen options)...
   */
  function setOptions($options);
  
  /**
   * @return array (string $reqId => RequirementInterface)
   */
  function getRequirements();
  
  /**
   * Create any DB tables or config files
   */
  function install();
  
  /**
   * Remove any DB tables or config files
   */
  function uninstall();
}

Civi_Install_RequirementInterface.php

<?php
namespace Civi\Install;

interface RequirementInterface {
  /**
   * @return string
   */
  function getDescription();
  
  /**
   * @return array (is_error => bool, error_message => string)
   */
  function validate();
}

comments.md

Major things to note:

• The installer is abstracted so that it can be plugged into different systems (e.g. Drupal web UI, Joomla web UI, Drupal profiles, drush, wp-cli, provision_civicrm, composer).
  • For example: the list of requirements/pre-requisites can be presented in different ways.
• The core installer has zero intelligence about CMSs. It has no opinions or biases on CMS-specific issues/policies. If something is CMS-specific (like the default path to templates_c), then the caller must pass in those details.
  • The CMS-specific install logic belongs in the CMS-integration module (e.g. civicrm-drupal uses hook-install or hook-menu and calls InstallerInterface at a suitable moment)
• There are a lot of details in the code above which are provided for sake of completeness but may not be the right/final decision (e.g. representing install-requirements with an interface while representing $options with a simple array). This gist is focused on demonstrating the bullet-points above.
• For the web-based installers (D6/D7/WP), the current installer throws up a screen where the admin configures an extra DSN. For D8/J/provision_civicrm, the current installer skips the extra screen and reuses the CMS DB. I suspect there were good reasons for split-DB in 2005, but today it seem like a bad default -- we should default to automatic, single-DB installation everywhere -- but allow some advanced way to install split-DB (e.g. manually pre-create civicrm.settings.php or call the installer via CLI).