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