[development] NodeAPI Broken-ness, possible solutions

[Jeff Eaton]

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

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

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.

--Jeff