Closed (won't fix)
Project:
Drupal core
Version:
6.x-dev
Component:
node system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
20 Aug 2007 at 23:17 UTC
Updated:
16 Sep 2008 at 17:38 UTC
Function node_overview_types() in content_types.inc contains the following line if (function_exists($type->module .'_form')) {...}, so that (module-defined) content types that dont implement hook_form are not listed. However all content types including those without a form are listed under node/add.
The code to prevent this was originally there, but it was removed for some reason in http://drupal.org/node/147061 (cvs log).
Comments
Comment #1
pwolanin commentedsubscribe
Comment #2
pwolanin commentedThat removal of the check for hook_form from node_menu was deliberate and necessary - hook_menu i not called on every page load, on node menu rebuild. Thus - when a module is disabled its hook_form is still in memory and that's why the content type was still being listed in the menu.
Why would a content type not have hook_form defined? Anyhow, if we need to check for this it needs to be done elsewhere.
Comment #3
drummAre you saying we should check for hook_form() existing in both places or neither place?
Comment #4
pwolanin commentedAs far as I understand the node system, hook_form must be implemented for every node type. Thus, if your module does not implement it, you have a bug in your module.
The check for hook_form was there is prevent the display of node types corresponding to disabled modules.
Comment #5
profix898 commentedNot sure it is a bug or my misunderstanding of hook_form. However in Drupal 5 it was possible to hide the edit form for certain node types by NOT implementing hook_form. This way a module was able to implement a new node type and use it internally without exposing the edit form to the user. In D6 this is no longer possible.
I'm using this to reference content of an external application from Drupal nodes. The nodes contain a title and a reference id only. On this background it doesnt make sense to let users create/modify/delete the nodes directly. Omitting hook_form make the nodes fully functional in D5, except them not being editable by users. Is there any other way to accomplish this in D6?
Comment #6
pwolanin commentedWell, probably you could implement hook_access and deny create and edit for all users?
Comment #7
profix898 commentedHmm. Probably. But hook_access doesnt apply for uid=1, so I would need to add all form fields 'read-only' (e.g. as 'value' fields) or stg. I guess there is a workaround, but it was sooo nice and easy in D5 :(
However the situation is somewhat inconsistent in the code. If this is not a feature anymore and hook_form must be implemented now, there is no need for the
if (function_exists($type->module .'_form')) {line in content_types.inc. Or am I missing something?Comment #8
nevets commentedActually there is a reason/purpose to have a module that implements a content type and no form. If you want a content type that has a given behaviour but do not care about the fields one could write a module that implements the content type, the behaviour and leave it to the user to use CCK to add the fields.
Comment #9
profix898 commented@nevets: But for your purpose you could simply implement an empty hook_form().
Thinking about it, the
ifstatement hides my content type in administration and I could use hook_menu_alter() to remove the edit tab and stuff in D6.Looking through the code it actually makes sense how it is implemented now. Its just a different solution than in D5.
Comment #10
jbomb commentedThere are some cases in which a node is generated and maintained by the system, and a hook_form implementation is not required beyond instructing a user not to use a form that they do not have access to or an empty implementation. Is there something else that is reliable enough to check against? is the node_type table reliable for preventing the display of node types corresponding to disabled modules?