MODULE MANAGER (MM) Proposal
In the context of designing the new SilverStripe 3.0 I would like to kick of a discussion about a Module Manger and share some thoughts about how I would picture it.
If you want to comment on this proposal please use this google groups thread
- Tool for installing, configuring and updating (and uninstalling?) of SilverStripe modules automatically
- Tool inspecting the currently installed modules (read metadata (see below), detect code changes)
- Tool for browsing the module catalogue
- Command Line Tool and CMS interface for the above tasks
- Alert security patches
- Rollback in case of an error during operation
- Require as little changes to the current module implementation as possible
- sake modules install cms
- sake modules search mollom
- sake modules status sapphire
For the module manager to work it I picture it:
- to be aware of the installed modules,
- to have the ability to inspect the modules and determine information required for updating them and
- to be able to retrieve a module index containing metadata about all published modules registered in a central module catalogue.
- specific versions of modules can be identified by their checksums
- ideally modules support a two step approach where step 1 is installation and step 2 is activation of the module (if a module has only been installed is does not take affect, only activated modules do)
silverstripe.org is currently holding some of the data required and could be extended to host the module catalogue
- Entries in the catalogue could be auto generated using the metadata, INSTALL and README files retrieved from the modules repository for easy automatic adding and updating the catalogue.
- The catalogue could be extended by metadata for user ratings, user comments, download counter (for the current version and all versions) and the date of the last update (important, missing in the listing, it shows up on the details page)
- In the catalogue the modules/widgets/themes structure could be replaced by a nested category structure to give more flexibility
The generic module importer class that would:
- curl-downloads a zipped module
- verifies the file by its checksum
- unpacks the archive to the appropriate path
- dialog for module activation and configuration
- executes onAfterInstall callback e.g. to add or amend config commands in the mysite/_config.php file if necessary
- onAfterInstall callback then extends to the modules onAfterInstall if it exists
- runs build task and flushes cache
Insufficient file permissions may turn out to be a serious problem for the MM's CMS panel because it operates with the web servers privileges.
Version Control Systems
The module installer base class implements a couple of methods that will be overloaded in the extensions for SVN and git.
Can be stored within the module in a metadata.yml or xml or ini because these formats can easily be parsed.
- Official name of the module
- Path segment to install the module in the approot
- Version Control System (SVN/git/none)
- Requirements info (required Sapphire version, supported os / dbms)
- Repository URL
- Checksum for identifying model+version and validating the downloaded code
- Last updated
Thanks to Hamish and JF for some good ideas
Author: andreas (at) silverstripe (dot) com