I created a content type and disabled the feature that I was creating to debug.

But now, the content type is no longer available on admin/content/node-type/ page.

And I cannot add it.

Comments

q0rban’s picture

Status: Active » Closed (works as designed)

the content type is no longer available on admin/content/node-type/ page.

This is by design.

tim.plunkett’s picture

Category: bug » support
Status: Closed (works as designed) » Active

Is there a way to prevent this behavior in certain cases?

My scenario:
I create a feature that defines two content types. Later I realize I should have created two separate features. I can't make another feature that defines the same content type because of conflicts, but disabling the feature removes the content type altogether.

yhahn’s picture

Status: Active » Closed (won't fix)

Not at the moment. The easiest way to move components between features is to cut and paste the info file lines and the portions of the defaults hooks you need.

tim.plunkett’s picture

Category: support » feature
Status: Closed (won't fix) » Active

I was able to stop features from deleting the content types when disabled by this: update node_type set module="node", custom=1, modified=1, locked=0 where type="TYPENAME";

I think that it might be a nice option, similar to the option to disable orphaned dependencies. Feel free to "won't fix" this again, but if you think there is any merit behind my suggestion, I'm willing to work on a patch.

tim.plunkett’s picture

Category: feature » support
Status: Active » Closed (won't fix)

Scratch that, didn't work. Cut and paste it is.

donquixote’s picture

I think this is quite important:
An option to silently disable/remove a feature, in a way that no site functionality is lost. Instead, all content types, views etc that were installed with the feature would now be treated as if they had been created manually.

raven_web’s picture

I second donquixote

donquixote’s picture

Status: Closed (won't fix) » Active

I am once again in a situation where I need this (see #6).
Usually I only need my features for a one-off migration of content types etc. Doing that, I need to get rid of older features to avoid conflicts. This needs to happen without doing any damage on the site (such as, removing a content type).

#3 "cut and paste"
I don't think that's an acceptable solution.
However, if for the time being this is the thing to do, then at least there should be some doc about what exactly needs to be done, and which consequences this will have.

One thing I tried was, to remove everything features-related from the info file. However, in this case the feature will no longer even show up in the features admin page, even though it is still enabled. Maybe I should use "drush dis" instead for the disabling?

citlacom’s picture

I needed to do something similar for a feature that define a product content type and that need to be product class for Ubercart module, the problem is that Ubertcart doesn't allow to add a content type as a product class if is already declared in other module, but when I was developing is really important to trace all the changes and definitions for that content type so I created a feature and when I was ready to deploy I did the following trick:

# disable cs_new_master_catalog due conflict with uc_product content type
drush dis cs_new_master_catalog -y
# redefine the content type and fields disabled by features
drush eval "echo db_query(\"INSERT INTO node_type VALUES('new_catalog_master', 'New Catalog Master', 'uc_product', '', '', 1, 'Name', 1, 'Description', 0, 0, 1, 1, 'new_catalog_master');\")"
drush eval "echo db_query(\"UPDATE content_node_field_instance SET widget_active = 1 WHERE type_name = 'new_catalog_master';\")"

So after disabling the feature I insert again the definition of the content type and set the widget_active for all the fields.

hefox’s picture

Status: Active » Closed (duplicate)