I added a field to my feature of a type whose module wasn't enabled on the production server.

I then pushed the code and went to features admin, where I got this error:

FieldException: Attempt to create a field of unknown type <em class="placeholder">fivestar</em>. in field_create_field

Perhaps Features needs to ensure dependent modules are enabled before it tries to create fields?


I ran into the same issue....I agree that features should enable the dependent modules first, then add fields, permissions, etc. The obvious workaround, is to add the dependency to the feature first, deploy, then add the field and redeploy. Just seems like a kludge to me, but that works.

Category:bug» feature

Patches welcome to autodetect whatever dependency, though I thouht it already did that.

Status:Active» Postponed (maintainer needs more info)

Features should already be scanning your Field export and adding dependencies for modules that it needs. Sounds like maybe there is some obscure type of field being added by a module that is not doing this?

For example, when I add a "number" field, Features properly added "number" as a dependency. When I export a entityreference, it added "entityreference" module. So we'd need a step by step procedure with more detail for whatever specific module you had a problem with. I can't think of anything Features can do that it's not already doing.

It was a while since I filed this, but my wording suggests that the module that provided the field type was included as a dependency of the Feature. The problem was that it was *added* as a dependency, and on deploying the code, Features was trying to create the new field before the extra module had been enabled.

Unfortunately that becomes a core issue. If the dependency is listed in the .info file for the feature module and Drupal is not enabling that module before your Feature module, then there isn't much Features can do.

I think you're misunderstanding the problem I reported.

The sequence of events is this:

- on dev server, create a feature
- deploy it to production. Everything fine.
- back on dev, add and enable a module that provides field type foo
- still on dev, add components to the feature, including a field of type foo
- deploy the feature

So at the point where the crash happens, the feature is already enabled, but a dependency and a field have just been added to its code.

OK, Right, I understand now. But how is Features supposed to deal with this? Your Feature Module A now depends upon Module B. You need to disable Module A, enable Module B, then re-enable Module A. Features has no way to detect that this needs to be done. It's just a normal job of deployment. Part of deployment is to run update hooks, revert features, etc. You can't just push new code and expect everything to magically work.

For example, when I work on a site and add a new module dependency, I write an update hook that enables the new module on production, and part of the production deployment runs the update.php (drush updb) to handle that.

Features does enable newly added dependencies during features_rebuild to my memory, though I never rely on it and likely caches are not cleared between enabling the module and rebuilding the rest of the feature

I ran into the same problem. The solution for me was to perform in "mysite.com/devel/php" the function "module_enable(array('fivestar'), TRUE);"

Thanks Matters for the solution. My site was completly locked up. Lifesaver.

I've solved the same issue by using field_cache_clear() in hook_update() after module_enable() and before field creation.
See https://api.drupal.org/api/drupal/modules!field!field.module/function/fi...