Some modules require more information to review than will appear in the teaser. These modules can declare a hook_modr8_preview($node) function, the results of which will be placed above the node teaser in the modr8 display.

I wrote this as I found myself continually having to open the node to check for proper geocoding for some of the node types on my site. The result of the geocoding (a valid lat/lon) does not belong in the teaser, but having it in the modr8 display when processing approvals was necessary.

CommentFileSizeAuthor
#9 specialzed_teaser_47_4.patch1.26 KBpwolanin
#8 specialzed_teaser_3.diff1.5 KBpwolanin
#4 specialzed_teaser_2.diff707 bytespwolanin
modr8_optional_data_on_node_preview.patch1007 bytesscott.mclewin

Comments

pwolanin’s picture

pwolanin commented
Status: Reviewed & tested by the community » Needs work

This is a good idea, but I'm not sure this is the best implementation. What if my module adds extra information to a variety of node types, but doesn't define any of them? I'd think this should either be a invoking only hook_nodeapi, or at least invoking it in addition to invoking this new hook.

scott.mclewin’s picture

scott.mclewin commented

Rather than expand the cases in nodeapi, how about making this a module_invoke_all call rather than invoking it back on the data type? If you nod your virtual head I'll make that change.

pwolanin’s picture

pwolanin commented

Sure, that's probably cleaner and more efficient in any case.

pwolanin’s picture

pwolanin commented
Status: Needs work » Needs review
StatusFileSize
new specialzed_teaser_2.diff707 bytes

How about something like the attached patch? Your module could look for the flag in hook_nodeapi('view') or hook_view. this way the new content gets properly rendered. I guess another option is that to add the flag and then within modr8_nodeapi('view') to do the module_invoke_all.

pwolanin’s picture

pwolanin commented
Version: 4.7.x-1.x-dev » 6.x-1.x-dev

sorry, patch is for 5.x/HEAD

scott.mclewin’s picture

scott.mclewin commented

That's nice and clean. When I move my main site up to 5.0 I'll use this mechanism.

pwolanin’s picture

pwolanin commented

Probably I should add to this patch a check by Modr8 itself so that the moderation message is not added when viewing the moderation page.

pwolanin’s picture

pwolanin commented
Status: Needs review » Patch (to be ported)
StatusFileSize
new specialzed_teaser_3.diff1.5 KB

better patch attached- and committed to 5.x/HEAD. if you can take 5 minute to backport to 4.7.x, I'll commit that too.

pwolanin’s picture

pwolanin commented
StatusFileSize
new specialzed_teaser_47_4.patch1.26 KB

attached patch is a backport for 4.7, and committed to 4.7 branch

pwolanin’s picture

pwolanin commented
Status: Patch (to be ported) » Fixed
scott.mclewin’s picture

scott.mclewin commented

Thanks Peter. I'm still reeling from newborn-baby lack of sleep. My 'playtime' with Drupal has dropped to an hour every few days. I had intended to port this for you. I have a backlog of changes to production sites that I'll work through, then I'll redo the modr8 patches from December to add the 'resubmit' functionality and some of the other mods. Is it OK if this happens against 4.7? I'm not up to 5 yet and won't be for many months.

pwolanin’s picture

pwolanin commented
Status: Fixed » Closed (fixed)
scott.mclewin’s picture

scott.mclewin commented

On the off chance you ever see this note on a closed issue - this solution works out just fine and is cleaner than the original approach I took. Thanks. (now that the baby is eight months old I have time for Drupal and D5 again!)