The Override Node Options module allows permissions to be set to each field within the Authoring information and Publishing options field sets on the node form. It also allows selected field sets to be set as collapsed and / or collapsible.
Tell me if this sounds familiar. You are working in Drupal and want to build out a Blog component for a website project you are working on. You start off in all the normal places -- build your content type, construct your views, setup any image styles -- and before you know it you have this nagging feeling like you’ve done all this before.
When developing in Drupal we all have to continually fight the urge to repeat the same steps when beginning a new project. And a lot of these steps have to do with the way we configure the site building components (Content Types, Views, Panels, etc). This is where the Features module comes into play. It allows the exportable components of these other modules to be bundled up in a way that it becomes its own Drupal module.
Once you have all your Views, Content Types, and other components working as you want on your development site you simply create a new Feature and begin assigning all the parts to it you want. Once you are all ready Features will give you a TAR download of the module file with everything combined. Simply upload the module folder up to your Staging or Production server as you would a normal Drupal module and then enable it through the Features admin interface.
Best part is, when you start making changes and revamping the components on your local development server, just redownload the Feature and enable it on the live environment the same way you did before. No more having to remember every little change you made to the database configuration, let Features keep track of all that for you.
I don’t know about you, but I love the idea that all the elements we create, be they configuration or development, are exportable to code. This streamlines the entire development process, adds protective layers when tackling bug fixes, and allows for integration with your own internal version control software (SVN, Git, etc).
Now the rub comes when trying to export components that are stored in the database as an id since Features module looks to the machine name of the component’s unique identifier. But thanks for the Drupal community there are solutions arising to fill this need:
- Role Export allows you to convert the user role id into a machine name
- Features Extra does the same but for Vocabulary, Nodequeue, and Blocks entities
- Strongarm module gives the sitebuilder control over Drupal default variables
For individual terms, nodes, and users this export concern won’t be a problem since there shouldn’t be any data entry occurring on a development server anyway. Save the real content for a Staging or Production server.
The final reason I feel it is best to follow this methodology when developing components for Drupal is for the quality assurance; to ensure that nothing is missed when migrating components from the Dev to Staging to Production. All too often it is easy to miss one checkbox in Views or a line added to a Rule when migrating functionality to the Production environment after it has been tested and approved on Staging. When Features and version control are used in conjunction to just about eliminate this room for human error.
Oh, and don’t even get me started on how Drush can play into this. Explaining the Features/Git/Drush trifecta would be an entire blog post all its own.