Aegir is designed to be platform-neutral: it can run on multiple operating systems, supports multiple web servers, etc. The key thing missing right now is supporting other CMSes.

This ticket is about implementing just that. There's a chat log in our documentation that details how this could be done. Although it's now outdated (since the new alias/multiserver stuff), it can still serve as a good basis to implement third-party platforms extensions.

To quote that chat log, which refers to allowing Aegir to provision SPIP sites:

<@anarcat> 0. test multispip in order to see how it works and successfully install a site by hand, without the web installer, just create the files and load the SQL dumps
<@anarcat> 1. code the PHP funcitons which do it, very simply, but with some arguments
<@anarcat> 2. integrate that in a Drush module, to understand how Drush works
<@anarcat> after that, we'll start speaking with aegir
<@anarcat> 3. do a code cleanup of the platform verifucation (provision-verify) in order to detect the platforms, around the engines
<@anarcat> 4. Call the right functions when a task is called, simply via the engine system
<@anarcat> 5. correct the drush module to implement the engine commands
<@anarcat> after that, do the frontend
<@anarcat> 6. add the fields in the database for the platform type
<@anarcat> 7. add the fields in the interface for choosing the platform type.. etc

So in short, we need the following modifications in aegir:

1. abstract Drupal away from the platform concept, probably by making platforms a class and Drupal a subclass
2. modify the frontend similarly - to add a "type" or "engine" field to platforms

Note that one of the challenges will be to adapt to non-multisite CMSes: maybe we don't even want to do that to start with. But in general, we should consider the idea that platforms and sites are merged, or at least that there's only one site per platform on some engines.

Once Aegir is ready to accept third-party CMSes, a sample one can be implemented, using the following steps:

1. design a makefile to deploy the code
2. implement provision-verify to setup the platform in the backend and frontend
3. implement provision-install to actually install the site
4. implement provision-backup to backup the site
5. implement provision-deploy to deploy the site to a new platform (which also covers restore, migrate, clone... etc)
6. implement provision-delete to delete the site (duh)

Note that Drush make can already be used to deploy the actual code of third-party CMSes, see #969076: non-drupal support: allow for downloading modules from other locations to other locations for that fascinating discussion.

Comments

Steven Jones’s picture

Version: 6.x-0.4-alpha3 » 6.x-2.x-dev
anarcat’s picture

The chatlog is now here.

Steven Jones’s picture

Status: Active » Postponed
ergonlogic’s picture

Version: 6.x-2.x-dev » 7.x-3.x-dev
ergonlogic’s picture

Issue summary: View changes

fix chatlog path