The future of hook_node_info()

[Arancaytar Ilyaran]

Hey all,

This is just a bit of idle speculation (and it may even have been
discussed before) but I wanted to share my observation. There may be a
changing trend in how Drupal perceives node types.

Way back, a node type was handled by exactly one module. Most
type-specific functionality could only be applied to the native type.
For example, CCK defined "cck-clones" of all existing content types in
4.7. You need to go back as far as 4.0 (see changelog) to see
book.module adding support for non-book nodes, but that's still where we
came from.

Even in Drupal 4.7 we had story.module and page.module providing what
have since become custom content types created by the installation profile.

Between Drupal 4.7 and Drupal 5, a lot of these type-specific features
became universal. CCK stopped implementing hook_node_info and expanded
hook_nodeapi (which had only watched the 'delete revision' action
before). story.module and page.module got axed.

In Drupal 6, book.module stopped implementing hook_node_info() too, in
favor of creating a type handled by node.module, and treating all node
types the same way.

Altogether, we're down to three hook_node_info implementations in Drupal
7 (from six in Drupal 4.7), which are blog.module, forum.module and
poll.module. Coincidentally, these modules are all somewhat notorious:
forum.module's has a very frustrating visual style, poll.module has been
called our "regression test", and both poll.module and blog.module have
been considered for removal (Google "remove X from core"). Only
poll.module can still make a convincing case for using hook_node_info,
but even poll stuff could in theory be added to generic nodes.

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

--
PGP:   http://ermarian.net/downloads/0x27CA5C74
XMPP:  arancaytar.ilyaran@...
AOL:   282026638 @icq / RealArancaytar @aim
URL:   http://ermarian.net

[Larry Garfield]

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

[Nathaniel Catchpole-2]

I'd love to see it go, but Larry's explanation matches what I've been told when it's been discussed before. It'd also be worth grepping Drupal 6 contrib to see which modules are using it and how.

Nat

On Thu, May 21, 2009 at 2:57 PM, Larry Garfield <larry@...> wrote:

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

[Daniel F. Kudwien]

> 1) ... That needs to
> get ripped out and made pluggable per-type, and stackable.  

There is an initial idea/approach and patch that needs architectural review:

http://drupal.org/node/441148


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

Also note that Poll could as well provide a field only, as someone suggested
in

http://drupal.org/node/61285


I'd like to add:

3) Make Node API re-usable (like Cache API)

There are many, many, many modules in contrib that could and would very
happily use "nodes" as storage type and for processing (i.e. load,
load_multiple, view, edit, insert, update, delete, *_multiple, + being
fieldable).  But they can't, because we still have a lot of magic happening
around nodes:

- Nodes appear on admin/content/node
- Nodes appear in search results
- Nodes appear on node/add
- Aforementioned default access permissions
- Possibly more.

What we currently call and understand as "node" is clearly a node of the
type "content" in reality.

Also, considering modules for private messaging or automated feed imports
that could (re-)use Node API, {node} would quickly become a bloat of
container for everything.

So lately, I was wondering whether we could open the door to allow modules
to use the (proven) Node API design by "classifying" nodes and making its
storage re-usable, _exactly_ like we do it with cache tables already.

All cache tables share the same schema, and we can do:

cache_get('cache_form')

Considering classified nodes, a module could do:

node_load($nid, 'message');

Thoughts?

sun

[Damien Tournoud]

On Thu, May 21, 2009 at 5:26 PM, Daniel F. Kudwien
<news@...> wrote:

> 3) Make Node API re-usable (like Cache API)
>
> There are many, many, many modules in contrib that could and would very
> happily use "nodes" as storage type and for processing (i.e. load,
> load_multiple, view, edit, insert, update, delete, *_multiple, + being
> fieldable).  But they can't, because we still have a lot of magic happening
> around nodes:
>
> - Nodes appear on admin/content/node
> - Nodes appear in search results
> - Nodes appear on node/add
> - Aforementioned default access permissions
> - Possibly more.

In the "more": nodes have revisions. They have a body in the
node_revisions table.

> What we currently call and understand as "node" is clearly a node of the
> type "content" in reality.

True. Which makes it a little bit less useful.

> Also, considering modules for private messaging or automated feed imports
> that could (re-)use Node API, {node} would quickly become a bloat of
> container for everything.
>
> So lately, I was wondering whether we could open the door to allow modules
> to use the (proven) Node API design by "classifying" nodes and making its
> storage re-usable, _exactly_ like we do it with cache tables already.

What you are proposing is to implement a more generic "Drupal Object",
of which the Node as we know it would be a particular version. That
makes a lot of sense, and would allow us to also properly implement
"set based lazy-loading" one day.

Potential candidates (in core), for such an API (providing life cycle
management and field support for those objects):

 - taxonomy vocabulary
 - taxonomy terms
 - aggregator feed
 - aggregator posts
 - comments
 - url alias?
 - menus
 - menu links?
 - others?

Damien

[Derek Wright-2]

On May 21, 2009, at 7:07 AM, Nathaniel Catchpole wrote:

> It'd also be worth grepping Drupal 6 contrib to see which modules  
> are using it and how.

A few node types you're all *very* familiar with, which are handled  
via hook_node_info():

project_project
project_release
project_issue

That can't change until everything about each of these node types is  
handled by pure fields:

"convert project* to CCK"
http://drupal.org/node/85049


That's going to be a very huge task, and will require quite an upgrade  
path.  It could be started in a 6.x-2.* branch to get us closer to  
core fields in time for the D7 port, or we could just do the whole  
conversion during the D7 port itself.  I guess it depends on how  
different D6 CCK API is from D7 field API.

And yeah, all the stuff Larry said is true, too. ;)

Off the top of my head, the only reasons project* uses  
hook_node_info() are:

A) It's almost as old as Drupal itself, completely predates CCK, etc,  
and no one's ever provided resources to convert it to CCK before.

B) hook_access(), and the lack of something like an 'access' operation  
in hook_nodeapi() (there are at least two big issues in core about,  
(one now dupe with the other) both of which have stalled):

http://drupal.org/node/122173
http://drupal.org/node/143075

C) The hassle of programatically defining CCK content types and fields.


Cheers,
-Derek (dww)

[Daniel F. Kudwien]

> In the "more": nodes have revisions. They have a body in the
> node_revisions table.

Yes, and AFAIK, there is already an effort to turn node_revisions into field revisions, eliminating node_revisions.  But then again, who says that a contrib module implementing private messages (or whatever) has no use for revisions?

> What you are proposing is to implement a more generic "Drupal
> Object", of which the Node as we know it would be a
> particular version. That makes a lot of sense, and would
> allow us to also properly implement "set based lazy-loading" one day.

I'm not sure whether I would go that far.  Was rather thinking that re-using the schema of {node} along with the API for nodes would dramatically simplify a lot of contrib modules and would "automatically" introduce the flexibility and customizability of nodes. - Which also results in a much nicer DX experience, because you wouldn't have to lookup, learn, and hook into countless of node-alike implementations.

But, most probably, you are right. :)

sun

[Chris Johnson-21]

Maybe we actually need node objects AND generic, stripped-down Drupal
objects.  All of the extra "baggage" that comes along with node types
is actually sometimes very beneficial and powerful, making it much
easier to do some things.  At other times, it's completely in the way
-- hence, I've sometimes created completely new objects in my modules
without using nodes at all.

Just as a wild idea which might have some potential use -- maybe take
a look at how the file framework handles its objects
(http://drupal.org/project/fileframework).

On Thu, May 21, 2009 at 11:50 AM, Daniel F. Kudwien
<news@...> wrote:

>> In the "more": nodes have revisions. They have a body in the
>> node_revisions table.
>
> Yes, and AFAIK, there is already an effort to turn node_revisions into field revisions, eliminating node_revisions.  But then again, who says that a contrib module implementing private messages (or whatever) has no use for revisions?
>
>> What you are proposing is to implement a more generic "Drupal
>> Object", of which the Node as we know it would be a
>> particular version. That makes a lot of sense, and would
>> allow us to also properly implement "set based lazy-loading" one day.
>
> I'm not sure whether I would go that far.  Was rather thinking that re-using the schema of {node} along with the API for nodes would dramatically simplify a lot of contrib modules and would "automatically" introduce the flexibility and customizability of nodes. - Which also results in a much nicer DX experience, because you wouldn't have to lookup, learn, and hook into countless of node-alike implementations.
>
> But, most probably, you are right. :)
>
> sun
>
>

[David Cohen-8]

On Thu, 21 May 2009 17:26 +0200, "Daniel F. Kudwien"
<news@...> wrote:
>
> There are many, many, many modules in contrib that could and would very
> happily use "nodes" as storage type and for processing (i.e. load,
> load_multiple, view, edit, insert, update, delete, *_multiple, + being
> fieldable).  

Drupal for Facebook (http://drupal.org/project/fb) does just this.  It
supports any number of Facebook Apps, and any number of Feed Templates.
So for these two things it defines custom content types.  This beats
writing all the CRUD functionality all over again.  Also, additional
modules add features, and they use hook_form_alter and hook_nodeapi to
add properties to these content types.


> But they can't, because we still have a lot of magic
> happening
> around nodes:
>
> - Nodes appear on admin/content/node
> - Nodes appear in search results
> - Nodes appear on node/add
> - Aforementioned default access permissions
> - Possibly more.

None of these is a deal-breaker for my purposes.  They can even be
viewed as advantages.
I may be old-school, but I like the original content type API.  I'd hate
to see it go away.



-Dave