I am trying to use the native Image content type rather than a custom type using CCK image fields. In my view, I am selecting out the correct images ( uses node references to get the images for a node id ). If I turn off the cycle block setting my images load correctly into the page. When I turn on the Cycle block option, the images disappear. This pointed me at my preprocessor functions. My assumption being that the preprocessor was not grabbing he correct data for the image tag.
When I turn on the debug data, it only shows the fields for nid, node_type, and the revision info:
stdClass::__set_state(array(
'nid' => '104',
'node_title' => 'Another Image',
'node_type' => 'image',
'node_revisions_teaser' => '',
'node_revisions_format' => '0',
))
Judging from this I know that my preprocess function is not even getting a referencable image in the array its using for the results. However, when cycle block is turned off... the images show fine.
My question is why isn't the cycle block passing a reference to the image?
I figure to get around this I can just add some logic in the preprocessor to grab stuff from the DB when the nodetype is image using the node id as a key, but I'm more interested in understanding how I can get the fields passed through proper inheritance.
Thanks,
-jj
Comments
Comment #1
JJustian132 commentedWas thinking the solution is probably to change the query in the preprocessor _cycle_block_content function to join against the node table.
Do the developers suggest this or is this bad?
Thanks,
-jj
Comment #2
JJustian132 commentedI ran this as my db linbe in the preprocessor for content:
$filepath = db_result(db_query("SELECT filepath FROM files left JOIN image ON image.fid=files.fid WHERE image.nid =%d AND image.image_size in ('_original','_preview') ORDER BY image.image_size DESC LIMIT 0 , 1", $result->nid));
The correct images come up now. However, in the interest of knowledgebasing... I have a question and I see an issue with this technique.
Issue:
I have to code in logic in the query to bring the correct image size up and from which set images may come from which makes it less portable.
Question:
Is there a better way to do this in keeping with 'best practices' for this kind of need. I think this is a somewhat elegant technique aside from the codebased solution, but I am relatively inexperienced with the Drupal framework and am guessing there is a more sustainable/scalable technique using established themeing techniques such as the theme API or other widely used technique.
Thanks,
-jj
Comment #3
JJustian132 commentedYeah, I see why this is bad... pager is busted
Comment #4
ppblaauw commentedDid not look much into this option to use the image module directly.
When you use the code you have, to get the image, you should use the same code in the pager preprocess function to get the images for the pager.
Maybe there are some theme functions in the image module which can be used, didn't look at that yet, but wanted to react on your statement pager is busted.
When I have some more time will have a look at this option.
Comment #5
JJustian132 commentedThats actually what I ended up doing, but I found another oddity when I did that. Seems if I only have one result, the DDblock doesn't activate. The source shows that all tags get outputted from the custom template file for the ddblock, and in the case of upright-50, the image based pager works fine but for some reason the initial image won't load.
I tried my best looking in the ddblock javascript for someplace that may have a failure if the result set is not > 1 but didn't see anything glaring. The second I add another image back... boom, the ddblock works like a charm. I can't find any bug reference on the jquery cycle plugin topics, nor in here.
I'm going to post this issue separately as well.
Thanks,
-jj
Comment #6
ppblaauw commented#5 The jquery cycle plugin, which is used in the ddblock module needs at least two slides to work.
Comment #7
JJustian132 commentedLOL, thanks. Do you know of anyway around that?
Comment #8
ppblaauw commentedset status to fixed