Last updated 9 March 2012.

Drupal core should include the ability to:

  1. Manage/abstract configurations
  2. Package them into small pieces as features
  3. Automate their setup/configuration

This will allow for 1 click setup of new features on Drupal sites such as blogs, image galleries, wikis, social networks, and more!

This functionality should be integrated to work during install and on existing sites.

It should be easy to export or share features from existing sites help setup new ones.

There should be infrastructure on Drupal.org to accommodate sharing, collaborating and improving these and ideally they should be able to be downloaded directly from new, fresh Drupal installations.

The following efforts should be combined into one system for Drupal core that accomplishes this:

TODO:

  • Add list of existing issues related to this
  • Define required core architecture
  • Create new issues in the queue for the necessary components

More to come...

Comments

Senpai’s picture

Chris, this is a really great start. Here's what I'm envisioning for core at the present moment, based upon the Usability Summit meeting (http://www.d7ux.org/structure-summit-sunday) There's going to be a three-tiered, drag-n-drop Site Builder tool of some sort or another in Core by D8, and possibly a variant thereof as a contrib for D7.

With this in mind, there needs to be a framework within D7 Core for submitting pre-determined groupings of data to Form API in order to make the administration sections of core do flip flops behind the scenes while the user merrily drags and drops things to their heart's content.

In order to realize this feat within the allotted time frame of < 10 weeks till code freeze, we must leverage a pre-built solution. Luckily for us, there a project in contrib that satisfies over 90% of the requirements we need right now.

Patterns module has undergone a serious refactoring since it's inception. When it began life, it was nothing more than a module that read XML, PHP, and YAML files, and submitted them to the Form API one after the other until something broke, then it stopped and reported the error. Now, it's been refactored into a UI-type module and an API module. The API is what we should focus on.

The Patterns API is currently the most suitable approach that we have working right now in contrib that has a chance of making it into core before code freeze. At the Usability Summit, I volunteered to spearhead the drive to get an API into core for some future Site Builder contrib module to leverage. Since then, I have spoken to Gravitek Labs (the team responsible for Patterns), and Crell has offered his knowledge and assistance with core's API structure to ensure that this is A) The very best code that it can be, and B) removable when the time is right for D8 or D9 to manifest it's fully visioned import/export framework.

Let the discussions begin. We need to talk through how much of the Patterns API should go into core, and fully harden it for error-proof interaction with Forms API.

****
Joel "Senpai" Farris | certified to rock score

Senpai’s picture

I forgot to reply to "It should be easy to export or share features from existing sites help setup new ones". This is not a feature request at this time, even though, it'd be really awesome, so that frees us up from having to realize such a system at this time. Whew.

****
Joel "Senpai" Farris | certified to rock score

eigentor’s picture

This is much needed and great, but a D8 feature for sure. Making Install profiles better could still make it into D7 though.

Summit’s picture

Hi, it would be great if also you could set up if you want newer .dev or versions of a module be installed automatically with sort of wizard that shows you the readme.txt of the specific module which is updated. Just like normal working when installing a program on Mac or else..
greetings, Martijn

Aren Cambre’s picture

This is a great idea and needs to be aggressively pursued. Right now complex functionality has to be custom-instantiated by the site owner or implemented in its own significant module.

Custom instantiations mean each site has its own flavor of some functionality and that site owners are collectively reinventing the wheel.

Implementations in significant modules means module developers are reinventing the wheel by duplicating functionality already in Views, Fields (CCK), Panels, and other modules that extend those three. They should be replaced with something like this. Examples include Biblio (#682044: Support fields (CCK) in D7 Bibliography Module) and Project+ (#85049: convert project* to CCK, especially see #28).

From the above list, it looks like features is the furthest along?

This is big. Is it getting attention from Drupal leadership?

rcross’s picture