GenerateBlocks stopped working with post {{variables}}

[mtoensing]

The variables (dynamic tags) of GenerateBlock do not work after the update: https://wordpress.org/support/topic/post_permalink-not-working-anymore/#post-18760339

@blronaldhuereca do you have any idea why? Because there was no change with the logic of th processing.

[ronalfy]

@mtoensing this broke between 6.9.1 and 6.9.2. I'm still investigating.

[ronalfy]

@mtoensing the only change was adding support for GB 2.0, which makes sense that GB users just started to notice.

6.9.1...6.9.2

[ronalfy]

This is an issue with the content parsing, and would require a re-work of block parsing, so I'm not sure this is ideal.

The issue is the filter the_content.

/**
 * Adds IDs to the headings of the provided post content using a recursive block structure.
 *
 * @param string $content The content to add IDs to.
 * @return string The content with IDs added to its headings
 */
function simpletoc_add_ids_to_content( $content ) {

	$blocks = parse_blocks( $content );

	$blocks = add_ids_to_blocks_recursive( $blocks );

	$content = serialize_blocks( $blocks );

	return $content;
}

add_filter( 'the_content', __NAMESPACE__ . '\simpletoc_add_ids_to_content', 1 );

By the time the content reaches you for parse_blocks, it's already sanitized. So what the plugin is doing is simply returning sanitized data.

A fix could be doing a string search for http://{{, which would work for certain GenerateBlocks tags. The issue with that is that it's a rabbit hole.

The most reliable solution would be to assume we're in a post context, grab the original unsanitized data from post content (using get_queried_object_id, and then run the parse_blocks on that.

[mtoensing]

Hi @ronalfy Thanks for looking into that! In the past there were many more problems due to the processing. If we grab the original unsanitized data maybe we have other side effects.

So since this has nothing to do with your changes (sorry, I assumed that) my suggesting is that we dont pursue this further. It might break many more things. My goal would be to make SimpleTOC as robust as possible and not introduce hacks down the road.

What do you think?

[ronalfy]

The TOC may not always be in a post, in theory, so yes, it’ll probably cause more problems than it solves. I’ll keep thinking of a workaround.

…

On Fri, Dec 19, 2025 at 00:30 Marc Tönsing ***@***.***> wrote: *mtoensing* left a comment (mtoensing/simpletoc#79) <#79 (comment)> Hi @ronalfy <https://github.com/ronalfy> Thanks for looking into that! In the past there were many more problems due to the processing. If we grab the original unsanitized data maybe we have other side effects. So since this has nothing to do with your changes (sorry, I assumed that) my suggesting is that we dont pursue this further. It might break many more things. My goal would be to make SimpleTOC as robust as possible and not introduce hacks down the road. What do you think? — Reply to this email directly, view it on GitHub <#79 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE3M2LDGRGLCR7W5HKKB734COLO5AVCNFSM6AAAAACPMVBYJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNZTG4ZTINJTGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>