Problem/Motivation
The condition only looks at the paragraphs referenced directly by the node. Any paragraph nested inside another one is invisible to it.
That misses the most common way Paragraphs is used. Sites usually wrap content in a layout paragraph, a "Section" or a "Row" or a "Container", and the paragraph that actually does the work sits inside it. On such a site the condition matches nothing useful: selecting the paragraph type you care about returns false on every page, because that type is never referenced by the node itself.
Steps to reproduce
1. Create a "Section" paragraph type with a field referencing other paragraphs.
2. Create a "Search" paragraph type.
3. Create a node whose paragraph field holds a Section, and put a Search paragraph inside that Section.
4. Configure a block with this condition and select the "Search" paragraph type.
5. The block is hidden on that node, even though the node does contain a Search paragraph.
Proposed resolution
Walk the whole paragraph tree instead of only its first level. The evaluation now recurses into every paragraph it finds, through any field of type entity_reference_revisions, and stops as soon as one of the selected types matches.
Add a visited set so a corrupted reference cannot turn the recursion into an infinite loop. Paragraphs are owned by their parent, so a cycle should not be possible in practice, but the guard costs nothing and turns a hang into a wrong answer, which is a much better failure.
Comments
Comment #3
trebormc