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 1with a field "content" of type blocksand 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.
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. Insertingblock 2
insideblock 1
-> OOM issue.Renaming
Block 1
's field "content" to "content_1":Inserting
block 1
insideblock 1
-> OOM issue. Insertingblock 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.