2

What would I need to do to pass the node id from a View Block to an associated Views Attachment for use in the filters in the Attachment View so that both operate on same content node id?

My specific example is for generating preview/teaser output from a media gallery with a certain tag:

  1. The title of the latest gallery with that tag
  2. The latest 3 thumbnails of that gallery

(I know how to build a block view to fetch thumbnails from galleries (i.e plural) that have a certain tag - my solution is here: https://drupal.stackexchange.com/a/13559/1082 I am using the Acquia Media module)

BUT what I don't know how to do is to get the title latest gallery (singular) with a certain tag followed by the latest 3 thumbnails of that gallery.

I attempted to create a block view that fetched the title of the gallery with the certain tag and I also created an view attachment to fetch the thumbnails of that gallery. But I could not work out how to pass the node id of the gallery from the block view to the attachment for it to use in its filters when fetching the thumbnails.

I tried various options including enabling the attachment to inherit arguments and filters from the block view and also contextual filters but no success so far.

Further to this, I may wish to out put more than one gallery in the teaser/preview but if I set the count to more than one on the view block I get the other gallery titles listed together followed by the thumbnails. I would want each gallery in turn to display the title followed by thumbnails that belong to it.

I would prefer to do this all withing Views i.e. not have to use PHP. I would want the solution to be as forward compatible as possible, i.e. not break with future updates - if we can stay within Views then the migration to those might be easier.

Improve this question
1

Since the attachment is linked to a specific view block, it should gain access to the information in the block. You can inform the block of the node ID by using contextual filters. 1. In the block add a contextual filter of the type content:nid. 2. Since blocks do not have paths you must explicitly tell the block to find the display node, so under form heading of "When the filter value is not available", choose "Provide default value" and select "Content ID from the URL". This should provide the Node ID to the view block.

Improve this answer
21
  • Thanks - this looks promising but it is the view attachment that needs to be informed of the same mode id from the view block. I think of it as the view block as 'parent' having the role of displaying the title of the gallery in question and passing the node id of that to the 'child' view attachment hanging off of it that does the job of generating the thumbnails. Forgive me if not explained clear enough in the question. Would your solution apply to this? Thanks for your time.
    – therobyouknow
    Dec 12 '11 at 9:03
  • Also, when we talk of "Content ID from the URL" I would like to think that this covers scenarios as well as the conventional meaning of a URL in an address bar of the browser requesting a page from the Drupal CMS. I would hope this term caters for blocks which don't have URLs in that conventional way, presumably though I would guess there is some kind of internal URL-passing within drupal that this "Content ID from the URL" would cover. This would be what I require for my case I believe.
    – therobyouknow
    Dec 12 '11 at 9:10
  • 1
    The information in the answer is correct. The "Content ID from URL" or one of the other items in the dropdown are necessary for the block to find context information from a page the block is displayed on. The block makes the information available to the attachment associated with it. Whether this answers your needs or not, of course, is another thing. Good luck and please comment on how you resolve this. Your follow up comments have been great and helpful.
    – Ashlar
    Dec 13 '11 at 15:40
  • 1
    I have read that there is more OOP at the core level, but have not gone looking for it. Views goes way back in Drupal and although it has been reworked through two major releases, it would be a lot of work to recast it as OO. Also there is Drupal's hook system and it might be difficult for Core to find hooks and call them successfully in objects. Certainly it would require new Drupal standard requirements for coding.
    – Ashlar
    Jan 4 '12 at 16:29
  • 1
    +1 @JoeS for those points. As said I am not concerned that Views is not traditionally OO. As you might agree OO has its place and its not a dogma to used for its own sake. It's just that it's easier to learn something new if it uses a concept that one is already familiar with. Whatever conceptual model used by Views, I don't mind, I think the problem here is that the possible flows of information within Views is not always obvious, but it doesn't need OO to make it so, rather better visualisation and grouping and tagging of the settings.
    – therobyouknow
    Jan 4 '12 at 17:01
0

you can try this

$my_arg = 1;
print views_embed_view('my_test_view', 'block_1', $my_arg);

views_embed_view('VIEWS_MACHINE_NAME', 'DISPLAY_ID');

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.