[development] NodeAPI Broken-ness, possible solutions
jeff at viapositiva.net
Sat Sep 9 16:39:09 UTC 2006
In Drupal 5.0, hook_view() and nodeapi 'view' operations now stick
elements into the $node->content array, and it's rendered for output.
That open up a lot of doors for theming and customization, and also
moves us closer to a clean centralized 'rendering API' for on screen
However, some modules need to do more than just add or rearrange
elements, though. They need to modify *the complete text of the node*
after it's fully rendered. In the case of upload.module, for example, we
do path substitution to make sure that things work when clean URLs are
In 4.7 and earlier, this was easy because ALL view-time work involved
altering the raw node body. In 5.0, though, this requires adding a
callback to $node->content['#after_render']. When drupal_render parses
the array to render it, it will call the functions listed in that
element, giving them a chance to alter the final text.
Shortly after the code freeze, however, I realized that this was
insufficient for some modules, and broke functionality that worked fine
in 4.7. Why?
1) Because they're called inside drupal_render(), the #after_render
callback functions don't get any context. They don't have a copy of the
$node object (which some modules need to do substitutions properly).
2) In addition, they don't know whether the node is displaying in teaser
mode, whether it's in full page mode, etc.
3) Code that needs to output just a small chunk of the node (in a
sidebar block, for example) loses any filtering done by modules like
inline or upload. Since the #after_build element is only processed when
the node is rendered *as a whole*.
Taken together, these problems cripple a couple of critical Drupal
modules and rob us of many of the promised benefits of the new node
rendering system. http://drupal.org/node/82045 has a patch that I posted
in an attempt to solve this problem a day or so after the code freeze.
It is potentially controversial, as it adds a new hook after the code
freeze (though it doesn't change any existing ones).
It's a somewhat subtle and complex issue, but I'd very much appreciate
any thoughts others would be willing to contribute. I'm hoping that we
can figure out an elegant solution to this before any of the badly
affected modules need to be ported.
More information about the development