Dependencies are not checked before an updated feature is automatically applied

I have been thinking a bit more about this problem. I really like how Features can help and make development/deployment easier, but its habit of automatically applying changes when I upload a new version is quite scary.

How come it does it this way and not allow me to do this manually?

Anyhow, my suggestion to solving this is:

• Detect the new version and display an message, with link to admin page, for users with permissions to administrate features so they can trigger the update. Do not automatically apply them!
• Make it possible to select several updated features modules to be updated at the same time.
• Add an option to put the site in Maintenance Mode before the update. Then set it back to live after the updates are applied

Something like this would make working with and deploying updated features a much less scary operation.

At the same time it would also let me update several modules at the same time, which will be very handy if they have dependencies on each other.

I do understand the part about managing configuration/change in code. However, when reading the project page it also says:

as a way to manage changes between development, staging and production sites

As a site builder it is very easy to see how useful this module can be to make deployment of new features on a live site easier and quicker. As well as rolling out updates to them.

To be hones, limiting the scope of this module to just "managing it in code" almost seams like it is only half complete to me.

I fully understand the advantages of having configuration in code, especially when you collaborate with other developers on the same site.

The project page also talks about building features such as blog, pressroom, image gallery and so on. But to use those you need to deploy them on a site, don't you? Plus that as we know sites are constantly changing, features are added, changed or removed.

I believe that with just a few additions, such as the ones I suggest in this issue Features can take the next step and become a great deployment tool as well. Its almost there, using the checklist I published in the post you commented on makes it somewhat controllable for that purpose.

I also believe that if such functionality would be added it would also make it much easier for developers and site builders (click monkeys like me) to collaborate even better and more productive.

Hi Fabian,

Sorry for the delay in responding, have been a busy week for me.

Thanks for your clarifications, they are most enlightening to me and have helped me better understand how Features work, as well as adjust my workflow using it.

However:

You are right that you are not warned that dependencies are missing, but this is not specific to features, but rather is valid for all contrib modules.

That other modules doesn't properly check this is, in my view, not an excuse for Features not to do it. Especially considering that dependencies are checked for not enabled features.

As you say, Features configurations are run from code, with one important exception - dependency modules will be written to the database as enabled no matter if they exist or not for enabled feature modules.

In my experimenting this has rendered my sites unusable and forced me to manually edit the database.

This could easily be avoided if Features run the same test for enabled modules as it does on disabled. If it doesn't find the module the feature requires it should warn users with permission about it. Then I simply have to upload that module and everything will work as planned.

That would at least prevent the risk of rendering the site unusable in most cases.

I am a site builder, not a coder, so your suggestion that I add my own check for this is not an option. And why should I when Features clearly already has this possibility for disabled features?

Is there any good reason why this is only done for disabled features?

As I have said before I am not a skilled coder, but I had a look at the Features code and found this function.

<?php
function features_install_modules($modules) {
  module_load_include('inc', 'features', 'features.export');
  $files = system_rebuild_module_data();

  // Build maximal list of dependencies.
  $install = array();
  foreach ($modules as $name) {
    if ($file = $files[$name]) {
      $install[] = $name;
      if (!empty($file->info['dependencies'])) {
        $install = array_merge($install, _features_export_maximize_dependencies($file->info['dependencies']));
      }
    }
  }

  // Filter out enabled modules.
  $enabled = array_filter($install, 'module_exists');
  $install = array_diff($install, $enabled);

  if (!empty($install)) {
    // Make sure the install API is available.
    $install = array_unique($install);
    include_once DRUPAL_ROOT . '/' . './includes/install.inc';
    module_enable($install);
  }
}
?>

From what I understand it works like this:

1. Read the dependency array from the feature modules .info file
2. Filters out those dependencies that already are enabled
3. Runs install on those that are not enabled.

If I have understood this correct, wouldn't it then be possible to add a check before step 3 where it also checks if the module is actually available (installed)?

When you look at the module list, for some modules there is "missing" in red when a module depends on a another module that isn't installed and the checkbox is greyed out so it can't be checked.