[SOLVED] API for get or find blocks by type or class

[gebeer]

Hi there,

$page->rockpagebuilder_blocks is of type RockPageBuilder\FieldData which extends PageArray and and can be searched like PageArray by id, title etc.

Is there a way to get/find blocks by there block type (class name)?

Maybe I overlooked something, but couldn't find anything in the docs.

I tried things like $page->rockpagebuilder_blocks->get('type|pageClass=Contact');

Would be a neat feature :-)

 

[bernhard]

Hey @gebeer please download v5.8.0 and use $page->rockpagebuilder_blocks->find('type=Whatever') 🙂 I also added this to the docs: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/api/

Would you mind sharing your use case? I've never needed this 🙂 

[gebeer]

  On 10/11/2024 at 10:34 AM, bernhard said:

Would you mind sharing your use case? I've never needed this

Expand  

Great! Thank you for the quick addition. Very much appreciated.

I have a SPA where I have URL hashes to jump to different section on the site like /#kontakt

In the info() method for each block I added a property id. For the ContactForm block the id is "kontakt"

Now I have link buttons in other blocks that should point to /#kontakt

I could have hard coded that. But I wanted to get the block by class name to get the id, just in case it changes one day

So in my template that holds the blocks I had this

$blocks = $page->rockpagebuilder_blocks;
$contactformBlock = $blocks->get('id=1195');
// add the hash to the page object to make it available further down the call stack in all block views
$page->contactHash = $contactformBlock ? '#' . $contactformBlock->getInfo('id') : '#kontakt';
?>

<main id="content" sortable>
  <?= $rockpagebuilder->render(true) ?>
</main>

With your update I can do $blocks->get('type=ContactForm') which is much safer in my opinion. In case the block gets deleted and recreated, the id would change.

[bernhard]

Ok one thing you have to be careful about is block visibility. What if an editor hides the contact block and add's another visible later on that page. I think your implementation doesn't account for that?

[gebeer]

  On 10/11/2024 at 2:18 PM, bernhard said:

Ok one thing you have to be careful about is block visibility. What if an editor hides the contact block and add's another visible later on that page. I think your implementation doesn't account for that?

Expand  

Yes, that is correct. I would like to handle this through the block's status, if possible. Since Block inherits from Page that should be possible?

Something like $contactformBlock = $blocks->get('type=ContactForm, status!=unpublished');

But:
When I hide the block, I get $contactForm->status = 1
When I unhide it, I get same status 1.
Looking at the RockPageBuilderBlocks pages in the page tree, they don't seem to have a regular Page status

So status in Blocks seems to be handled differently from Page status.

Is there already a selector that we could use for finding only unhidden blocks?

[bernhard]

Have a look at FieldData::wakeup - it's stored in the _mxhidden prop.

[gebeer]

  On 10/12/2024 at 9:39 AM, bernhard said:

Have a look at FieldData::wakeup - it's stored in the _mxhidden prop.

Expand  

Great hint, thank you.

My logic for getting the block now looks like

/** @var FieldData $blocks */
$blocks = $page->rockpagebuilder_blocks;
/** @var Block $contactformBlock */
$contactformBlock = $blocks->get('type=ContactForm, _mxhidden=0');

This gets only non-hidden blocks which is perfect for my use case.

[bernhard]

Hey @gebeer would be nice to mark this topic [solved] thx 🙂 

[gebeer]

  On 11/3/2024 at 3:25 PM, bernhard said:

Hey @gebeer would be nice to mark this topic [solved] thx 🙂 

Expand  

Done