The future of hook_node_info()
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@gmail.com AOL: 282026638 @icq / RealArancaytar @aim URL: http://ermarian.net
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@garfieldtech.com
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@garfieldtech.com>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@garfieldtech.com
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)
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
On Thu, May 21, 2009 at 5:26 PM, Daniel F. Kudwien <news@unleashedmind.com> 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
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
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@unleashedmind.com> 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
On Thu, 21 May 2009 17:26 +0200, "Daniel F. Kudwien" <news@unleashedmind.com> 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
participants (8)
-
Arancaytar Ilyaran -
Chris Johnson -
Damien Tournoud -
Daniel F. Kudwien -
David Cohen -
Derek Wright -
Larry Garfield -
Nathaniel Catchpole