You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding a block with a block type field within itself and rendering it using renderBlocks() causes out-of-memory issues.
More specifically, block variables are shared within each layer of blocks. This can happen at any level of depth within blocks.
Example:
We have Block 1 with a field "content" of type blocks and Block 2 with a field "content" of type blocks.
I believe blocks shouldn't be able to access parent blocks' variables, as it would only lead to unintended consequences such as this one, and I do not see intentionally using parent variables in blocks as a good thing.
I believe this is a known issue, as the columns_two default block forcefully ignores itself as a valid block underneath.
The text was updated successfully, but these errors were encountered:
Adding a block with a block type field within itself and rendering it using renderBlocks() causes out-of-memory issues.
More specifically, block variables are shared within each layer of blocks. This can happen at any level of depth within blocks.
Example:
We have
Block 1
with a field "content" of typeblocks
andBlock 2
with a field "content" of typeblocks
.Inserting
block 1
insideblock 1
-> OOM issue.Inserting
block 2
insideblock 1
-> OOM issue.Renaming
Block 1
's field "content" to "content_1":Inserting
block 1
insideblock 1
-> OOM issue.Inserting
block 2
insideblock 1
-> OK.I believe blocks shouldn't be able to access parent blocks' variables, as it would only lead to unintended consequences such as this one, and I do not see intentionally using parent variables in blocks as a good thing.
I believe this is a known issue, as the
columns_two
default block forcefully ignores itself as a valid block underneath.The text was updated successfully, but these errors were encountered: