[development] The future of hook_node_info()

Larry Garfield larry at garfieldtech.com
Thu May 21 13:57:37 UTC 2009

On Thursday 21 May 2009 7:54:03 am Arancaytar Ilyaran wrote:

> Will hook_node_info() eventually die entirely, in favor of working on
> nodes centrally handled by node.module? Should it?
> Thanks for reading all the way, :)
> -Aran

Potentially, but there are two key things that need to happen first:

1) There are still things that can only be done by a custom-defined node in its 
own module.  The most notable is hook_access(), which still must be defined by 
the declaring module if you want permissions that differ even ever so slightly 
from what node module defaults to.  That needs to get ripped out and made 
pluggable per-type, and stackable.  There has bee discussion on how to do this 
well back in Szeged, but unfortunately no one who was at that BoF has had the 
spare mental cycles to work on it. :-(  (If you want to volunteer, let me know 
and I'll try to help.)  I think there's a few others items that must be done 
by the declaring module still, but I can't recall them off the top of my head.

2) Easy programmatic creation of new nodes.  Some modules need to have custom 
behavior that comes with their nodes.  Poll is a text-book example.  For 
hook_node_info() to go away, it would need to be replaced by a *good*, *easy 
to use*, *flexible* way to declare a node type and additional behavior (eg, 
Fields) in a way that could be easily imported on module installation; 
patterns.module looks like it could be a step in that direction (I understand 
it's in the process of moving away from doing everything via drupal_execute(), 
which is good), but there are other efforts along similar lines.

If you want to kill hook_node_info(), tackle one of those problems first. :-)

Larry Garfield
larry at garfieldtech.com

More information about the development mailing list