Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

has_block doesn't return true when a block is inside a reusable block #18272

Open
LyleBennett opened this issue Nov 4, 2019 · 6 comments
Open
Labels
[Block] Block The "Reusable Block" Block [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f [Type] Bug An existing feature does not function as intended

Comments

@LyleBennett
Copy link

If a block is inside a reusable block, has_block doesn't return true.

Steps to reproduce the behavior:

  1. Add a block inside a reusable block. (Let's say prfx/myblock)

  2. Add action in plugins php file to wp_enqueue_scripts

    if (has_block('prfx/myblock')) {
    
    wp_register_script('my-script', plugins_url( 'dist/assets/myscript.min.js', dirname( __FILE__ )), array(), null, true );
    
    wp_enqueue_script('my-script');
    
    }
    
  3. At this point the script is not loaded to site, but the block is in the page.

  4. Add the block to the page separate/outside to reusable block

  5. Now the script loads.

Could has_block function also validate with blocks inside reusable blocks?

Desktop:

  • Windows 10
  • Firefox 70.0.1
  • Gutenberg Version 6.8.0
@mcsf mcsf added [Feature] Nested / Inner Blocks Anything related to the experience of nested/inner blocks inside a larger container, like Group or P [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f [Block] Block The "Reusable Block" Block and removed [Feature] Nested / Inner Blocks Anything related to the experience of nested/inner blocks inside a larger container, like Group or P labels Nov 5, 2019
@cfaria
Copy link

cfaria commented Dec 16, 2019

In the meantime, this function will do the job:

function has_reusable_block( $block_name, $id = false ){
    $id = (!$id) ? get_the_ID() : $id;
    if( $id ){
        if ( has_block( 'block', $id ) ){
            // Check reusable blocks
            $content = get_post_field( 'post_content', $id );
            $blocks = parse_blocks( $content );

            if ( ! is_array( $blocks ) || empty( $blocks ) ) {
                return false;
            }

            foreach ( $blocks as $block ) {
                if ( $block['blockName'] === 'core/block' && ! empty( $block['attrs']['ref'] ) ) {
                    if( has_block( $block_name, $block['attrs']['ref'] ) ){
                       return true;
                    }
                }
            }
        }
    }

    return false;
}

Maybe the name of the function should be sth like has_block_in_reusable instead of has_reusable_block, anyway...

@tyrann0us
Copy link
Contributor

Possible duplicate of #17048.

@outdoorsdev
Copy link

Chiming in to ask if a reusable block check function can be added to core if possible. Many themes use reusable blocks for the sake of speed.

@WORX-Developer
Copy link

I would also like to know if there is a plan to provide a solution for this problem? As @outdoorsdev rightly pointed out, reusable blocks are widely used and I would expect has_block to take them into account.

@jordesign
Copy link
Contributor

Hi folks - I'd love to know if this issue is resolved by the change to synced/unsynced patterns? Are you able to try it out and see if it makes a difference?

@jordesign jordesign added the [Type] Bug An existing feature does not function as intended label Aug 16, 2023
@talldan
Copy link
Contributor

talldan commented Jul 24, 2024

I expect it's still a bug, has_block is very basic, and doesn't know to recurse into patterns or template parts (or any other kind of block that loads content from another post).

My own feeling is that I don't think it'd be a good idea to try improving has_block for this purpose either - it'd suddenly become a very expensive function, which existing users of the function might not expect.

Maybe some other API would be a way to solve it, but it's not an easy problem to fix, hence why this issue remains open. 😞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Block The "Reusable Block" Block [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

8 participants