Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
#128 | features-disable-content-type-1055460-128.patch | 1.95 KB | David_Rothstein |
#32 | features_content_type_disable-1055460-32.patch | 3.57 KB | nedjo |
Comments
Comment #1
iler CreditAttribution: iler commentedHaving 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.
Comment #2
knaffles CreditAttribution: knaffles commentedThere's a patch for your issue with not being able to see the imported feature:
http://drupal.org/node/1018178
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedSubscribe
Comment #4
ryan.armstrong CreditAttribution: ryan.armstrong commentedI'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.
Comment #5
ryan.armstrong CreditAttribution: ryan.armstrong commentedUpdate: 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.
Comment #6
knaffles CreditAttribution: knaffles commentedI 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.
Comment #7
ryan.armstrong CreditAttribution: ryan.armstrong commentedAh 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?
Comment #8
ts145nera CreditAttribution: ts145nera commentedHi,
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.
Comment #9
webchuck CreditAttribution: webchuck commentedSeeing the same issue on beta1. Any solution for this?
Comment #10
willvincent CreditAttribution: willvincent commentedAlso 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!
Comment #11
404 CreditAttribution: 404 commentedI am having the same problem. Subscribe.
Comment #12
hefox CreditAttribution: hefox commentedUnless 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.
Comment #13
Moinax CreditAttribution: Moinax commentedHow 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.
Comment #14
ckngStuck 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?
Comment #15
ryan.armstrong CreditAttribution: ryan.armstrong commentedAs of now I think you just have to do it manually unfortunately.
Comment #16
nedjoTo manually delete a content type that was created by a feature:
mysql> UPDATE node_type SET module = 'node', custom = 1, modified = 1, locked = 0 WHERE type = 'mytype';
Comment #17
mortendk CreditAttribution: mortendk commentedsubscribe
this bug makes it a bit strange to use feaures to export content types :/
Comment #18
muschpusch CreditAttribution: muschpusch commentedthis bug is still in beta2 changing version tag and secretly subscribing...
Comment #19
hefox CreditAttribution: hefox commentedUpdate: 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).
Comment #20
minnur CreditAttribution: minnur commentedDruapl 7. I use this code to prevent adding content for disabled feature/content type (place this code into *.module file):
Comment #21
sk33lz CreditAttribution: sk33lz commentedI 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.
Comment #22
RavenHursT CreditAttribution: RavenHursT commentedThis 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..
Comment #23
jviitamaki CreditAttribution: jviitamaki commentedsub
Comment #24
mraichelson CreditAttribution: mraichelson commentedsubscribe
Comment #25
John Bickar CreditAttribution: John Bickar commentedConfirming that #16 works as a workaround (and secretly subscribing).
Comment #26
jacobson CreditAttribution: jacobson commented+1 for #16 workaround.
Comment #27
sw3b CreditAttribution: sw3b commentedsubscribe
Comment #28
psychobyte CreditAttribution: psychobyte commentedsub
Comment #29
nedjoOpened #1169884: Define what should happen to a feature's components when a feature is disabled to address the general issue here.
Comment #30
logaritmisk CreditAttribution: logaritmisk commentedSubscribe
Comment #31
nlisgo CreditAttribution: nlisgo commentedSubscribe
Comment #32
nedjoAttached patch:
Comment #33
mwheeler CreditAttribution: mwheeler commentedSubscribe
Comment #34
rogical CreditAttribution: rogical commented#32 the content type still won't be deleted automatically,
just can be deleted manually.Comment #35
m4oliveisubscribe
Comment #36
mrfelton CreditAttribution: mrfelton commentedApproach in #16 worked for me as a workaround. Thanks.
Comment #37
nico_ CreditAttribution: nico_ commentedsubscribe
Comment #38
likewhoa CreditAttribution: likewhoa commentedSubscribe
Comment #39
rogical CreditAttribution: rogical commented#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
Comment #40
Gemma Morton CreditAttribution: Gemma Morton commentedI can confirm that #32 works for me as well.
Comment #41
jdleonardsubscribe
Comment #42
tbeauchemin CreditAttribution: tbeauchemin commentedsuscribing
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"
Comment #43
fabsor CreditAttribution: fabsor commentedI 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.
Comment #44
hefox CreditAttribution: hefox commentedThe 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).
Comment #45
fabsor CreditAttribution: fabsor commentedI 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.
Comment #46
hefox CreditAttribution: hefox commentedahh, 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.)
Comment #47
khiminrm CreditAttribution: khiminrm commentedSubscribe
Comment #48
doubi CreditAttribution: doubi commentedsub
Comment #49
mattbk CreditAttribution: mattbk commentedsubscribing
Comment #50
e2thex CreditAttribution: e2thex commentedSo 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?
Comment #51
nedjoGood 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.
Comment #52
febbraro CreditAttribution: febbraro commentedI'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.
Comment #53
hefox CreditAttribution: hefox commented(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.)
Comment #54
febbraro CreditAttribution: febbraro commentedSo 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.
Comment #55
nedjoThanks! 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.
Comment #56
Pelegro CreditAttribution: Pelegro commentedsubs
Comment #57
acbramley CreditAttribution: acbramley commentedSub
Comment #58
herve CreditAttribution: herve commentedSubscribe.
At the moment, which version of features included this bug fix please?
Comment #59
febbraro CreditAttribution: febbraro commented@herve right now only a dev version but I think we will be rolling a new release in a day or so.
Comment #60
mwbyrd CreditAttribution: mwbyrd commentedThis 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
Comment #61
febbraro CreditAttribution: febbraro commented@mwbyrd That is not b/c of Features.
Comment #62
Dean Reilly CreditAttribution: Dean Reilly commentedSubscribed
Comment #63
lkacenjasubs
Comment #64
tinefin CreditAttribution: tinefin commentedsubscribe
Comment #65
tinefin CreditAttribution: tinefin commentedYou 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.
Comment #66
micahtaylor CreditAttribution: micahtaylor commentedI also was able to delete it with the following steps:
Comment #67
nao CreditAttribution: nao commentedThanks! micahtaylor your step by step was a successful!!
Comment #68
cainrus CreditAttribution: cainrus commentedneed to be backport for D6
Now i need to use custom code:
Comment #69
hefox CreditAttribution: hefox commentedI 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.
Comment #70
MrPaulDriver CreditAttribution: MrPaulDriver commented#65 solves it
thanks tinefin
Comment #72
lsolesen CreditAttribution: lsolesen commentedI am still seing this issue in 7.x-1.0-beta6.
Comment #73
radoo CreditAttribution: radoo commentedSubscribe
Comment #74
likewhoa CreditAttribution: likewhoa commented@radoo stop subscribing and start following. see the green button at the top of all issues you wish to follow/subscribe to.
Comment #75
hefox CreditAttribution: hefox commenteddelete => disable
Since disabling should never delete
Comment #76
coredumperror CreditAttribution: coredumperror commentedLike #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.
Comment #77
hefox CreditAttribution: hefox commentedHow 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
Comment #78
rameshbabu.g CreditAttribution: rameshbabu.g commentedThanq nedjo.,It works fine for me.,Great....
Comment #79
jaloo CreditAttribution: jaloo commented#66 it works, thanks. "content_type_I_want_to_delete" needs machine name, like "features_test".
Comment #80
hefox CreditAttribution: hefox commentedI'm marking this postponed since it a core bug. Please, please test the core patch else it'll just not get fixed!
Comment #81
mpotter CreditAttribution: mpotter commentedRe-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.
Comment #82
nedjo@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) debugnode_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.
Comment #83
hefox CreditAttribution: hefox commentedFixing 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.
Comment #84
ridgek CreditAttribution: ridgek commentedsubscribe
Comment #85
Danny Englander#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.Comment #86
donquixote CreditAttribution: donquixote commentedThanks nedjo (#16).
Not having a clearly defined behavior for disabling a feature does make this module feel incomplete.
Comment #87
donquixote CreditAttribution: donquixote commentedOk, 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.
Comment #88
tim.plunkettThe 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.
Comment #89
marcinsdance CreditAttribution: marcinsdance commented#65 and #66 worked for in my case. thanks!
Comment #90
sumedha CreditAttribution: sumedha commentedThanks... It worked.
Comment #91
wusel CreditAttribution: wusel commented#66:
Thanks, that works for me.
My wish:
Get it as code, please
Comment #92
francescjr CreditAttribution: francescjr commentedStill 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.
Comment #93
hefox CreditAttribution: hefox commentedtraveaoist: 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.
Comment #94
kle CreditAttribution: kle commentedworkaround: add a delete at the end of the URL.
like: admin/structure/types/manage/testtype/delete
Works fine for me.
Comment #95
Jazoja CreditAttribution: Jazoja commentedWorks for me too.
I'd push the LIKE button if there was one...:-)
Comment #96
Ivanhoe123 CreditAttribution: Ivanhoe123 commentedThis can also be solved through a FEATURE_NAME.install file:
Comment #97
El Bandito CreditAttribution: El Bandito commentedIf you use admin menu it still presents the delete links, even if the admin page doesn't.
;-)
Comment #98
brunops CreditAttribution: brunops commentedFound another way to force content type deletion by following whats inside content_type.inc, that is:
Comment #99
rodmaz CreditAttribution: rodmaz commentedThis does not delete fields created by the module and used in the content type, does it?
Comment #100
Jaesin CreditAttribution: Jaesin commentedThis works for me:
In the MY_FEATURE.install file:
Comment #101
jawad.shah CreditAttribution: jawad.shah commentedref #65 works for me.
Thanks tinefin.
zeropoint.IT
Comment #102
reenuchahal CreditAttribution: reenuchahal commentedI 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.
Comment #103
henrydennis CreditAttribution: henrydennis commentedI suggest trying http://example.com/?q=admin/structure/types/manage/MODULE_ID/delete, it worked fine for me.
Comment #104
cmsdave CreditAttribution: cmsdave commentedThank 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
Comment #105
lundj CreditAttribution: lundj commented#103 worked for me as well after disabling the feature!
used features-version: 7.x-2.0-rc1
Comment #106
Mac_Weber CreditAttribution: Mac_Weber commented@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).
Comment #107
purabdk CreditAttribution: purabdk commentedManually You can fix this issue by running following query through phpmyadmin
Comment #108
mpotter CreditAttribution: mpotter commentedWe 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?
Comment #109
nedjo@mpotter: that's what I did in #32, which fixed the issue and was applied. Apparently, subsequent code changes broke this.
Comment #110
mpotter CreditAttribution: mpotter commentedAh, right. OK, we just need a re-roll against the current code then. All of the needed hooks should be there now.
Comment #111
nedjoHere'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.
Comment #112
mpotter CreditAttribution: mpotter commentedWhat 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.
Comment #113
petergus CreditAttribution: petergus commentedIs there anything happening on this still? (new patch anyone?)
Comment #113.0
petergus CreditAttribution: petergus commentedPutting in workaround on top to save others confusion of reading through the thread - like I was confused. Hope that helps!
Comment #114
jduhls CreditAttribution: jduhls commented#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.Comment #115
Argus CreditAttribution: Argus commentedComment #116
AnybodyI can confirm that this problem still exists.
Comment #117
ShaneOnABike CreditAttribution: ShaneOnABike commentedWould 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.
Comment #118
nedjoWhat 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.
Comment #119
kingfisher64 CreditAttribution: kingfisher64 commentedHas any progress been made on this? Latest 2.2 branch still has this issue.
Comment #120
hefox CreditAttribution: hefox commentedMoved the core issue back to 7 as all that has changed so drastically in d8, please review :)
Comment #121
asb CreditAttribution: asb commentedThe 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.
Comment #122
hefox CreditAttribution: hefox commentedPlease 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.
Comment #123
jcovington CreditAttribution: jcovington commentedadmin/structure/types/manage/typename/delete works for me. I'm going to try the patch, next.
Subscribing.
Comment #124
Leeteq CreditAttribution: Leeteq commentedRef. @asb's comment in #121, this is "major", IMO.
Comment #125
hefox CreditAttribution: hefox commentedAgain, please address this in core :'(
Comment #126
knowledges33ker CreditAttribution: knowledges33ker commentedUntil 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.
Comment #128
David_Rothstein CreditAttribution: David_Rothstein commentedI 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.
Comment #129
David_Rothstein CreditAttribution: David_Rothstein commentedOops, finger slipped - wrong version.
Comment #133
mpotter CreditAttribution: mpotter commented@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.
Comment #135
dsnopekI 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!
Comment #136
mpotter CreditAttribution: mpotter commentedThanks for all the help on this issue while I've been in D8-land. Will get this committed and released later today.
Comment #137
mpotter CreditAttribution: mpotter commentedCommitted to c13a3f3.
Comment #139
kingfisher64 CreditAttribution: kingfisher64 commentedHaving 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
Comment #140
kingfisher64 CreditAttribution: kingfisher64 commentedAny other confirmation of this?
Comment #141
dsnopek"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.
Comment #142
kingfisher64 CreditAttribution: kingfisher64 commented@dsnopek - thanks that clarifies things.
Comment #144
zet CreditAttribution: zet commentedDo 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/ )