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

pwolanin’s picture

subscribe

pwolanin’s picture

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

drumm’s picture

Status: Active » Postponed (maintainer needs more info)

Are you saying we should check for hook_form() existing in both places or neither place?

pwolanin’s picture

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

profix898’s picture

Not 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?

pwolanin’s picture

Well, probably you could implement hook_access and deny create and edit for all users?

profix898’s picture

Status: Postponed (maintainer needs more info) » Active

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

nevets’s picture

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

profix898’s picture

Status: Active » Closed (won't fix)

@nevets: But for your purpose you could simply implement an empty hook_form().

Thinking about it, the if statement 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.

jbomb’s picture

There 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?