[meta] More flexibility for core installation profiles

I'd add #820054: Add support for recommends[] and fix install profile dependency special casing - currently a profile can't specify hard dependencies on modules (and the inconsistency with module dependencies is the cause of several bug reports elsewhere).

fixing mis-aligned issues

Adding a link to #820054

Adding #1242956

karschp posted this in another issue:

However, once I install the Open Atrium distro I cannot then install Open Public on top of it and merge their features. Or, more simply, once I install the single_user_blog profile, I can't then borrow stuff from the community_forum profile.

This is one of the fundamental things we need to look at with install profiles. It's related to #1170362: Install profile is disabled for lots of different reasons and core doesn't allow for that.

Install profiles are currently fulfulling (at least) the following:

1. Just enabling a couple of modules so you can get to /admin/modules to enable some more (minimal)
2. A 'quick start' of a few enabled modules and some default configuration (standard)
3. A 'distribution' for a specific use case, tailored to building sites for that use case (say commerce)
4. A distribution for a specific use case, designed to be immediately usable for that use case (or you could customize if you wanted to), Open Atrium

.

I would like us to get to a technical point where you can install Drupal without actually running the installer - we have low level APIs that can get the configuration system up and running, install their db schema if they need to just from settings.php, then you can do that and run drush en -y to start enabling modules without drush site-install or install.php. If we ever get there, then there would be a level 0 below minimal profile which does nothing - but which you'd never normally see because you can still go to install.php and choose some defaults.

For standard profile, or distributions which bundles lots of modules together, but don't necessarily set up all the configuration for a usable site, these can be run-once things. You install the profile, then you forget it's there and enable/disable modules from that. It's largely a marketing tool, and a way to get a single tar.gz from Drupal.org

For the last one, you might actually want tight integration, and the ability to update at the level of the entire profile configuration not just individual modules.

There is also an aspect of this which is bundling modules + configuration together - this is what 'features' (as in features module) are supposed to be - and definitely it seems like people should be able to mix and match those together. Image gallery, forum, multi-user blog - these can be site sections, or entire sites.

All of this, means that I think we need to try to decouple the idea of features - the sets of modules and configuration. From distributions - the packaging of sets of modules and configuration along with Drupal core. You don't actually need features modules to make a 'feature', you can just make a module, specify dependencies and ship some default configuration - especially once CMI is in place.

I don't know if it's still like it, but in 2000 when I first install linux ever, the Red Hat desktop distribution had an installer that let you choose particular sets of packages to install - say office, graphics, games etc.

mikey_p pointed me to http://drupal.org/project/packgr yesterday, which actually implements some of this. Combined with http://drupal.org/project/project_browser we could do a lot there.

In my mind, this would ideally look like Buzzr or Gardens, where upon install, you get the menu of "features" (not the module) to enable: blog, wiki, photo gallery, etc. I know that is way easier said than done, but if we're looking to greatly enhance the "first four-hour" experience as @eaton termed it, this would be a massive step forward.

After thinking about this a little more, and forgive me for re-stating the obvious, but perhaps on the d.o/download page we have "Drupal Core" and "Drupal Starter" (onramp), where "Starter" is a profile that contains all the functionality that's been jettisoned from "Core" such as blog, forum, profile, etc.

However, Starter would not contain blog.module per se, but config + Views (a feature or recipe) for creating blog functionality. In other words, Starter would also include contrib modules.

Which, of course, begs the question, "Who's going to maintain Starter?" to which I don't really have an answer.

But it seems that removing blog.module from core and having Dave Reid (or some other prominent contributor) maintain it in contrib doesn't really solve the problem of "Core contributors need to focus on core."

There are some sites that have one specific set of functions that can match up well with an install profile/distribution. When that is the case, distributions can serve as a nice on-ramp for site builders.

However, there are plenty of other sites that need several disparate sets of functions. I run a site for a membership organization that has a conference each year. Some things from Open Atrium might be really nice for some of the community functions. There's also a really nice conference distribution. However, I can’t easily just tack that on to another distribution or even to the existing site I’ve built up.

For that reason, an approach like the one Drupal Gardens uses is much more appealing to me as a site builder. Allow an easy way for me to decide at installation or later on that I want to tack on a set of functions like a blog or an image gallery or e-commerce.

This would make products more akin to features than distributions. This allows far more flexibility, and that’s a core value of Drupal. I don’t want to have to pick a distribution and then be stuck with it, without being able to add the cool features that another distribution offers, without having to go to a great deal of effort to figure out what modules I need, what configurations I need to make, etc.

+1, Bazzr's "feature's driven expirience" looks really usable
Also having simple layout editor like panels allowed for static & probably dynamic pages could be a great feature

The only reason I think 'features' is relevant to this discussion is because there's a fundamental issue with D7/8 profiles that we don't let you ever, ever move away from them. IMO that's a straight bug in core now but it's also a conceptual issue about how much power the install profile should have on the site - whether I can see it, is there in interface to control it, can I uninstall it without data loss. The answer to all of these questions for D7/8 is an emphatic no, and I think that comes from the changes to install profiles being focused on the needs of people building distributions.

In D6 they were so limited in the other direction that none of those questions even made sense to ask, but we moved in a specific direction towards monolithic distributions in D7 that I don't think is a healthy one.

Since we arcitecturally don't let you have any Drupal install unless it's based on an install profile these are the right kinds of questions to ask I think. Maybe not on this issue though do I'd be happy to split that conversation to another one.

wowzie - @catch, your observations and considerations are highly interesting (again!). That's a lot of food for thought.

I also love to see the flippy module included with D8.

Every second website we build needs this prev/next paging links (At the moment we use custom_pagers to build that), so I think this feature would make many people happy.

Another missing piece would be a "back to overview" link on the detail page, which brings you back to the listing page.

Adding a link to #880940, since it has a real patch

Many of the issue in the IS are duplicates, so tracking the related issue to figure out what is closed or not.

Now remove the completed issues.