I'm looking at ln 866 in hotblocks.module where node_view() is invoked and it seems there's no way to tell the node to be a teaser:
Perhaps there could be a setting in the hotblocks setting page that would allow you to pass in the teaser argument into node_view -- just a thought.
I see that this module also creates a content type -- I suppose it was your intention to use that content type as a pointer to other content... like create a hotblock node to point to other nodes, and skip the need for the teaser on the output..
One thing that might be cool (and would take a lot of refactoring...) is to integrate views and replace the calls to hotblock_item_view() in hotblocks_view_block() with a call to views:
$sHotblocks = '';
foreach ($aHotblocks as $oHotblocks_Item) {
$sHotblocks .= hotblocks_item_view($oHotblocks_Item, $iDelta);
}
to
$sHotblocks = '';
//build a list of nids to pass to views
$list_of_hotblock_nids = array();
foreach ($aHotblocks as $oHotblocks_Item) {
$list_of_hotblock_nids[] = $oHotblocks_Item->nid;
}
$args = implode("+",$list_of_hotblock_nids);
$sHotblocks = views_embed_view("user_designated_view", $args);
then the user could designate a view, which of course would have to accept multiple node nids separated with + as an argument (views does support this, and i think there might be a way to install a default view on install of the module)
You could even use http://drupal.org/project/views_arguments_extras to handle your sorting..
The advantage to such an integration would be that the super user could configure the output of each node in the views UI, which could be pretty cool.
Anyway.. just some thoughts.. there's plenty to work with here to not require such integration with views, but it's just a thought
Oh and of course that would only work if all of the items are nodes..... hmmmm
Comments
Comment #1
tmsimont commentedcrap i don't think this module does create a hotblock content type i just made that up. i think i created that content type a while back...
Comment #2
tmsimont commentedA simpler way to allow more customized output of nodes than trying to factor in views might be to simply create a theme function, which would allow an override of the node's output in template.php.
For example:
to
that would then require a new form registration in hook_theme()
another idea might be to simply flag the node before passing it into node_view, so that way another module can hook into the nodeapi and recognize that the node is being rendered for the hotblock region:
I might implement some of these ideas and put up a patch -- I'm trying to get this built to a set specification ASAP, so I might just work around this and do something else like a pointer content type with a nodereference field...
Comment #3
tmsimont commentedthe more i look at this the less possible using a view seems to be...
Comment #4
justindodge commentedHi tmsimont, thanks for your thoughts on the matter.
I agree with your comment at #3 that views does not seem like the most appropriate means of achieving this.
Allow me to point out one thing that I believe you may have missed, which is that in hotblocks_nodeapi hook, the loaded node is flagged with a little indicator that it is a hotblock item. To be clear, it does not indicate the context in which the node is being viewed, but it may be of some use.
I do think that adding some sort of flag to the node object that indicates it is going to be viewed in the context of hotblocks is a good idea in general.
I also agree that a theme function could be very effective.
Personally however, I think a good solution would be to give hotblocks its own CCK build mode. Would this accommodate your use case?
Comment #5
tmsimont commentedI saw that in there, but the problem with that is there's no distinction to CCK that the $oNode->is_hotblocks_item means that the node is being loaded into a hotblock region. it's being flagged in nodeapi without checking to see who's calling on the node to load (which i don't think is even possible in hook_nodeapi() )
so.. that flag is put there regardless of who is calling node_load -- that's why i was thinking you could flag it before you call node_view in hotblocks_item_view(). I'm pretty sure if you did, then the flag would end up in the "view" op of the nodeapi function.
i'm not sure what you mean by cck build mode... sounds cool tho. do you mean like a mode you can configure "display fields" on the content type UI? that could be really handy, would that mode be usable in the theme level? like in the node-whatever.tpl.php or in the node_preprocess function for template.php ?
Comment #6
justindodge commentedYes I believe you must have missed my explanation of the very thing you reiterate in #5, but at any rate, we are in accords.
You see a list of CCK build modes when you go to the display fields section, I see "basic" and "rss" for myself at the moment.
Adding a "hotblocks" build mode would then give you a separate page to choose the formatters for each of the fields, hide the field labels, etc. This also gives you access on the theme level, I'm not sure the syntax exactly but yeah, something like node-hotblocks.tpl.php.
This is a very simple thing to implement and I think it's a good idea, so if it works for you I will write it in.
Comment #7
justindodge commentedSo I have added the build mode, called "hotblocks" which you could find by going to admin/content/node-type/page/display, where "page" is the node type in question, of course.
This also has the advantage of flagging the node object with $node->build_mode = 'hotblocks' directly prior to viewing, should any other code want to know if a node is being rendered in the context of a hotblock.
As a side note, I have discovered that the settings for the display of a field's label on the 'basic' build mode will affect every other build mode by default. Modules like Display Suite have solutions for more granular configurations.
I have also discovered that there is no template suggestions provided by default for build modes, so I have offered my own. First will be 'node.tpl.php' and any variants that the system provides. Of course using these will affect the display of the node in all cases. Next is 'hotblocks-node.tpl.php', specifically for the hotblocks build mode, followed by 'hotblocks-node-nodetype-tpl.php', for specific content types. I am open to changes in the namespace if this seems counter-intuitive to themers.
I would be very happy if you were able to test this out and provide feedback.
The code is committed to dev, though you may need get it directly from git since the snapshots come out every 12 hours or whatever.
Comment #8
echoz commentedYour module listing is not getting a dev version posted on the project page, up to commits from 2 days ago.
Comment #9
justindodge commentedOops, they should be coming again now. I'm not sure when the next snapshot will be created, you can always checkout the code with git in the meantime if you're in a hurry.
Comment #10
tmsimont commentedhey i'm sorry i think i might have to come back to this another time -- i went with the "pointer" method i briefly touched on before... i just created a "quicklink" content type and set it up with a node reference field so i can use that in sidebars to let client admins point to content independently from what exactly that content contains... not as cool as it could be but it gets the job done. i'll definitely use this in the near future, and will test/comment.
thanks!
Comment #11
justindodge commentedFunctionality as described in #7 has been committed and is in 6.x-1.7 official release.
Comment #12.0
(not verified) commentedafterthoughts