I think we all agree that the "Hosting Features" subsystem is... not ideal.

What if we leverage drupal's module system properly? What if we use the amazing Module Filter module?

I have an idea, which I've implemented on a new branch.

  • Include module_filter module in hostmaster.
  • Load in the system modules form at admin/hosting.
  • Form Alter the system modules form at admin/hosting by removing all non-hosting modules. (for now I'm using hosting_get_features()) to determine what modules are "hosting" modules. )
  • Use module "package" to instead of hosting_features "group" to keep things together.

Thoughts?

CommentFileSizeAuthor
#1 Screenshot from 2014-10-19 12:45:59.png122.89 KBJon Pugh
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jon Pugh’s picture

Jon Pugh
he/him
Primary language English
Location Newburgh, NY
CreditAttribution: Jon Pugh commented
Status: Active » Needs review
FileSize
Screenshot from 2014-10-19 12:45:59.png122.89 KB

Uploading a screenshot. It's a start.

We should remove sidebar blocks in admin pages, too.

  • Jon Pugh committed a7b923e on dev-2359571 
    Issue #2359571: Remove "Hosting Features" in favor of drupal core module...
helmo’s picture

helmo CreditAttribution: helmo commented

Great, works in my quick test.

  1. We should add module_filter to hostmaster.make (slight risk of merge conflict with: #2358413: Cleanup makefile)
  2. Having everything under 'Hosting' is not that usefull. Can we create a nesting? Or just by prefixing 'Aegir' in the package name... like a group 'Aegir - Git' and 'Aegir - Webservers'
  3. After submitting we are redirected to /admin/modules ...
omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

I don't like this idea. It is confusing. Previously it was easy to see Hostmaster specific features/modules with extra section for experimental features. Just like Features are separated from Modules, because they are functionally Features (bundles) and not just Modules. Now it will be a standard Drupal mess. Please don't do this.

Jon Pugh’s picture

Jon Pugh
he/him
Primary language English
Location Newburgh, NY
CreditAttribution: Jon Pugh commented

Re: helmo:

  1. Would add to hostmaster.make for sure.
  2. I simply didn't get to this. That was definitely where i was going. I think I agree on changing package to Aegir. The word "Hosting" is a bit to generic to be instantly recognizable.
  3. There's a few more form_alter fixes to make like this, for sure.

Re: omega8cc: I think we can address those concerns. I already planned on updating "Package" to reflect the hosting feature "group" parameter.

What would you say is confusing about it, other than the lack of separation of "experimental" modules?

We can do more here to make this less confusing, for sure. Perhaps removing the requirements would reduce clutter?

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

As long as we don't lose functionality, I'd support this. It's a lot of code we shouldn't really need to maintain. I believe that we can add arbitrary data into a module's .info, no? in that case, maybe we can put the Hosting Features meta-data there.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

I vote no if it will make the current elegant listing ugly - which is typical for Drupal own module listing.

If it will look at least similarly to what we have now, then OK. Not sure if related code we need to "maintain" currently really needs any maintenance?

But if it will replace the current minimal and elegant listing of Aegir specific features with cluttered visually Drupal chaos in the module listing, then what is the purpose/reasoning behind this change, if I can see basically the same in the Drupal own module listing with some filtering there?

Please don't make it ugly w/o any other good reason than a temptation to remove some code we need to "maintain".

helmo’s picture

helmo CreditAttribution: helmo commented
Status: Needs review » Needs work

More work to be done ... after enabling a module via this patch other modules like admin_menu become disabled.

To make a better case for code we can remove it would be nice to remove it with the patch.

helmo’s picture

helmo CreditAttribution: helmo at Initfour websolutions commented

I've included the module_filter module in hostmaster as a tiny step forward.

  • Jon Pugh committed a7b923e on 2359571-rm-hosting-features 
    Issue #2359571: Remove "Hosting Features" in favor of drupal core module...
colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Consensus Enterprises, Colan Schwartz Consulting commented

Just finding this now...

#7: To maintain the Experimental/Advanced/etc. functionality, why don't we just make those the package names in Drupal core's system?

  • Aegir (Core)
  • Aegir (Advanced)
  • Aegir (Experimental)

To go a bit further (probably too much): We could just use core only, and remove all of the Hosting Features stuff entirely (and then of course change all of the module package names to those listed above).