admin管理员组

文章数量:1023827

Issue

I have a setup using Gutenberg blocks via ACF. One of these blocks is a Group block which has the following context:

"providesContext": {
    "acf/groupData": "data"
}

I am then using <InnerBlocks /> inside the group block template file.

Each of the blocks that can be nested in this group block have a value of:

"usesContext": ["acf/groupData"]

This works perfect and the group values are passed into the $context array for use within the inner blocks.

However, if I add a Synced Pattern block inside this group block, the context is lost and acf/groupData is not part of the $context array.

Hoping someone can help, would be great if there's a way to pass down the group context into synced patterns.

Tried

I've had a look around to see if there's any hooks relating to when patterns are created to see if I can pass the context through there but no luck.

I also tried creating a function that would grab the post content, parse the blocks and try and get the group block from there, however, the block ID's aren't returned when using the post content, only the block name and attributes etc.

Issue

I have a setup using Gutenberg blocks via ACF. One of these blocks is a Group block which has the following context:

"providesContext": {
    "acf/groupData": "data"
}

I am then using <InnerBlocks /> inside the group block template file.

Each of the blocks that can be nested in this group block have a value of:

"usesContext": ["acf/groupData"]

This works perfect and the group values are passed into the $context array for use within the inner blocks.

However, if I add a Synced Pattern block inside this group block, the context is lost and acf/groupData is not part of the $context array.

Hoping someone can help, would be great if there's a way to pass down the group context into synced patterns.

Tried

I've had a look around to see if there's any hooks relating to when patterns are created to see if I can pass the context through there but no luck.

I also tried creating a function that would grab the post content, parse the blocks and try and get the group block from there, however, the block ID's aren't returned when using the post content, only the block name and attributes etc.

Share Improve this question asked Nov 18, 2024 at 20:02 Glen SatchwellGlen Satchwell 111 silver badge2 bronze badges 8
  • Does the <InnerBlocks> have an allowedBlocks attribute? And if so, are all of the pattern blocks on that list? Have you tried dumping the block data before save or while editing? You might find help on the plugin support forums: wordpress./support/plugin/advanced-custom-fields – admcfajn Commented Nov 18, 2024 at 21:16
  • What happens when you detach the block from the synched pattern? My guess is that the block won't work with a context as a synched pattern. – Emiel Zuurbier Commented Nov 19, 2024 at 19:33
  • @admcfajn It does, yes. However, the pattern isn't created in the code, it's created in the editor view within WP Admin. So I can't include this within allowedBlocks since many of these can be created on the fly. – Glen Satchwell Commented Nov 20, 2024 at 13:01
  • @EmielZuurbier Yeah it works fine when detached, I think because once detached, it's then a direct descendant of the group block, so the context is there. It only seems to be an issue with synced patterns. – Glen Satchwell Commented Nov 20, 2024 at 13:03
  • I meant the blocks used in the patterns, not the pattern blocks themselves. Sounds like a tricky issue that could change at any time. Wish I had more time for this one, good luck! Have you checked the source for both SyncedPatterns and the ACF blocks you're working with? Code for both and roadmaps for improvements is available to read online. – admcfajn Commented Nov 20, 2024 at 20:33
 |  Show 3 more comments

3 Answers 3

Reset to default 1

I figured it out! I'm posting here for any future developers.

The other answers to this question weren't possible since the synced patterns being created aren't being registered through the code and instead in the Admin Editor using the options menu for blocks.

