civicrm-setup library aims to replace the CiviCRM installer. Following the December/January iteration, it's available for use as a CLI installer and as a web-based WordPress installer.
install/civicrm.php) with no particular ordering. Conditionals are sprinkled randomly in a way which makes it hard to follow the big picture.
civicrm/install/index.phpweb-based installer; e.g.
civicrm_install; e.g. Joomla web-based installer). The installer should have a common library so that one change to the installer can go-live on all channels.
civicrm.settings.phpon your own, and you have to figure out the right mix of
*.mysqlfiles. Originally, the workflow had the upside of producing a singular
*.mysqlfile that you could use to quickly initialize a new installation. However, over time, several requirements were mixed-in, such as translating DB content and seeding the DB with example data -- leading to an (overall) obscure workflow for building+distributing the SQL files. The architecture could be simpler and more robust, but it would require moving a few tasks from external scripts to the installer.
civicrm.settings.phpis occasionally a point of friction in sophisticated hosting environments. Making this file optional could improve portability/maintainability.
Of course, it's easy to write a wishlist with a bunch of nitpicks. But if you start making big changes to an existing piece of code, that creates risks -- risks of causing regressions, risks of breaking existing workflows, etc. And if you try to fix everything on the list, then your schedule may drag on forever (without shipping anything!).
To manage these risks, one might follow the Leap by Extension philosophy. In particular:
civicrm-setuplibrary is optional -- if it's specifically enabled, use it; otherwise, fallback to the existing code. This may require some narrowly-tailored patches.
During December/January, we set out to create a new zip/build with a revised installation screen suitable for publishing on the
wordpress.org plugin directory. Some of the installer issues -- such as the general entropy of the code and the design of the UI -- were clearly on our path. So we bit the bullet and started the installer leap. This produced a few concrete deliverables:
civicrm.orginfrastructure provides a new build,
civicrm-X.Y.Z-wporg.zip, which incorporates
civicrm-setupand a new installation screen. This screen presents a different mix of options, chosen to meet policy/design guidelines for the
wordpress.orgplugin directory. (The new build is currently available as a
NIGHTLYautobuild for v4.7.31+ on https://download.civicrm.org/latest; for an official release, it should appear in March.)
civicrm-setupto implement subcommands
cv core:uninstall, and
cv core:check-req. The subcommands have automated test-coverage for CLI installation on single-site deployments of Backdrop, Drupal 7, and WordPress.
Of course, we're not trying to solve every possible issue with installation -- for example, the Drupal 7 installer hasn't changed. But we've made progress. How does this iteration stack-up against our original list of issues?
civicrm-setuplibrary is better organized and better documented.
$e->getModel()->extensions = 'org.example.myext'.
civicrm-setupis a library/API which is amenable to use in many channels/installers. However, we should eventually update more installers to use
civicrm-X.Y.Z-wporg.zip), or they can build new UI's with the installer API (as in
cv, which implements a command-line interface).
cvcommand supports automated installation, uninstallation, and requirements-checking. The PHP API is available for other forms of automation.
cv core:installrequires a CMS-first bootstrap script, and it now has a first-draft implementation. As discussed in cloud-native #7, the CMS-first bootstrap script is an important component which will help remove
civicrm.settings.php. However, that's a bigger project -- for now, the installer must still generate
We don't currently have any budget or manpower allocated for future iterations -- the Dec/Jan iteration has already covered more ground than we needed to meet our original goal. However, there are several topics that are ripe for progress -- contributions of code or funding would enable them to move forward. For example: