Feature Driven Development : Distros

Moving the database settings from one one instance to other, has always been a menace. Not just in Drupal but web-development in general. Thanks to features module we today have solved this problem significantly if not completely.

A feature is a collection of Drupal entities which taken together satisfy a certain use-case. And what features module does is enables the capture and management of features in Drupal. A features module takes different site building components from modules(with exportables) and bundles them together in a single feature module. Examples of modules with exportables are views, cck, contexts and panels. So in simple terms features bundles together the varoius components from modules like views, cck, contexts and panels.

To get more clarity lets take an example. Let us assume that we are exporting a “Photo Gallery” feature through features module. The “Photo Gallery” feature will typically consist of two content types images and gallery, a view for latest galleries, a view for images in the gallery and a view for the featured gallery. Three to four image-cache presets. Few admin settings. So it would be a herculean task to export all these features individually. With features when you select one items it autosuggest all the other realte entities that should be exported. Using contexts simplifies this process further more.

With the advent of features module, a new trend has started in the Drupal Distro space and its called Features Driven Development. The idea here is to keep the naming convention generic enough so that all you need to create a new Distro is export your features through feature module and create a simple profile with the modules exported by feature enabled by default. Thanks to features module every Drupal developer can now also be a Distro contributor, if he can generalise the requirements. A whole new set of Distros or built base don this concept.

Drush : Set password, watchdog entries and run sql-query

The more you learn about Drush, the more you will love it. Generally most of the developers use Drush only for download modules, install modules and clear cache. But there is more to Drush than that.

1. You have a Drupal instance and you don't remember the password for the admin.

drush user-password admin  --password="IamNotadmin$123"

converting the password to MD5 and storing it in DB drush will take care :)

2. Recently I had an instance of Drupal to which I was not able to login. I wanted to check out the watchdog entries, but as I was not able to login I had to check it from db. I thought drush may help me out and it did.

drush watchdog-show  

For more http://drush.ws/#watchdog-show

You can also use watchdog-list which will give you more control. This throws up a set of options like cc does and you can select what you want

drush watchdog-list 

3. If you are drupal developer and you are using, it's a safe bet to assume that you are using sql-cli. But the pain with that is that you need to remove the braces from the table names to actuall run the query.

drush sql-query "SELECT u.name, u.status from {users} u where uid = 1"

And you can see the result of the query ;) Saves a  lot of time. Doesn't it?

Drupal 6 : PHP snipper to get a list of all the content types with respective fields.

Here is small snippet of php code that will help you get a list of all Content types in an instance along with the fields within the content type. It came handy to me when I wanted to give a list of conent types with fields to one of my clients for remapping them to the new structure that they wanted to build.

  
  $content_types = node_get_types();
  $output = '';
  foreach($content_types as $content_type => $content_type_object) {
    $output .= "" . $content_type_object->name . "";
    $output .= '
';
    $fields = _content_type_info();
    $fields = $fields['content types'][$content_type]['fields'];
    $ouput = '';
    foreach ($fields as $field_name=>$field) {
      $output .= $field['widget']['label'];
      $output .= '
';
    }
  }