Turn hosting features into features features.

Do you mean the real 0.3? or 0.4? If the former, this should be a critical issue (and i'm not sure that's a good way to go since it's a bit of refactoring/new feature that could break more stuff, and we're at the RC stage).

I just merged in the stuff that had been done on the dev-features branch and quite like some of the ideas that where being played with in that code, wonder what happened to this? Were there any technical reason for it not proceeding any further? Do you still think its worth working on?

Ok, not sure if this should be under a different issue but it is related to moving to a features architecture for aegir.

I recently put some time into attempting to moving all the code from the hostmaster.profile into a feature module and out of the install profile. As one of the things I noticed recently is a change like the primary menu now including the items for site/platforms/servers did not automatically happen in an upgrade (which is probably good as you may have a custom setup with different menus. But putting these settings into a feature its easier to keep in sync with whats changing on upgrades (at least you can see whats different in your site when you upgrade from the default install).

I got it to a point where hostmaster would install and basically set everything up correctly for a aegir frontend with no code in the hostmaster profile and everything instead was able to reside in a hosting_ui feature module. The only part I haven't got working is setting up the nodes for the first client and server - but that shouldn't be too difficult to get working.

This change would basically means that install_profile_api dependency can be removed, although instead it would add a dependencies on profiler, features, features_extra

I did have most of this working back when I posted the above, but just haven't had the time to complete and test it - I'm reasonably confident that it works and should allow the system to be installed and work exactly the same, but it probably needs some testing against features I'm not using like nginx

Basically the attached patch removed the dependency on install_profile_api and instead uses profiler (which hopefully should help in D7 upgrade). All the main setup is moved to a hosting_ui feature module, this sets up things like the menus, user roles and permissions.

There are three other dependencies added in this patch:
* features
* context
* ctools

There are becoming fairly standard modules for building distributions, so these three modules should be useful in a number of other places and they are all available in D7.

This patch is against 7.x-2.x (i assume this is probably a bit too disruptive for the now stable 6.x-1.x branch), but I can also provide a patch against 6.x-1.x as did first get it working in that branch.

I'm not sure if an update function should be provided to enable the hosting_ui feature, as that could revert site specific changes (e.g. menu, roles, permissions)

Use this patch instead (previous one included stuff that shouldn't have been in there).

There are unrelated changes in this patch, the old stuff to cleanup the bulk operations forms (which still need to be cleaned up, btw):

@@ -485,10 +485,25 @@ function hosting_site_list_form($form_state, $filter_by = NULL, $filter_value =

Out of curiosity - why is the hosting_ui module separate? Is this because of features.module requirements?

Sorry, removed those bits.

It is possible to merge hosting_ui into an existing module and the core hosting.module probably makes the most sense for this. It would have a nice side effect of being able to see exactly where your site has changed from the default install without any complicated update functions.

The only problem I noticed is that hosting already has a hosting.features.inc file which is a standard features file, so that would need to be renamed or that code merged into the hosting.module file so features could use that file.

The only thing that concerns me is how well features would handle all the other files and sub-modules in hosting, my experience is that it should be ok but I haven't dealt with features module with this much other stuff in it before.

The whole idea is to drop our own idea of features.inc, so yes, merging this in hosting.features.inc is exactly the objective here...

Maybe this patch would work well as a first pass, in a feature branch of 2.x, then a second pass would refactor our existing "features" to make them "features features"...

The whole point in using features is ability to move our built-in "features" out of core, to make them pluggable etc, so it shouldn't go back in the core.

[EDIT] doh, just read #11 :)

The one advantage I would put forward for creating a separate module for the front end type stuff (menu items, roles, permissions, blocks) is that then you can swap out the feature for your own custom feature to manage all this stuff.

Looks like a good change overall, and a good preparation for Drupal 7. In Drupal 7, profiler shouldn't be required, since install profiles are treated as modules by default.

For an example of writing a profile that is itself a feature in Drupal 7, see Open Outreach.

+++ b/hostmaster.info
@@ -0,0 +1,28 @@
+variables[install_profile] = hostmaster

Why does this variable need to be in features? Isn't it set by Drupal on install?

+++ b/hostmaster.info
@@ -0,0 +1,28 @@
+variables[site_name] = Aegir - Drupal Hosting
+variables[site_mail] = testing@testing
+
+variables[site_footer] = Aegir - Drupal Hosting

Since the individual site is likely to want to customize these variables, it might be better to set them manually via variable_set() rather than in Strongarm, to avoid the feature being overridden.

All those variables are set through profilers install process and have nothing to do with strongarm or features. They just set some defaults and are mostly there as an example for other variables which should be can set as default, happy to update the patch with more suitable default values.

There are a few reasons why profiler could still be useful in D7. Apart of enabling modules which is now possible in D7 install profile info files. It also allows you to setup themes, variables, taxonomy terms.

One of the more interesting features is that it allows you to create sub-profiles that extend a base profile. So in aegir there can be a base install profile and everyone can extend that through their own profiles.

I suspect that this will happen as part of the D7/8 frontend upgrade, but probably can wait I think until we know exactly what the architecture should be really. I reckon we will end up using Features to some extent, because they are quite good for capturing fields configuration.

Thanks for the time you've all spent on this issue, but I'm going to mark it as won't fix, but we can re-open or start new issues once we know what the frontend architecture of the next frontend version looks like.

(I could mark this postponed, but this is such a large issue that I think it'll stall, and isn't actually worth keeping visibly around tbh, sorry!)