Multiple node types are broken

+1

Except on third example surely their shouldn't be spaces in 'node type c' as surely that won't work?

Just to make it clear to people: this patch enables a module, such as project.module, to define more than one node type, using different hooks for each of those node types within the same module. Otherwise, functions would have to be shared between the node types defined by the function, or a different module would be needed for each node type. Neither of which are desirable.

Currently gives warnings such as:

Warning: Missing argument 1 for page_node_name() in ...something.module on line x

Perhaps add argument $null = '' or something similar for backwards compatability as e.g. page.module calls as thus:

function page_node_name($node) {
  return t('page');
}

... so we need the $node argument to be allowed, even if its totally pointless.

question: would this functionality allow us to get rid of page and story node types in favor of a similar module that can be called whatever you want to call it?

Instead of

function hook_node_types() {
  return array('page');
} 

we could have

function hook_node_types() {
  return array(variable_get('user_defined_nodes', array('page', 'story'));
} 

This would let us get rid of these two identical (yes, do a diff on them, they're identical now) modules and let people start defining all the module names that should be attributed to the title+body paradigm.

chx - get what I'm saying? How would your patch support this?

the second example should be this:

function hook_node_types() {
  return variable_get('user_defined_nodes', array('page', 'story'));
}

Robert:

I think that would be possible with chx's changes and code:

function simplenode_node_name() {
  return array('page' => t('page'),'story' => t('story'));
}

function simplenode_base_name() {
  return array('page' => 'simplenode','story' => 'simplenode');
}

... renaming page.module or story.module simplenode.module instead. Then the one module can deal with two identical nodes but giving them different names.

hook_base_name should maybe be hook_node_base_name instead.

in theory chx whenever the word 'page' or 'story' is mentioned you could use node_get_module_name instead.

and in the seldom places they do deviate other than simply the word page/story, then you can have a switch statement based on node_get_module_name

maybe i've missed a whole chunk of discussion re. simple node types etc in the past though

In node_list():

      else {
        $types[$module] = array($value, $module);
      }

I think should be ($node_names is a string here):

      else {
        $types[$module] = $node_names;
      }

As I'm getting a few errors as a array is being passed to other functions instead of a string.

I've now got a working project module against HEAD, with this in project.module and chx's patch

function project_node_name() {
  return array('project_project' => 'project',
               'project_issue' => 'issue');
}

function project_base_name() {
  return array('project_project' => 'project_project',
               'project_issue' => 'project_issue');
}

My comments were against node_basename_1.patch, with that node/add fails to show any content types.

A couple of bugs:
In theme.inc there is a node_list()

@@ -232,7 +232,7 @@
   );

   if (module_exist('node')) {
-    foreach (node_list() as $type) {
+    foreach (node_get_types() as $type) {
       $defaults['toggle_node_info_' . $type] = 1;
     }
   }

In node.module, a node_name hook is still called

@@ -1403,15 +1409,15 @@
       }
     }
     $output = node_form($node);
-    drupal_set_title(t('Submit %name', array('%name' => node_invoke($node, 'node_name'))));
+    drupal_set_title(t('Submit %name', array('%name' => node_get_name($node))));
   }
   else {

If _node_names() is called with a non-existing node-type, it returns the last node-type
in the list because the "foreach ($node_names as $type => $value)" is overwriting the $type
derived from $node a couple of lines above.

This patch no longer applies. Is it still needed? I believe this has been taken care of.