Score:0

How to pass Block ID to a view?

us flag

I have a Custom Block type called HomeBlocks. This bundle has a paragraphs field which allows multiple paragraphs.

I then place (using Layout Builder) an instance of this block type on my home page (a node type called Landing Page). In the layout of the block type I have a View which lists some of the paragraphs added to that specific block. The view lists my paragraphs but lists all the paragraphs of that type. If I add a contextual filter for Parent ID to the view and set as Fixed with the value being the BlockID of the block which I placed on my home page; then it filters to only the ones added to that block. Perfect.

The question is then; how to dynamically set this contextual filter?

I can think of 2 approaches:

  1. Create a contextual filter plugin which passes the BlockID.
  2. Pass BlockID from the Layout to the View.

I looked at option 2 a while back and found some work being done to allow arguments to be passed back from LB; but it was only supporting static values (as opposed to tokens).

Option 1 seems pretty simple and I set that up. To start with I simply pass back the static ID value and this works as expected.

The missing piece here is how to get a list of blocks (of a certain type) which are placed on a specific node?

I tried doing this with a view and I can get a list of BlockIds of all the blocks of this type; but can't see how to filter to the the one used on the specific node.

If there will ever be only 1 instance of this block used on the site; then I can use my existing view (that lists the only block of this type). I am not concerned about having multiple versions of this block on a single page; but I am trying to accommodate that there could be multiple pages with this block added.

Score:0
in flag

So if I understand correctly, here's what you did:

  1. Created some paragraph types.
  2. Created a block type, with a paragraph field referencing the paragraph types in #1.
  3. Created a view with a Block display of Paragraphs, with a contextual filter for Parent ID.
  4. Added the view in #3 to a display of the block type in #2 via Layout Builder.
    • I'm assuming you have other things going on in the layout, otherwise, this would simply just be a View Block of Paragraphs or just added the paragraph field directly to the layout.
  5. Created instances of the block type in #2 and added them on a page.

There's a couple of crucial steps that are easy to miss:

  • In step 3 (creating the view), create a relationship to the Block entity type. Then, instead of creating a contextual filter for the paragraph's Parent ID, create a contextual filter for the related Block's ID field.
  • In step 4 (adding view block to layout), when you add the View block onto the layout of the block, Layout Builder will ask you about the block title and its visibility. Right after that, and because of the previous changes to the view, it will now ask you what value to pass as the contextual filter value. There will be an option that represents the current block.

The end result should be a view inside the layout of a block filtering paragraphs by the ID of the block that contains it.

liquidcms avatar
us flag
awesome but perhaps patches required? Your description of what i have is correct. There is no relationship for "block entity type". I have relationship to the content using the fields added to that type. Using one of those i have arg for "Custom block ID". After placing block i have contextual links for "control visibility" (patch), manage attrs (styling) and configure. In configure i see only title and override title . I can also enable to ask for args in the View under block settings; but this only takes a static id in layout.
liquidcms avatar
us flag
I'll try setting this up on a vanilla D9 site. Perhaps you have patches, or i do not have latest (I am on D9.2) or patches i do have are interfering.
liquidcms avatar
us flag
Tried a vanilla D9.2 site with only a couple patches to allow paragraphs to work at all with blocks in LB and i get same results as mentioned. I'll try updating to latest D9.3.
in flag
@liquidcms I just checked, the relationship is named like "By id: Custom block using `<paragraphfieldmachinenameonblock>`". When you add the contextual filter, the field to filter is "Custom block ID". Then one minor detail I missed, when you configure the contextual filter, you check "Specify validation criteria", with validator set as "Block", and Single ID as argument. I think this last bit is what finally made the selection appear for me the last time I did this. And this was available since 9.1 without patches.
liquidcms avatar
us flag
Sadly no relationship anywhere near that name. Perhaps a contrib module you have? I'll see I if i can track it down. Thanks.
in flag
@liquidcms A quick search for "By id" (match case and words) in the code reveals that this feature is from `entity_reference_revisions`, a dependency of `paragraphs`, which you should already have.
liquidcms avatar
us flag
oddly enough i did that exact same case sensitive search across entire site and came up with nothing. But a little digging and guessing you have this patch in place: https://www.drupal.org/node/2799479. The one from #163 as I have the one from #158 which had not yet added this relationship. Thanks for the help.
liquidcms avatar
us flag
And even with that patch.. there is still no option to pass in current block id (or anything else to the view). I suspect another patch providing this part of the solution. For now I will go back to my solution of a custom argument plugin to pass in the "parent id". This does work but at the moment only grabs the first block of this type as I can't find the answer to my original question - "how to get a list of the blocks placed on a node?".
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.