What I ended up doing was:

  1. Hook into the render_block_data filter. Check if the block type is core/block (Pattern) and has a parent block. If so, set the 'content' attribute onto the block in question. The pattern block renderer will treat this as overriding data which is then supplied to the block context. For some reason the $context array within the block template won't pass through the pattern/overrides straight away, which is where the next step helps.
  2. Hook into the render_block_context filter. Check if the $context array contains 'pattern/overrides'. If so, set the acf/groupData key (What we usually have available for non-pattern blocks) equal to the pattern/overrides data. This makes the data available to use within the block template

    Issue

    I have a setup using Gutenberg blocks via ACF. One of these blocks is a Group block which has the following context:

    "providesContext": {
        "acf/groupData": "data"
    }
    

    I am then using <InnerBlocks /> inside the group block template file.

    Each of the blocks that can be nested in this group block have a value of:

    "usesContext": ["acf/groupData"]
    

    This works perfect and the group values are passed into the $context array for use within the inner blocks.

    However, if I add a Synced Pattern block inside this group block, the context is lost and acf/groupData is not part of the $context array.

    Hoping someone can help, would be great if there's a way to pass down the group context into synced patterns.

    Tried

    I've had a look around to see if there's any hooks relating to when patterns are created to see if I can pass the context through there but no luck.

    I also tried creating a function that would grab the post content, parse the blocks and try and get the group block from there, however, the block ID's aren't returned when using the post content, only the block name and attributes etc.

    Issue

    I have a setup using Gutenberg blocks via ACF. One of these blocks is a Group block which has the following context:

    "providesContext": {
        "acf/groupData": "data"
    }
    

    I am then using <InnerBlocks /> inside the group block template file.

    Each of the blocks that can be nested in this group block have a value of:

    "usesContext": ["acf/groupData"]
    

    This works perfect and the group values are passed into the $context array for use within the inner blocks.

    However, if I add a Synced Pattern block inside this group block, the context is lost and acf/groupData is not part of the $context array.

    Hoping someone can help, would be great if there's a way to pass down the group context into synced patterns.

    Tried

    I've had a look around to see if there's any hooks relating to when patterns are created to see if I can pass the context through there but no luck.

    I also tried creating a function that would grab the post content, parse the blocks and try and get the group block from there, however, the block ID's aren't returned when using the post content, only the block name and attributes etc.

    Share Improve this question asked Nov 18, 2024 at 20:02 Glen SatchwellGlen Satchwell 111 silver badge2 bronze badges 8
    • Does the <InnerBlocks> have an allowedBlocks attribute? And if so, are all of the pattern blocks on that list? Have you tried dumping the block data before save or while editing? You might find help on the plugin support forums: wordpress./support/plugin/advanced-custom-fields – admcfajn Commented Nov 18, 2024 at 21:16
    • What happens when you detach the block from the synched pattern? My guess is that the block won't work with a context as a synched pattern. – Emiel Zuurbier Commented Nov 19, 2024 at 19:33
    • @admcfajn It does, yes. However, the pattern isn't created in the code, it's created in the editor view within WP Admin. So I can't include this within allowedBlocks since many of these can be created on the fly. – Glen Satchwell Commented Nov 20, 2024 at 13:01
    • @EmielZuurbier Yeah it works fine when detached, I think because once detached, it's then a direct descendant of the group block, so the context is there. It only seems to be an issue with synced patterns. – Glen Satchwell Commented Nov 20, 2024 at 13:03
    • I meant the blocks used in the patterns, not the pattern blocks themselves. Sounds like a tricky issue that could change at any time. Wish I had more time for this one, good luck! Have you checked the source for both SyncedPatterns and the ACF blocks you're working with? Code for both and roadmaps for improvements is available to read online. – admcfajn Commented Nov 20, 2024 at 20:33
     |  Show 3 more comments

    3 Answers 3

    Reset to default 1

    I figured it out! I'm posting here for any future developers.

    The other answers to this question weren't possible since the synced patterns being created aren't being registered through the code and instead in the Admin Editor using the options menu for blocks.

    What I ended up doing was:

    1. Hook into the render_block_data filter. Check if the block type is core/block (Pattern) and has a parent block. If so, set the 'content' attribute onto the block in question. The pattern block renderer will treat this as overriding data which is then supplied to the block context. For some reason the $context array within the block template won't pass through the pattern/overrides straight away, which is where the next step helps.
    2. Hook into the render_block_context filter. Check if the $context array contains 'pattern/overrides'. If so, set the acf/groupData key (What we usually have available for non-pattern blocks) equal to the pattern/overrides data. This makes the data available to use within the block template

      本文标签: advanced custom fieldsWordPressAccess context of parent block within block patternStack Overflow