I created a feature on site A and then enabled it on site B, which worked as expected. But when I disabled the feature on site B, the content types created by the feature were not deleted. I've confirmed that in the D6 version, content types created by a feature are subsequently deleted when the feature is disabled (even if you have created content of that type), so I assume this is how it should work in D7.

Current workaround

Add a delete at the end of the URL.
E.g., admin/structure/types/manage/typename/delete

Files: 

Comments

Having the same issue. Imported content type can not be deleted even though features module is uninstalled. And should the imported feature be visible under admin/structure/features manage list? In my system it is not visible there. Using vanilla D7 and Features 7.x-1.0-alpha3.

There's a patch for your issue with not being able to see the imported feature:

http://drupal.org/node/1018178

Subscribe

I'm getting the same thing. Also, the 'delete' button has been removed. So if I uninstall the feature, then go to the Content Types section, not only is the content type still there but the delete button is missing, so I can't remove it at all.

Update: This isn't specific to content types, the same thing happens with vocabularies. They don't get removed, and if you go to the taxonomy page, the delete option is gone.

I believe the functionality you're describing (where the delete button is missing) is intentional. Because disabling the feature is supposed to delete the content type, you're not actually supposed to be able to delete it otherwise. I've confirmed this is how it works in D6.

Ah ok, so then the error is that uninstalling or disabling the feature isn't removing the associated content types and vocabularies/terms. It also isn't removing included views. Which makes me think that the uninstall function isn't doing anything at allo. Can anyone confirm whether or not things like text formats, etc get removed?

Hi,
I have the same problem.
With features-7.x-1.x-dev I can disalbe a features and I can unistall it in modules administration, but the content types is not removed. The same problem for rules and permission but in this case I can remove it manually.
The views are removed.

Version:7.x-1.0-alpha3» 7.x-1.0-beta1

Seeing the same issue on beta1. Any solution for this?

Priority:Normal» Major

Also seeing this behavior in 7.x-beta1

It appears that the uninstall isn't actually doing anything.

When I uncheck an enabled feature, which presumably should remove anything associated with it, I'm seeing a very non-helpful message in the log:

"The file was not deleted, because it does not exist."

LOCATION: .../admin/structure/features/cleanup/clear?render=overlay
REFERRER: .../admin/structure/features?render=overlay

Uninstalling from the modules page claims to have completed successfully, but nothing appears changed. Any insight on this would be awesome. Thanks!

I am having the same problem. Subscribe.

Unless 7 has changed a lot, the views should have disappeared when the code defining them disappeared unless they were overriden before disabling the feature. Views are true 'exportables'.

this issue exists in 6, however I really don't want features doing anything without control on how removing content (nodes) and their associated is done (sometimes someone wants to retain parts of the feature despite removing the feature -- I've heard support requests for this on IRC).

I'd imagine features suggesting how to create a hook_uninstall to define removing respective parts of itself from database.

As for content types, if it hasn't changed change the base field in the database (node_type table) to 'node_content' should fool core into thinking the node type was defined via the UI. They should, however, likely already be marked as disabled looking at _node_types_build. (what is currently the base key?).

D6 features didn't deleted content types; they were marked as disabled in _node_types_build.

How can we intentionally delete a content-type in that case ?
I created copy of similar content-types and import them in a feature, but I realized that it will be better to use field_group instead of multiple content-types.
I cannot believe I'll be forced to go to the database and delete every occurrences of table fields_*, field_revision_* and node_type.

Stuck with this as well while developing new features. It doesn't remove and recreate the content type, so some old settings seems remained as well. Any other way besides manual removal?

As of now I think you just have to do it manually unfortunately.

To manually delete a content type that was created by a feature:

  1. Disable the feature. I've sometimes run into problems with this--a feature won't disable. In this case, remove the feature module code.
  2. Determine the machine name of the content type to be deleted, e.g., 'mytype'. In the site database, revert the node_type table values to the defaults as if the content type were created manually through the UI:
    mysql> UPDATE node_type SET module = 'node', custom = 1, modified = 1, locked = 0 WHERE type = 'mytype';
  3. Clear caches to ensure the content type change is available.
  4. Through the UI at admin/structure/types, delete the content type.

subscribe

this bug makes it a bit strange to use feaures to export content types :/

Version:7.x-1.0-beta1» 7.x-1.0-beta2

this bug is still in beta2 changing version tag and secretly subscribing...

