README.txt 7.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236
  1. Current state of Features for Drupal 7
  2. --------------------------------------
  3. Work on Features for D7 is currently aimed at getting to a point where Features
  4. can be used on a new install of Drupal 7 with features that were created on D7.
  5. Once this has been achieved, we will begin working on supporting D6 features as
  6. well as possibly supporting upgrades & migrations between legacy components and
  7. new equivalents (e.g. CCK to fields, imagecache to core image styles).
  8. ### Working components
  9. - ctools
  10. - dependencies
  11. - field
  12. - filter
  13. - image
  14. - menu_custom
  15. - menu_links
  16. - node
  17. - taxonomy
  18. - user_permission
  19. - user_role
  20. - views
  21. ### Has changes to export format between D6 and D7
  22. (@TODO legacy export compatibility)
  23. - filter
  24. - taxonomy
  25. ### Requires upgrade/migration path
  26. - imagecache > image
  27. - content > field
  28. Note on the "Generate Feature" capability
  29. -----------------------------------------
  30. Features 7.x-2.x includes the ability to "Generate a feature" which saves it
  31. to the server disk. This can be a time-saving task in development. It requires
  32. the webserver to be able to write to the very code running the site and is
  33. not recommended for any environment other than a firewalled-off, local
  34. development environment (e.g. a person working alone on their laptop).
  35. Features 1.x for Drupal 7.x
  36. ---------------------------
  37. The features module enables the capture and management of features in Drupal. A
  38. feature is a collection of Drupal entities which taken together satisfy a
  39. certain use-case.
  40. Features provides a UI and API for taking different site building components
  41. from modules with exportables and bundling them together in a single feature
  42. module. A feature module is like any other Drupal module except that it declares
  43. its components (e.g. views, contexts, CCK fields, etc.) in its `.info` file so
  44. that it can be checked, updated, or reverted programmatically.
  45. Examples of features might be:
  46. - A blog
  47. - A pressroom
  48. - An image gallery
  49. - An e-commerce t-shirt store
  50. Installation
  51. ------------
  52. Features can be installed like any other Drupal module -- place it in the
  53. modules directory for your site and enable it on the `admin/build/modules` page.
  54. To take full advantage of some of the workflow benefits provided by Features,
  55. you should install [Drush][1].
  56. If you plan on creating or working with very large features (greater than 1000
  57. items), you may need to increase PHP's max_input_vars configuration directive.
  58. For example, adding the following line to your .htaccess file will increase the
  59. max_input_vars directive to 3000:
  60. php_value max_input_vars 3000
  61. If you are using Suhosin, increasing suhosin.get.max_vars,
  62. suhosin.post.max_vars, and suhosin.request.max_vars may also be necessary.
  63. Basic usage
  64. -----------
  65. Features is geared toward usage by developers and site builders. It
  66. is not intended to be used by the general audience of your Drupal site.
  67. Features provides tools for accomplishing two important tasks:
  68. ### Task 1: Export features
  69. You can build features in Drupal by using site building tools that are supported
  70. (see a short list under the *Compatibility* section).
  71. Once you've built and configured functionality on a site, you can export it into
  72. a feature module by using the feature create page at
  73. `admin/structure/features/create`.
  74. ### Task 2: Manage features
  75. The features module also provides a way to manage features through a more
  76. targeted interface than `admin/modules`. The interface at
  77. `admin/structure/features` shows you only feature modules, and will also inform you
  78. if any of their components have been overridden. If this is the case, you can
  79. also re-create features to bring the module code up to date with any changes
  80. that have occurred in the database.
  81. Including custom code and adding to your feature
  82. ------------------------------------------------
  83. Once you've exported your feature you will see that you have several files:
  84. myfeature.info
  85. myfeature.module
  86. myfeature.[*].inc
  87. You can add custom code (e.g. custom hook implementations, other functionality,
  88. etc.) to your feature in `myfeature.module` as you would with any other module.
  89. Do not change or add to any of the features `.inc` files unless you know what
  90. you are doing. These files are written to by features on updates so any custom
  91. changes may be overwritten.
  92. Using Features to manage development
  93. ------------------------------------
  94. Because Features provides a centralized way to manage exportable components and
  95. write them to code it can be used during development in conjunction with a
  96. version control like SVN or git as a way to manage changes between development,
  97. staging and production sites. An example workflow for a developer using Features
  98. is to:
  99. 1. Make configuration changes to a feature on her local development site.
  100. 2. Update her local feature codebase using `drush features-update`.
  101. 3. Commit those changes using `svn commit`.
  102. 4. Roll out her changes to the development site codebase by running `svn update`
  103. on the server. Other collaborating developers can also get her changes with
  104. `svn update`.
  105. 5. Reverting any configuration on the staging site to match the updated codebase
  106. by running `drush features-revert`.
  107. 6. Rinse, repeat.
  108. Features also provides integration with the [Diff][3] module if enabled to show
  109. differences between configuration in the database and that in code. For site
  110. builders interested in using Features for development, enabling the diff module
  111. and reading `API.txt` for more details on the inner workings of Features is
  112. highly recommended.
  113. Drush usage
  114. -----------
  115. (requires Drush v4.5 or higher)
  116. Features provides several useful drush commands:
  117. - `drush features`
  118. List all the available features on your site and their status.
  119. - `drush features-export [feature name] [component list]`
  120. Write a new feature in code containing the components listed.
  121. If called with no arguments, display a list of available components.
  122. If called with one argument, take the argument as a component name and
  123. attempt to create a feature with the same name.
  124. The option '--destination=foo' may be used to specify the path (from Drupal
  125. root) where the feature should be created. The default destination is
  126. 'sites/all/modules', though this can be overridden via the Features
  127. settings page.
  128. - `drush features-update [feature name]`
  129. Update the code of an existing feature to include any overrides/changes in
  130. your database (e.g. a new view).
  131. - `drush features-revert [feature name]`
  132. Revert the components of a feature in your site's database to the state
  133. described in your feature module's defaults.
  134. - `drush features-diff [feature name]`
  135. Show a diff between a feature's database components and those in code.
  136. Requires the Diff module.
  137. Additional commands and options can be found using `drush help`.
  138. Compatibility
  139. -------------
  140. Features provides integration for the following exportables:
  141. - CTools export API implementers (Context, Spaces, Boxes, Strongarm, Page
  142. Manager)
  143. - ImageCache
  144. - Views
  145. - [Other contributed modules][2]
  146. Features also provides faux-exportable functionality for the following Drupal
  147. core and contrib components:
  148. - Fields
  149. - Content types
  150. - Input filters
  151. - User roles/permissions
  152. - Custom menus and menu links *
  153. - Taxonomy vocabularies
  154. * Currently in development.
  155. Security Concerns
  156. -----------------
  157. If you are using Features to export Roles and also use those Roles in other
  158. exportable code (like Views filters) you can wind up with an unintended
  159. security hole. When you import your Feature, if the Roles do not get created
  160. with the exact same Role IDs then your Views filters (or other component) will
  161. be referencing a different Role than you intended.
  162. For developers
  163. --------------
  164. Please read `API.txt` for more information about the concepts and integration
  165. points in the Features module.
  166. Maintainers
  167. -----------
  168. - febbraro (Frank Febbraro)
  169. - hefox (Fox)
  170. - mpotter (Mike Potter)
  171. - timplunkett (Tim Plunkett)
  172. [1]: http://drupal.org/project/drush
  173. [2]: (http://drupal.org/taxonomy/term/11478)