Drupal 7 Tutorial: Features Module [March 12, 2014]
Drupal 7 Tutorial: Features Module [March 12, 2014]
Want to learn more about Acquia’s products, services, and happenings in the Drupal Community? Visit our site: http://bit.ly/yLaHO5.
Join Prasad Shirgoankar, Curriculum Developer, Acquia Learning Services for a step-by-step introduction to Features in Drupal 7. Features helps you package up configuration so you can move it more easily between environments. Prasad will also cover best practices when creating Features, and give you some tips to make it easier.
In this webinar you will learn:
• What the Features module does
• What cannot be captured with Features
• How to configure Features to capture configuration
• How to deploy Features in different environments
• Tips and things to watch out for
Moderator: Webinar is a Drupal 7 tutorial with the features module with Prasad Shirgaonkar who’s the Curriculum Developer for our Learning Services Department here at Acquia. We’re really excited to have Prasad on the call. Thank you, Prasad, for presenting to us today.
Prasad Shirgaonkar: Hello, everyone. So good morning, afternoon, evening to everyone. We are going to talk on the Features module today. Just a quick introduction of myself, I work as a Curriculum Developer for Acquia Learning Services. I design and conduct training programs on Drupal as well as on Acquia products. I worked for over 20 years and I have been working on Drupal since Drupal 4.7. Today, we are going to talk about one of the key challenges faced by Drupal developers. That is the configurations management challenge. Let’s talk about challenge first and then obviously we follow by the solution
Prasad Shirgaonkar: Yes. Perfect. Okay. So we’re going to talk about one of the key challenges and that’s about the config management or the configurations management challenge and obviously it will be followed by the solution. Let’s first look at the challenge, what exactly is the challenge first. If you followed Drupal’s recommended development practices, you will typically have a well-defined development workflow. A typical Drupal development workflow consists of multiple environments where your code resides. For example, you may have a local development environment, and a staging environment, and production environment there remotely. You do development on your local environment, you post your code to your staging environment, you do some testing over there, and once the testing is finalized, you push your code to the production environment.
Now, a Drupal site. Typically, the components of a Drupal site as you are aware are the code which are your modules and themes, the configurations which are the content types and views and vocabularies and all the configurations that you do using Drupal’s GUI and the content, that’s the nodes, and terms, and users blocks, all the contents which is added by users to the site. So typically, code resides in code files, so modules and themes are in their own individual files, the .module files and .tpl.php files, java script files, and CSS files, and so on. The content on the other hand, that resides in the database so the nodes and terms and users, they’re all form of the database. Up to Drupal 7, the interesting part was the configurations that we do for building a site like the content types and views, they also reserved. The definitions are also stored in the database.
Now, when you are doing the initial development of your website, copying your code and data or the database from your one environment to another environment, it’s a very straightforward process. So if you’re using some version control system like GIT, you just check-in your code into GIT and check-out on your stage environment and database, you simply take the database down from the environment and push it to another environment and all your environments are getting synced, obviously. When you go down the development stages and when you are doing the continuous development of your website, copying code is simply straightforward but copying database from an environment to another environment becomes increasingly difficult. In some stage, it might become even impossible.
Now, this is because the developer develops the code locally, he adds his own data and does the testing, pushes the code to staging environment. On staging environment, the client test users might add some data independently and when they add the data, they do their own testing and then the code is pushed to the production environment. In production environment, then there’s a live data, the actual data added.
Now, if you copy over your database from one stage, one environment to another environment, it wipes out the data off the target environment. That’s why it becomes almost impossible to copy all the data on the database or actually the configurations that’s stored in the database from an environment to another environment. So this is one of the most prominent challenges faced by Drupal developers. So how do we manage Drupal’s site configurations? How do we move configurations from one environment to another environment without affecting the data or content of the target environment? That’s the challenge that we are going to discuss today and as everything else in Drupal, there’s a module for that. That module is called as features. So what is features module? So this is the URL from where you can get features module, it is drupal.org/project/features. Features modules, as its own name says, it enables the capture and management of features in Drupal.
Now, a feature can be defined as a finite, a defined set of functionality or entities which taken together can satisfy a certain use case. So take the example of, say, a news article. So you have content-type name news articles. You can have a view in which produces various pages or blocks. You could have some taxonomy terms which are used for that particular content type. On that bundle together can create a news feature for your website. What features module does is that it converts and stores site configurations in code rather than in the database.
Now, here are various applications or use cases of features module. We can move your site configurations from database to code which makes it extremely easy to move between environments like the development, staging, and production. We can also check-in in a version control system, like if you just define all your configurations in the database, it’s impossible to check them in in a version control system. Say for example you want to revert back to a previous version of a view, which might be an extremely complex view, it’s absolutely impossible to do it without Drupal’s UI. If you convert that into code and if you version control it properly, you can very easily revert back to a specific version in the past. Another great application that it has got is that you can distribute these features as independent features or independent modules and re-use them across various sites. So suppose you are developing a large set of sites and all the sites require, say, use functionality or requires a user listing functionality or requires, say, a products catalogue. You create it once, you convert that into a feature, and you can use it across multiple sites to minimize your effort or minimize duplication.
So how does features module do it? Let’s have a quick demo of features module. I’m using my local environment and on my local environment I have this dev site and staging site. Now right, now both of these sites or both the environments are on the single machine but they could have been on completely different machines or completely different places, but for this demo purpose, I’m using it on just a single machine but two different code bases completely. So both the sites have almost the same set of modules, but different data. As you can see, the site names and the home pages and everything is slightly different. Now, suppose my dev site is having, say, a content type. That’s news and also a view, news, which pulls the data of that content type and displays it as a page. That functionality is not there on my staging site. Now, if I want to push this specific functionality from my dev environment to my staging environment, I first of all check if I have features module enabled, so I had downloaded and enabled the features module. So enable the module. Features functionality is available on the structure and features. There is no feature right now so I’ll just create a feature. I’ll give a name to my feature, let’s call it as “News”. Just give a unique description. A package, I can just give, say, “My features” and I’ll give a version for this particular feature.
Now, on the right-hand side, I can see various components that I can select. So inside this, what I’m going to select now is the news content type. It could automatically detect the various dependencies that are required to give news content type and I’ll also select news view. So I select all the features that I want to be bundled in this particular feature. I could either download the feature so that it will create code files and download it into a tar or open “Advanced options” and I’ll give a path where it can generate, give an existing path where it can generate the feature and I will click “Generate feature”. Now, if I go to my code base, I’ll find that under the site, so we’ll use the path which I’ve specified. It has created a new folder called the “news”. Inside, features has created several files which are these feature files. I’ll go back to my URL and go to features page again and I can see that it has created a new feature, the news feature which is currently disabled, so I’ll just enable it on the current environment.
Now, we’ll see the use kits; why we need it too or why we should enable it on the source environment. That we’ll be in a few minutes. So this is enabled, I have the news feature of news content type and view, now that’s bundled into a feature.
Now let’s move that to my target environment so just copy this module with folder, you go to my target environment and you’ll have the same folder features custom. I’ll just put it as that folder. Going back to my target environment, I’ll just check. I’ll verify features module is enabled, so you see that features modules is enabled. I can also see that this item module might be just inside that group, it’s the news module. I could either enable it from here or I can just go and check from my features site and I’ll see the news feature is added on my staging environment as well. I’ll enable it and bam, I have a news view added over here and the content types. I have the news content type added over here. So this has absolutely saved me a lot of time of rebuilding that content type as well as a view on the stage. It could be actually a bundle of like multiple content types and multiple views. You can bundle inside a single view, a single feature, and post it from one environment to another environment. So that’s the basic use case or basic use, basic application of features module.
Going further in the workflow of features module, what happens if we make changes to our configuration? So in the content type, say, news content type. If I want to add a new field later on, and I added a new field which is the location field and the text-based field. Now, this on the dev site, if I go to structures and features overview page, and I’ll also add inside the view, if I make some changes, say, I don’t know the behavior. So “no data”. So I’ve made some changes to my content type, I’ve made some changes to my view. If I go to structure and features now, it shows me the state as overridden. What that means is that the configurations which are stored in the code of features are now different than the configurations which are stored in the database. So I need to either to match them, I need to regenerate the code on my source site. So I’ll just click see what’s happening so that you can be sure that the database is different and I go to recreate, and under recreate, under advanced options, and just generate the feature. So after I generate, I’ll just view it again and make sure that it’s in the default state. Now, I need to copy the newly generated code from my source site, that’s my source site from where I’ll just copy this new and better code and I’ll just replace the code on my destination site.
So I’m just doing it fairly crudely over here. I really should be doing it and checking it in a version control system and checking out from that system in the real world. Now, if I go to my staging environment and go to structure, and features, just let me try clearing the cache. Okay, so it has the empty text as well as I can see that it has created on content types in news as either the new feed. So basically whatever changes I do on one environment, I can keep on adding, keep on just reflecting those changes or transferring those changes from one environment to another fairly easily with features module. Going back to our – let’s have some discussion on some other features of the features module. So some intricacies of features modules and how do we extend features module. There are some unique terminologies with features module. Those datasets that we saw on the features page, sometimes, that shows a state that’s overridden that we saw. There’s an option to revert or there’s an option to update the feature. So when we want to save, make changes, use site configurations in the database. When we do revert, actually what it does is that it changes the configurations in the database to match with that in the features module’s code. When we update a feature, what it does is that it creates and produces a newer version, a newer code versions between the configurations from the database.
So these two terms are used quite often with features module. The key question that people asked is that what exactly can be ‘feature’ized? So these are the things which can be ‘feature’ized or which the configurations can be stored in features module. From the core, we can store content types, we can store vocabulary definitions, user loads, permissions, field definitions, text formats, menus and menu items, and image styles. They all can be exported to a feature. From contributed modules, we can store the views definitions, panels, mini-panels, rules that we use for sites, context, as well as the display suite configuration. These all can be ‘feature’ized and many, many other contributed modules. They can export their own settings to features module. What cannot be ‘feature’ized are field like content. So things like nodes, terms, users, and your custom blocks that you add, and the native blocks that you add to the site. These cannot be ‘feature’ized because that’s content and they cannot be stored as a part of code.
A couple of advanced usages of features modules, if you use the module called the Strongarm module that exposes Drupal’s entire variables system to features which basically means that you can export things like your site name, the site slogan, or your team setting, and anything that is stored in the variables table that can be exported into a feature. If you use Diff module, you can actually compare when it shows that feature is overridden. It shows what exactly is the difference. That, you can be using Diff module. Features module has got fantastic integration with Drush. There are lots of Drush command like we can lift all the features, you can see the components of an individual feature. You can see the differences in the feature, in the database and the code. You can expose features, you can revert features, and of course you can update features. So these are all the extensions or advanced uses of the features module.
Just a little slide on resources, where you can find all these, so features module on drupal.org is at drupal.org/project/features, then comprehensive documentation along with examples on drupal.org, and the links for Strongarm module, and Diff modules. So this was a brief presentation about the features module, its use cases, and how to use that module. I’m open for questions now.
Moderator: Great. Thanks, Prasad. If anybody has any questions, could you please ask them now in the Q&A section? We had one come in so far. Can installation of features be automated during Drupal installation like installation profiles in some way?
Prasad Shirgaonkar: Yes, perfectly. It can be. So when you create features, they actually become like your modules. Sorry, just a minute, I just stopped sharing my desktop. Okay. When you create features, they become like modules and you can include them as part of installation profiles and they can be automatically enabled while installing new sites.
Moderator: Awesome. The next question is using Drupal 6 here still. Is there a very big difference between 6 and 7 in the features module?
Prasad Shirgaonkar: Yes. The main difference is in the URL features module but the core, I think, that it does. The core content, the core entity that can be exported. That hasn’t changed.
Moderator: Okay. As a reminder, slides and recording will be posted to our website. I think that’s it for questions. If anybody has any follow up questions, you can reach out to me or Prasad and we can get them answered for you. Prasad, would you like to end with anything?
Prasad Shirgaonkar: No. I just would like to say that for doing the normal day-to-day, Drupal Development workflow, and if you are especially working on complex projects, features is an absolutely must have step in your Drupal workflow. It saves a lot of time for development as well as keeps our code, our configurations completely under our control. So it’s absolutely worth spending time and exploring that module. Make sure that you use it and make it a part of your day-to-day workflow.
Moderator: All right, thanks so much everyone. Thanks Prasad.
Prasad Shirgaonkar: Thanks, bye.
- End of Recording -