Update: I've found out that d6 does delete disabled content types (see node_types_rebuild). However, CCK does not remove disabled content types fields, (see #1136632: content_fields_list displays empty content types (content_type_delete doesn't delete disabled fields )).

However...

Disabled a module should not remove it's data from the system in the backend; (however it's functionality should not show up). Uninstalling a module is the step where the data should be removed (see hook_disable/hook_uninstall).

My guess is that this issue reflects a different core d7 bug (disabled content types cannot be deleted but show up) combined with a features issue (features doesn't do hook_uninstall/fully remove the content type from the system).

Druapl 7. I use this code to prevent adding content for disabled feature/content type (place this code into *.module file):

function HOOK_disable() {
$num_updated = db_update('node_type')->fields(
array(
'disabled' => 1,
)
)
->condition('type', 'MY_CONTENT_TYPE', '=')
->execute();
}
function HOOK_enable() {
$num_updated = db_update('node_type')->fields(
array(
'disabled' => 0,
)
)
->condition('type', 'MY_CONTENT_TYPE', '=')
->execute();
}

I have the same issue with content types created by a feature on Drupal 6 as well. I just tried to remove the Views Gallery feature that Jeff Eaton made, as KarenS has contributed a full version of it as a module now. I tried removing what Jeff made as per Karen's instructions on the new Views Gallery module page and ran into the same issue described here. I am not sure how to post that other than to add it on to this issue and let the maintainers figure that out.

This is a rather big issue.. Kinda defeats the purpose of "features" if you can't delete CT's once a feature is "removed" from the system via disabling the feature or by removal of the feature altogether..

sub

subscribe

Confirming that #16 works as a workaround (and secretly subscribing).

+1 for #16 workaround.

subscribe

sub

Subscribe

Subscribe

Status:Active» Needs review
StatusFileSize
new3.57 KB

Attached patch:

  • Introduces two new hooks that component types can implement: hook_features_disable() and hook_features_enable().
  • Implements these for node, following the approach in #16. When a feature is disabled, any content type it provided is converted into a standard, custom node type. If the feature is reenabled, it's converted back.

Subscribe

#32 the content type still won't be deleted automatically, just can be deleted manually.

subscribe

Approach in #16 worked for me as a workaround. Thanks.

subscribe

Subscribe

#32 's patch works for me.

And I decided not using features for content types, for:

1. not good support of field changes on content type

2. may potentially destroy nodes data

3. changes on content type won't cost too much clicks

I can confirm that #32 works for me as well.

subscribe

suscribing
I've try to apply the patch of #32, but couldn't, it might be because it's beta-3 now. If somebody could re-roll this patch for the latest version, would be appreciate. Otherwise it might just be my noob-drupal skill that are still at level "idiot"

Status:Needs review» Reviewed & tested by the community

I like the approach in #32, I think it's a good compromise, since it might be very harmful to the user if the content type would just go away. Someone who would like to change this behaviour could change it by implementing the features_enable and disable hook themselves, which means you are not necessarily locked to this solution.

This also opens the door for doing using a similar approach for other components that might cause similar issues.

With that in mind, I set this to RTBC.

The patch looks clean and the hooks look easy to understand, but should we be weary of introducing a new hook instead of trying to use the parent hook instead? Course, there'd be issues with the includes being included on demand; this way is much easier.

(Has anyone opened or look for a core patch? -- this is a bug/regression in core also as this used to work fine in 6).

I did some checking, and I don't think it's core that has changed that much, it's probably more likely that because features have changed how it works with node types since D6.

In Drupal 6, Features always declared content types so that they belonged to the features module. That meant that we needed to implement hook_form ourselves, and that all modules that were controlled by features looked like they were a part of it. Have a look at http://drupalcode.org/project/features.git/blob/refs/heads/6.x-1.x:/feat... and look for features_form to see it in action.

In D7 this was changed, the node_info hooks that are being exported declares 'node_content' as their base. node_content nodes are handled differently than others, see http://api.drupal.org/api/drupal/modules--node--node.module/function/_no...

Going back to the old approach would probably make our node types dissappear directly instead of giving the user the option to remove it. It could still be a viable approach as well I guess.

ahh, it does sound like the nodes types shouldn't be being exported with node_content as base, from the comments in that function (that indicate node_content is specially for node types that are defined via the database). Feels like it'd be best practices to do what 6 did then, not sure.

(There's defiantly changes in core for disabled items though I've noticed; node_types_rebuild used to delete them, but it no longer does as far as I can tell.)

Subscribe

sub

subscribing

Status:Reviewed & tested by the community» Needs work

So I am conflicted, I think have the same functionality in d6 where they get removed is of value, but I would prefer that that happen on uninstall, and not on disable. It seems like disable should not destroy user enter data (the nodes of that type). And have disable do what happens in #32.

So we would have a two step process.
1. disable places the content types to a db state
2. uninstall removes content types (including all nodes of that type)

Any thoughts?

Good suggestion. There are a lot of issues associated with deleting content types and orphaning nodes. To help understand what our best options are, we should look to #232327: Deleting node type leaves orphan nodes, which maps a lot of this out. Basically, this is semi-broken in core, and while we probably can't fully fix it in Features we can improve on what happens now.

I'm in favor of the patch in #32 to allow a content type to be removed via UI on a module disable and "re-owning" the content type on module enable. My only question is what if you turn on a Feature that has a content type with a key that already exist sin your system, "blog" keep coming to mind. We have no way of knowing if we used to own it or if it was pre-existing.

That said, this issue can focus on what to do when disabling and deleting the content type an nodes should be addressed in another issue.

(I don't think it's a good use of effort for features to worry about something conflicting modules too much, at least on the level of a specific component. -- ie this can happen outside of features, etc.)

Status:Needs work» Fixed

So thanks for all the collaboration on this. Committed patch from #32.

http://drupalcode.org/project/features.git/commit/e00d7e5

I think the comments hefox makes in #46 likely deserve some more thought and if there is a push for that we can create a new issue. What to do on uninstall can be created in another issue as well, but at least we now have the flexibility to more the content type manually, before that was not even an option.

Thanks! it's a start anyway.

Re #52,"what if you turn on a Feature that has a content type with a key that already exist sin your system", I've pushed that to a new issue, #1279348: Detect feature conflicts with existing site components.

subs

Sub

Subscribe.
At the moment, which version of features included this bug fix please?

@herve right now only a dev version but I think we will be rolling a new release in a day or so.

This is interesting. I created a content type using features in Drupal 7. I imported some content into the content type to test it and it worked fine.

I've cleaned the data up and want to upload fresh data, but I can't delete the old data. I get sent to a 'white page' with no text. I can't even delete one piece of content manually.

Is this because I used features to create the content type?

Any help would be appreciated

@mwbyrd That is not b/c of Features.

Subscribed

subs

subscribe

You can actually still remove it, it's just the button that's missing.
If you manually go to /admin/structure/types/manage/"content_type_I_want_to_delete"/delete it will delete it (at least I succeeded in doing so).

Not sure if it in some cases is also needed to edit some of the database fields like in #16 , I didn't have to.

I also was able to delete it with the following steps:

  • Disable content type feature (drush dis "content_type_I_want_to_delete")
  • Disable Features module (drush dis feature)
  • Navigate to your content types (admin/structure/types)
  • If the delete link is missing under operations, manually paste /admin/structure/types/manage/"content_type_I_want_to_delete"/delete and it should delete the content type.

Thanks! micahtaylor your step by step was a successful!!

Version:7.x-1.0-beta2» 6.x-1.0
Status:Fixed» Active

need to be backport for D6

Now i need to use custom code:

function custommodule_uninstall() {
module_load_include('inc', 'custommodule', 'custommodule.features.content');
module_load_include('inc', 'content', 'includes/content.crud');
$fields = custommodule_content_default_fields();
foreach ( $fields as $field ) {
content_field_instance_delete($field['field_name'], $field['type_name'], FALSE);
}
// Clear caches and rebuild menu.
content_clear_type_cache(TRUE);
menu_rebuild();
}

Version:6.x-1.0» 7.x-1.x-dev
Status:Active» Fixed

I think 6.x would be better discussed in a new issue; they are mostly two different things.

This was a bug for 7.x due to handling node types not as core wants them handled in hook_node_info, whereas in 6.x it handles them like core handles them and thus works as expected, so it's a feature request to add in additional behavior. It's also more painful.

#65 solves it

thanks tinefin

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Version:7.x-1.x-dev» 7.x-1.0-beta6
Status:Closed (fixed)» Active

I am still seing this issue in 7.x-1.0-beta6.

Subscribe

@radoo stop subscribing and start following. see the green button at the top of all issues you wish to follow/subscribe to.

Title:Disabling a feature does not delete content typeDisabling a feature does not disable content type

delete => disable

Since disabling should never delete

Like #72, I am also still seeing this problem in Features 7.x-1.0-beta6. When I disable (and even uninstall) a feature, its content types remain available and can't be deleted. The workaround in #16 worked.

How about this time we fix the core issue (then revert the patch that was added).

Looked around for it but didn't see it, so filled #1441950: Node types removed from hook_node_info with base = 'node_content' cannot be deleted

Thanq nedjo.,It works fine for me.,Great....

#66 it works, thanks. "content_type_I_want_to_delete" needs machine name, like "features_test".

Status:Active» Postponed

I'm marking this postponed since it a core bug. Please, please test the core patch else it'll just not get fixed!

Version:7.x-1.0-beta6» 7.x-1.x-dev
Status:Postponed» Needs work

Re-opening this. I agree that getting the core patch is useful. But I would also like to get this fixed in Features itself in the meantime (since any core patch will be D8 and then need to be backported).

Removing a Node Feature (content type) should *not* automatically remove anything...that just causes problems with unwanted data loss. However, disabling a Node Feature *should* allow the content type to be manually deleted.

As mentioned above, you can still manually delete it by going to the proper URL. So it's just the Delete button itself that is missing. Shouldn't be too hard to find a way to fix that.

I'll review the previous patches to see what I can do. I know that I'm personally running into this issue on one of my sites right now and it's very annoying.

@mpotter: thx for looking into this. It looks like some change subsequent to the patch applied in #54 broke this. Possibly a change in Drupal core? Steps to diagnose would include: (a) ensure hook_features_disable is triggered; (b) debug node_features_disable() in features.node.inc.

Of course, we could roll back what was done in #54 and take some other tack to fixing this.

Fixing it in features is an unneeded band-aid. It results in less need to get it fixed in core, which makes it less likely to get fixed in core. Only patch for core issues when it's a critical/security issue -- this is not. It's an edgecase that has a workaround most people who can install a module/feature, can do.

There's been many projects that have done bandaids, and the corresponding core issues have just sat around for years cause no one had any need to fix them. It's not good for drupal to patch contrib for core issues.

subscribe

#84 @ridgekuhn -- you can now click the follow button at the upper right hand side of the page as opposed to "subscribe". (note, see Stop subscribing, start following) Cheers.

Thanks nedjo (#16).

Not having a clearly defined behavior for disabling a feature does make this module feel incomplete.

Ok, this is how I think it should be done:

Problem:
- Deletion of node types or other things can result in severe data loss, which needs approval by the admin / site builder.
- Not deleting the node type leaves an undefined situation, because the node type is still associated with the now non-existing feature module.
- When disabling or even uninstalling a module, there is no point where we could ask for approval for anything.

Solution:
- Whenever a feature is disabled, it should leave a "ghost feature" in the database, to remember everything that was created by the feature, and that may now be orphaned. This information will be remembered even if the feature is removed from disk. (I think we should already create that ghost thingy while the feature is still enabled)
- The admin / site builder can browse the ghost features, and use them as a handle to clean up the mess. He will have the choice to either remove the functionality, or to "liberate" it, making it independent from the disabled feature module.

E.g.
- Admin enables the feature "mysite_citygroups", which creates/defines a node type "city_group".
- Admin disables the feature "mysite_citygroups". The content type remains, but in a broken state, where Drupal still thinks it belongs to a feature.
- Admin visits the ghost feature page for "mysite_citygroups", and sees that a content type "city_group" still exists. He can now choose to either liberate the content type, or remove it.

Title:Disabling a feature does not disable content typeDisabling a feature does not disown content type

The providing module should not disable the content type. It could possibly disown it.

If you enable the book module, then disable it, the book content type is still present.

Features should behave the same way.

See #1268974: For disabled node types with 'base' != 'node_content', _node_types_build() does not return data about the type. for more details.

#65 and #66 worked for in my case. thanks!

Thanks... It worked.

#66:
Thanks, that works for me.

My wish:
Get it as code, please

Version:7.x-1.x-dev» 7.x-1.0-rc2

Still with the same problem, no solutions for the code?

#66 and #65 and #16 are just workarounds. I don't want to start in discussions that if it should behave one way or another. At least, for sure, it should do that: disable a feature will free the modules with whom it was dependant so I will be able to disable them too. Unfortunately that is not the case. For example, I installed a feature that had a content type with a field "date" which required the "date" module. After disabling the feature, I can't disable the "date" module, (and there are no more dependencies on date).

And I have to test it more, I guess it is just my messy hacked drupal installation, but, in my case, after deleting the content type using #16 #65 or #66, if I reinstall the feature, I don't get the same fields as before, kind if only the "title" and that's all.

Version:7.x-1.0-rc2» 7.x-1.x-dev

traveaoist: don't change version like that :(

And yea, there is code, in the patches against core, cause it's a core bug, (two mentioned so far in this thread, at least one of them should fix this bug). People, try them please so it can be fixed for everyone, instead of doing the workaroud!

However, the other issues you mentioned are unrelated to this specific bug, and should be tested against -dev version to see if they exist again, then if existing, see if there's open issues on them and if not, filed separately.

workaround: add a delete at the end of the URL.
like: admin/structure/types/manage/testtype/delete
Works fine for me.

Works for me too.
I'd push the LIKE button if there was one...:-)

This can also be solved through a FEATURE_NAME.install file:

<?php
/**
* Implements hook_uninstall().
*/
function FEATURE_NAME_uninstall() {
 
// List custom content types added by this feature
 
$custom_ctypes = array(
   
'blog',
  );
 
// Go through each and unlock the content type
 
foreach ($custom_ctypes as $ctype) {
   
db_query("UPDATE {node_type} SET `custom` = 1, `locked` = 0 WHERE `type` = :ctype", array(':ctype' => $ctype));
  }
 
// Clean Drupal cache; this is necessary for the "Delete" link to appear
  // next to the content type created by the feature.
 
drupal_flush_all_caches();
}
?>

If you use admin menu it still presents the delete links, even if the admin page doesn't.

;-)

Found another way to force content type deletion by following whats inside content_type.inc, that is:

<?php
/**
* Implements hook_uninstall().
*/
function MODULE_NAME_uninstall() {
 
node_type_delete('CONTENT_TYPE_NAME');
 
variable_del('node_preview_CONTENT_TYPE_NAME');
 
node_types_rebuild();
 
menu_rebuild();
}
?>

This does not delete fields created by the module and used in the content type, does it?

This works for me:

In the MY_FEATURE.install file:

function MY_FEATURE_disable(){
  //custom content types
  $custom_ctypes = array(
    'article',
    'page',
    'custom_content_type',
  );
  db_query("UPDATE {node_type} SET `custom` = 1, `locked` = 0 WHERE `type` IN (:ctypes)",
    array(':ctypes' => $custom_ctypes));
}

ref #65 works for me.

Thanks tinefin.

zeropoint.IT

Priority:Major» Normal
Issue tags:+How to delete content type imported by Features module

I deleted it directly from database. database> node_type > delete the content type you want to delete. Sometimes you can't delete the content type from here, delete from inside inline edit. It worked for me. dont forget to clear cache. configuration > performance > clear cache.

Thank you to henrydennis.

This worked for me.

Although there is no delete link on the content types page, the path to the delete page is apparently still valid. So you just have to construct the URL yourself.

-Dave

#103 worked for me as well after disabling the feature!
used features-version: 7.x-2.0-rc1

@hefox, I was almost changing this issue's version to 7.0-2.x-dev, as it seems to be the HEAD -dev version, but I saw your comment on #93. Well, I'm still not understand why not changing the version, but you are the module maintainer.

Solution suggested on #100 seems to be something that can be applied to both versions (1.x and 2.x).

Manually You can fix this issue by running following query through phpmyadmin

UPDATE node_type SET custom = 1, locked = 0;

We need an actual patch here. Perhaps when the content type is disabled we can run an SQL update query like in #107? And when content type is re-enabled, make sure it gets locked again?

@mpotter: that's what I did in #32, which fixed the issue and was applied. Apparently, subsequent code changes broke this.

Ah, right. OK, we just need a re-roll against the current code then. All of the needed hooks should be there now.

Here's the commit where this was fixed: http://drupalcode.org/project/features.git/commit/e00d7e5. I haven't looked to see what subsequent change broke this. Ideally we'd have a test along with a fix to prevent future breakage.

What changed was all of the stuff needed to create the hooks for enable, disable, etc. All of those hooks have subsequently been added. The _features_restore routine calls "pre" and "post" hooks for "revert", "rebuild", "enable", "disable". So all that is needed to this patch is the correct "pre" or "post" hooks in the features.field module for doing the db update.

Is there anything happening on this still? (new patch anyone?)

Issue summary:View changes

Putting in workaround on top to save others confusion of reading through the thread - like I was confused. Hope that helps!

#16 worked form me. Used drush sqlq. Didn't need step one as I had removed all references to the content type from the feature beforehand.

Issue summary:View changes