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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

iler’s picture

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.

knaffles’s picture

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

http://drupal.org/node/1018178

Anonymous’s picture

Subscribe

ryan.armstrong’s picture

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.

ryan.armstrong’s picture

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.

knaffles’s picture

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.

ryan.armstrong’s picture

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?

ts145nera’s picture

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.

webchuck’s picture

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

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

willvincent’s picture

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!

404’s picture

I am having the same problem. Subscribe.

hefox’s picture

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.

Moinax’s picture

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.

ckng’s picture

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?

ryan.armstrong’s picture

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

nedjo’s picture

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.
mortendk’s picture

subscribe

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

muschpusch’s picture

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

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

hefox’s picture

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).

minnur’s picture

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();
}
sk33lz’s picture

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.

RavenHursT’s picture

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..

jviitamaki’s picture

sub

mraichelson’s picture

subscribe

John Bickar’s picture

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

jacobson’s picture

+1 for #16 workaround.

sw3b’s picture

subscribe

psychobyte’s picture

sub

nedjo’s picture

logaritmisk’s picture

Subscribe

nlisgo’s picture

Subscribe

nedjo’s picture

Status: Active » Needs review
FileSize
3.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.
mwheeler’s picture

Subscribe

rogical’s picture

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

m4olivei’s picture

subscribe

mrfelton’s picture

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

nico_’s picture

subscribe

likewhoa’s picture

Subscribe

rogical’s picture

#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

Gemma Morton’s picture

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

jdleonard’s picture

subscribe

tbeauchemin’s picture

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"

fabsor’s picture

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.

hefox’s picture

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).

fabsor’s picture

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.

hefox’s picture

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.)

khiminrm’s picture

Subscribe

doubi’s picture

sub

mattbk’s picture

subscribing

e2thex’s picture

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?

nedjo’s picture

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.

febbraro’s picture

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.

hefox’s picture

(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.)

febbraro’s picture

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.

nedjo’s picture

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.

Pelegro’s picture

subs

acbramley’s picture

Sub

herve’s picture

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

febbraro’s picture

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

mwbyrd’s picture

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

febbraro’s picture

@mwbyrd That is not b/c of Features.

Dean Reilly’s picture

Subscribed

lkacenja’s picture

subs

tinefin’s picture

subscribe

tinefin’s picture

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.

micahtaylor’s picture

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.
nao’s picture

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

cainrus’s picture

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();
}
hefox’s picture

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.

MrPaulDriver’s picture

#65 solves it

thanks tinefin

Status: Fixed » Closed (fixed)

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

lsolesen’s picture

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.

radoo’s picture

Subscribe

likewhoa’s picture

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

hefox’s picture

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

delete => disable

Since disabling should never delete

coredumperror’s picture

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.

hefox’s picture

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

rameshbabu.g’s picture

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

jaloo’s picture

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

hefox’s picture

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!

mpotter’s picture

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.

nedjo’s picture

@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.

hefox’s picture

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.

ridgek’s picture

subscribe

Danny Englander’s picture

#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.

donquixote’s picture

