Standard Structure of a Feature

[jdearie]

No description provided.

[click2tman]

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

1. 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

1. 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.
2. I want to create a feature to share code and allow other people to reuse it without overriding the module

[GeilerC]

We have several content models that are available you to take and implement for your needs or use as as starting point for the content model you are creating. They are available for download.

Additionally, there are several free APIs available for download that allow your content to be syndicated. The URL for the storefronts are listed here:

Health Content for Syndication

Health and Human Services Syndication Storefront https://digitalmedia.hhs.gov/storefront/
Centers for Disease Control and Prevention Public Health Media Library https://tools.cdc.gov/medialibrary/index.aspx?context=e30%3D#/results

More information and details pertaining to the free syndication tools offerings can be read here:
http://www.digitalgov.gov/2014/11/10/get-more-health-content-for-your-websites-apps-and-social-media/