Closed (fixed)
Project:
Features
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
16 Jul 2009 at 19:32 UTC
Updated:
26 Sep 2009 at 15:20 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
Anonymous (not verified) commentedI think the issue is that node types generated through enabling of the Feature are not considered 'custom'.. note that this bug occurs even when the feature is enabled and the node type is created (as opposed to the idea that it's just when one disables the feature that the Delete button disappears)
The magic around what node types have the 'Delete' link seems to happen around line 31 of content_types.inc in the node module in Drupal 6.13
(as a test removing this check forces the 'Delete' link to appear on the Feature-generated node)
How to set the node type as 'custom' is beyond me, I am trying to work out how to export that as a parameter where the node type is defined in the 'module' that Features generates. Hopefully these are some clues for the developers.
Comment #2
Anonymous (not verified) commentedFound a solution
Edit your $feature.defaults.inc, find the implementation of hook_node_info
Add an attribute to the array 'custom' => '1'
i.e:
I then installed this feature on a new test site (could've just reinstalled the feature on the same site I spose, but I wanted to test on a completely fresh db where the node type didn't already exist etc) and the 'Delete' button appears.
Hope it helps
Comment #3
Anonymous (not verified) commentedHere's a patch for HEAD that works for me.
Hope it's ok (it's the first patch I've ever submitted :) )
Comment #4
Anonymous (not verified) commentedI guess it doesn't address the issue's title of the node type not being removed when the feature is disabled. Maybe this should be two separate issues.
Comment #5
yhahn commentedSo some sleuthing reveals that the node module has some special logic for node types with
nodeas the value for their module key:The fix I'd like to try out is to delegate the hooks provided by the node module for custom content types to the features module for any node types provided by features (see
node_content_access(),node_perm()andnode_content_form.I've attached a patch that does just this - the key change is that any exported content types now use
'features'instead of'node'in their module key. You can update your features using drush or the UI, or if you want to do it by hand do this:I'd love to get some testing with this before I commit the change.
Comment #6
Anonymous (not verified) commentedI might be doing something wrong.. I installed a fresh site (via Aegir), downloaded features and patched it as above, built a new feature with a simple new node type and applied this feature on another fresh site, that also had the features module patched just in case.
The implementation of hook_node_info does define the 'module' as 'features' as above,
but under Content Types on the site I deployed the new feature on, the delete option is still missing until I add 'custom' => '1' to that array and refresh.
Should I be testing this not on the latest stable but HEAD or something? Though the patch did apply cleanly.
Maybe I'm misunderstanding, if so please let me know if there's anything specific you'd like me to try - I'm very keen to help out testing and have lots of resources to do so :)
Comment #7
Anonymous (not verified) commentedHowever, disabling the feature does now remove that node type, so your fix correctly addresses this issue's title (just not the 'delete' node option that was mentioned in the body, that my patch addressed). sorry for complicating the ticket as these are really two separate issues I guess.
Comment #8
yhahn commentedYou actually shouldn't be able to delete the feature's content type unless you've overridden it (edit it and save). And if the content type is being removed when the feature is disabled, then it's working as intended : )
Comment #9
Anonymous (not verified) commentedComment #10
q0rban commentedSorry, I just realized I wasn't subscribed to the issues on this module. I'll test this out soon.
Comment #11
q0rban commentedTested, and works as described! leaving as RTBC
Comment #12
q0rban commentedThe only nice addition would be to have a hook_update_N call that actually changes what's in the node_type table... It doesn't appear that just manually changing a feature to 'module' => 'features' actually updates anything, and features UI doesn't mark it as overridden either. You either have to manually delete the node type, or edit the node_type table manually to change module to features.
Comment #13
Jackinloadup commentedsubscribing
Comment #14
a_c_m commentedran into this as well, subscribing.
Comment #15
q0rban commentedAdding an update call to fix any node types from previous features. This update can be re-run if need be.
Comment #16
yhahn commentedThanks everyone - committed: http://drupal.org/cvs?commit=261548
Comment #17
q0rban commentedJust looked at the code that was committed for this, and think I see a problem:
Line 34 of features.install
Shouldn't this be:
From my experience, if you don't wrap that in parentheses, $types will be a boolean value.
Comment #18
yhahn commentedIt's probably best practice to do so (wrap in parens) but believe it or not if the variable assignment is last in the if(), it will work (but if you switch the order $types will indeed be the boolean).
Comment #19
q0rban commentedAh, good to know! :)