Standard Structure of a Feature

The structure of a feature depend on your use case. I will start with the following use cases;

I want to create a feature to manage my site configuration In this situation, you will plan and break your features into pieces based on your use cases or user stories or requirements. its ok to combine the content type fields, base views, content type properties, permissions and anything that is specific to this a use case. Why? because you want to manage the configuration of each requirement/use case or user story independent of the others. This way, you can disable the feature and uninstall the module when the requirement/user story or use case is deprecated by the client. You can also track all issues related to requirement/user story or use case. Here is an example use case or user story; As a content publisher, I will like to use a content type called "Press Release". When I create new content, I will like to have the opportunity to move it through an editorial workflow (Draft, Needs Review and Published). Because I am publisher, I will like to be able to publish the node I created. When I publish a node, I will like it to be displayed with all other press releases when I click on Press Release Menu from the primary navigation. I will like to have separate fields to enter "browser title, full title, summary, full body, image, author and etc". I will like to have the ability to enter custom metatags. For this feature, I will capture the following components;
- Content Type
- Module Dependencies
- Base Fields
- Field Instances
- Metatag
- Permissions
- Strongarm variables (Workbench, state machine, metatag and anything related to this content type)
- Views
I want to create a feature to manage my deployment This is very similar to 1. The major difference is on dependencies. You will have a lot of dependencies here because you want to make sure you can deploy following an established process and not allowing people to disable features that could break site. For example, you will look through your site for common fields, views, SEO and other configurations;
- Create a core/base feature that will hold all site configurations that are the basic minimum needed to run the site. This include modules that your site cannot operate without. All your features will depend on this feature. Without it your site is nothing.
- Create a feature that will hold all the base fields, especially those shared by at least two content types.
- Make all your content types using these base fields depend on the base field module. If a base field is used in one content type alone, keep it in the feature that implements the content type.
- Have a feature for all Base views. These could be views used for backend admin stuff or are common to all content types and etc.
- Create a feature to capture all SEO related stuff that is site specific.
- Create a feature for each content type like in 1 but not including common components that are already captured in other features.
I want to create a feature to share code and allow other people to reuse it without overriding the module

GSA / Open-And-Structured-Content-Models

Standard Structure of a Feature #18