Needs work
Project:
Hosting
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
19 Oct 2014 at 16:44 UTC
Updated:
10 Oct 2019 at 15:15 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
jon pughUploading a screenshot. It's a start.
We should remove sidebar blocks in admin pages, too.
Comment #3
helmo commentedGreat, works in my quick test.
Comment #4
omega8cc commentedI 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.
Comment #5
jon pughRe: helmo:
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?
Comment #6
ergonlogicAs 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.
Comment #7
omega8cc commentedI 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".
Comment #8
helmo commentedMore 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.
Comment #9
helmo commentedI've included the module_filter module in hostmaster as a tiny step forward.
Comment #11
colanJust 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?
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).