Open
Styling added to GenerateBlocks that are included in Toolset Content Templates or in custom WordPress Archives lose their styling when viewing posts on the front end.
(This happens because GenerateBlocks scans posts to see if they contain any of their blocks to know whether to enqueue their assets, but it is not the posts which contain the blocks, it is the template or the custom archive design which does.)
You can add the following code snippet which uses a GenerateBlocks filter to append the “content” of a Content Template or custom WPA to the post content being scanned by the plugin to determine what CSS it should add to the page. You should edit the array of post type slugs which this should be applied to (for templates and archives).
add_filter('generateblocks_do_content', function ($content) {
// Array of post types slugs which use Content Templates or custom WPAs
$post_types = array( 'cpt-1', 'cpt-2', 'cpt-3' );
if ( is_singular( $post_types ) )
{
global $post;
// is the post being displayed with a Content Template?
$template_id = apply_filters( 'wpv_content_template_for_post', 0, $post );
if (isset($template_id) && !empty($template_id))
{
if (has_blocks($template_id))
{
$template = get_post($template_id);
// Append the template "content" to the post content, for scanning by GP
$content .= $template->post_content;
}
}
} elseif ( is_post_type_archive( $post_types ) )
{
// is there a custom WPA for this post type?
$post_type = get_query_var( 'post_type' );
$wpa_id = wpv_has_wordpress_archive( 'post', $post_type );
if (isset($wpa_id) && !empty($wpa_id))
{
$wpa_helper = get_posts
( array
(
'post_type' => 'wpa-helper',
'post_parent' => $wpa_id,
'post_status' => 'publish'
)
);
if (isset($wpa_helper) && !empty($wpa_helper))
{
if (has_blocks($wpa_helper[0]))
{
$content .= $wpa_helper[0]->post_content;
}
}
}
}
return $content;
});
Would love for this to be resolved, any updates as to how long we think?
Details from plugin developers:
Hi Stuart,
GenerateBlocks is only able to scan content that it knows about for its blocks so it can generate the necessary CSS.
If content is being served by a third-party, that party needs to tell GenerateBlocks about the existence of its content so GenerateBlocks can scan the content and generate the CSS.
This article explains it with an example: https://docs.generateblocks.com/article/adding-content-sources-for-dynamic-css-generation/
Toolset should be able to either add compatibility or provide a function that should do it.
Let us know 🙂
—
Tom Usborne
Thanks for that Stuart. I’ve crafted a generic solution using the plugin filter which should automatically work for any posts displayed with a Content Template without you having to specify the template ID in the code itself, and edited the above post with that solution.
Thanks, Nigel 🙂
I suspect that will make a lot of people who use and love both Toolsets and GeneratePress/GenerateBlocks very happy.
Thanks Nigel and Stuart, much appreciated!
Hey Nigel,
One thing I have noticed here, this works with standard content templates applied to custom post types etc…however, if when using the block editor in view none of the styles is rendered unless you use the original method here and individually assign all of the view templates where you are using the block editor…
is there another alternative? or modification I can set it up to apply to all content templates using the block editor in views?
add_filter( 'generateblocks_do_content', function( $content ) {
$post_id = 218763; // A post ID to check the content of. Can be dynamically set.
if ( has_blocks( $post_id ) ) {
$block_element = get_post( $post_id );
if ( ! $block_element || 'view-template' !== $block_element->post_type ) {
return $content;
}
if ( 'publish' !== $block_element->post_status || ! empty( $block_element->post_password ) ) {
return $content;
}
$content .= $block_element->post_content;
}
return $content;
} );
Cheers
I actually figured it out …
details here: https://community.generateblocks.com/t/issues-with-styling-for-generateblocks-being-removed-for-custom-post-types-plugins/233
add_filter( 'generateblocks_do_content', 'generateblock_template_support_testing', 10, 2);
function generateblock_template_support_testing($content) {
$args = array(
'numberposts' => -1, // get all posts.
// 'include' => array(), //specify a list of ids comma seperated to include, for performance reasons
// 'exclude' => array(), //specify a list of ids comma seperated to exclude, for performance reasons
'post_type' => 'view-template', //change this is you need to use it on a differnet custom post type, useful for other plugins that uses GenerateBlocks and custom post types.
);
$my_posts = get_posts( $args );
if( ! empty( $my_posts ) ){
foreach ( $my_posts as $p ){
if ( has_blocks( $p ) ) { //used to check if its using blocks or not
$content .= $p->post_content;
}
}
return $content;
}
};
*caveat, I am not a php dev – use at with caution…
Note that in Blocks 1.5 information about the content template used to display a post is no longer stored as postmeta against that post, and a new filter can be used to retrieve the template ID from the post object. I’ve updated the code in the workaround above to use that filter.
Hi,
The workaround mentioned at the top only works for the content template, not for the WordPress Archives.
Is there any workaround to make it work for archive templates also?
Thanks in advance.