Thanks nedjo (#16).

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

donquixote’s picture

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.

tim.plunkett’s picture

Title: Disabling a feature does not disable content type » Disabling 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.

marcinsdance’s picture

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

sumedha’s picture

Thanks... It worked.

wusel’s picture

#66:
Thanks, that works for me.

My wish:
Get it as code, please

francescjr’s picture

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.

hefox’s picture

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.

kle’s picture

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

Jazoja’s picture

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

Ivanhoe123’s picture

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


/**
 * 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();

}
El Bandito’s picture

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

;-)

brunops’s picture

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

/**
 * 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();
}
rodmaz’s picture

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

Jaesin’s picture

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));
}
jawad.shah’s picture

ref #65 works for me.

Thanks tinefin.

zeropoint.IT

reenuchahal’s picture

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.

henrydennis’s picture

cmsdave’s picture

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

lundj’s picture

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

Mac_Weber’s picture

@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).

purabdk’s picture

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

UPDATE node_type SET custom = 1, locked = 0;
mpotter’s picture

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?

nedjo’s picture

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

mpotter’s picture

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

nedjo’s picture

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.

mpotter’s picture

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.

petergus’s picture

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

petergus’s picture

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!

jduhls’s picture

#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.

Argus’s picture

Issue summary: View changes
Anybody’s picture

I can confirm that this problem still exists.

ShaneOnABike’s picture

Priority: Normal » Major

Would it not be possible just to add the code from #16 as the uninstall feature to allow items to be uninstalled. It's hard for development purposes to not be able to fully delete the content type (things get a little screwy)

Also from a usability perspective I think it makes it harder for non-programmer types to be able to use features properly :/ Especially, when a content type is deployed with major changes to field names or whatever. When they revert it doesn't always work properly, and the cleanest solution seems to be to nuke it entirely and then recreate.

nedjo’s picture

What seems to have happened in this issue is that the bug was fixed and then a subsequent patch to features broke the fix.

What's presumably needed is not a new approach, but to restore the functionality that was broken.

kingfisher64’s picture

Has any progress been made on this? Latest 2.2 branch still has this issue.

hefox’s picture

Moved the core issue back to 7 as all that has changed so drastically in d8, please review :)

asb’s picture

The problem still exists in D7; content types, vocabularies, and input formats created by a feature are not removed by uninstalling the feature; they can not be deleted throught Drupal's UI since the "Delete" buttons are disabled. However, locked content types can be deleted without working directly in the database by appending /delete after ./admin/structure/types/manage/{type}.

However, even worse is that the 'Features' module itself can not be uninstalled after some features have been installed and ununstalled. All together, this throws drupal manageability back into times of Drupal 4.x before the capability to uninstall modules was introduced.

hefox’s picture

Please see core issue

Also, if you're having other errors, please work to report and find fixes for them, (vs. derailing an existing thread). Remember, open source, community, etc.

jcovington’s picture

admin/structure/types/manage/typename/delete works for me. I'm going to try the patch, next.

Subscribing.

Leeteq’s picture

Priority: Normal » Major

Ref. @asb's comment in #121, this is "major", IMO.

hefox’s picture

Priority: Major » Normal

Again, please address this in core :'(

knowledges33ker’s picture

Until the module offers the delete link, the easiest thing to do (I think) is to use the admin_menu module (https://www.drupal.org/project/admin_menu). I already use this on most of my sites so it isn't an extra step for me.

With admin_menu enabled, you can simply hover over structure > content types > any type and the delete link will appear.

I just tested this out by moving a content type and a view from one site to another via features. Disabled the feature but the content type was still there with no delete link. Used the admin menu to delete the content type. Worked fine.

  • febbraro committed e00d7e5 on 8.x-3.x
    Issue #1055460 by nedjo, hefox, fabsor, others...: Disabling a feature...
David_Rothstein’s picture

Version: 7.x-1.x-dev » 8.x-3.x-dev
Status: Postponed » Needs review
FileSize
1.95 KB

I committed #1441950: Node types removed from hook_node_info with base = 'node_content' cannot be deleted to Drupal 7 last week and included it in the 7.36 release, so the current behavior should now be that disabling the feature module disables the content type that it provides. However, based on #2465159: 7.36 (Issue #1441950) May Cause Node Types to be disabled this is now causing problems for people also... I am not sure what the expected behavior here is.

In any case, it looks like this issue is still open because #32 was committed, but then stopped working somewhere along the way. Here's a patch that seems to get it working again. With this patch applied and testing with Drupal 7.36, disabling the feature module now disowns the content type rather than disabling it (it remains in the user interface but gets a delete link next to it). The delete link is removed if the module is enabled again. This behavior does seem closer to me to the way Features normally handles configuration that Drupal stores in the database by default.

The patch is slightly buggy in the case of a content type that was originally created in the user interface via the Node module but then added to a feature later (e.g. the default Article or Basic Page content types provided by the standard install profile, if you add them to a feature post-installation). Disabling and reenabling the feature essentially causes the content type to be completely taken over by Features, whereas it previously wasn't. But I think that's pretty minor.

David_Rothstein’s picture

Version: 8.x-3.x-dev » 7.x-2.x-dev

Oops, finger slipped - wrong version.

Status: Needs review » Needs work

The last submitted patch, 128: features-disable-content-type-1055460-128.patch, failed testing.

Status: Needs work » Needs review

The last submitted patch, 32: features_content_type_disable-1055460-32.patch, failed testing.

mpotter’s picture

Status: Needs review » Needs work

@David_Rothstein: That looks pretty reasonable. Can you re-upload the patch with the 2.x status so the tester will see it and pass it? Just changing the status caused the original patch to be tested instead of yours.

Status: Needs work » Needs review
dsnopek’s picture

I re-queued it for testing and it appears to have tested the right patch this time. So, this should be ready for a proper review!

mpotter’s picture

Status: Needs review » Reviewed & tested by the community

Thanks for all the help on this issue while I've been in D8-land. Will get this committed and released later today.

mpotter’s picture

Status: Reviewed & tested by the community » Fixed

Committed to c13a3f3.

kingfisher64’s picture

Having tried the latest stable version with 7.36 the relevant content type once a feature is disabled is still showing up.

Have I understood incorrectly that "disowning" is meant to be the same as "removing or deleting"? Or is it a case of the user having to delete the content type after the feature has been disabled.

Thanks

kingfisher64’s picture

Any other confirmation of this?

dsnopek’s picture

Have I understood incorrectly that "disowning" is meant to be the same as "removing or deleting"?

"Disowning" is not the same as "removing or deleting". Each content type has an "owner" which is the module responsible for it. When creating a content type with Features, it's the Features module that contains it. The goal of this issue is to change the owner to the node module when the Feature is disabled, so that the user can delete it if they want but it doesn't actually delete it automatically.

kingfisher64’s picture

@dsnopek - thanks that clarifies things.

Status: Fixed » Closed (fixed)

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

zet’s picture

Do not use db_query for INSERT, UPDATE, or DELETE queries.
Those should be handled via db_insert(), db_update() and db_delete() respectively.
( http://api.drupal.org/api/drupal/includes%21database%21database.inc‌​/ )