[Resolved] split — Post Content (Body) into 2 sections
This support ticket is created 2 years, 6 months ago. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
1. Title
2. Excerpt
3. video block
4. many paragraphs blocks
in a long monotonous blob..
I am using a Single Post content template to make things look better, and of course the custom fields, title, excerpt etc are no issue, but Toolset Blocks sees 3. Video Block and 4. many paragraph blocks all as Post Content (Body);
...all of this is normal behavior I guess.
I am wondering if there is a good way to flag (to Toolset Blocks) that a Gutenberg Block in the Post Content (Body) should be ignored by the Single Field > Standard Field > Current Post > Post Content (Body)... (or hidden in the display)
.....this probably seems like a weird request but I am noticing that as people start creating very long posts using blocks at some point we need a way to re-engineer the site to take some of the content and convert it to work like a custom field, or be an actual custom field, so that we can dynamically rearrange the way blocks are displayed on a post.
I understand what your describing, but there isn't really any way to split out parts of the post content where users have created long posts so that you have more control over how they are displayed. The post content is the post content (all of it).
I don't know the details of your site and what the users are adding to posts, but the only real solution I see is to try and tackle the issue at source, i.e. to prevent the users creating such long posts in the first place.
Create more custom fields as appropriate to encourage them to split content into different sections, and then in the template you can control what sections are displayed where.
sorry for the delay - I somehow missed the notification. As always, you seem to understanding the situation quite precisely ...thank you.
The issue does not really come up on much on new sites where I can define appropriate custom fields and post types. The issue is more with old sites where someone knew enough about blocks to create a color and font circus reminiscent of so many theme free powerpoint presentations in the 90's.
There is some issue with older plugins like Sugar Calendar and Kadence Simple share where they seem to be injecting stuff below the header; which has the result of repeating this stuff both below the header and wherever I am using - Toolset Blocks Single Field - Post Content (Body). see attached images. I am of course asking Sandhill and Kadence about it.
When it comes to cleaning up older sites I get back to this idea that some stuff belongs in the Post Content (Body) and some needs to be either ignored or moved... and well - I cant think of a good way. ...but I am fairly sure I am not the only person dealing with this.
I was looking at export files as they are a little easier for me to read than wading through a database; and at the risk of stating the obvious everything between
<content:encoded><![CDATA[ ]]></content:encoded>
...will be displayed by Toolset Blocks Single Field - Post Content (Body).
This is grand and so I was thinking about either running a search and replace in the export file or a query in the database to move for example this ARVE block elsewhere; then then it occurred to me it might be possible to optionally ignore certain blocks, and just leave the post alone, so here for example I want to display all the content except the Arve Block (I deleted the hundreds of paragraphs which followed).
<content:encoded>
<![CDATA[<!-- wp:nextgenthemes/arve-block {"url":"<em><u>hidden link</u></em>","thumbnail":"15080","thumbnail_url":"<em><u>hidden link</u></em>"} /-->
<!-- wp:paragraph -->
<p><strong>lots of text deleted... </strong></p>
<!-- /wp:paragraph -->]]>
</content:encoded>
When inserting the post body using a block (the Single Field block) the option to add the suppress_filters parameter isn't available, and that prevents 3rd-party code adding content to "the content" via the_content filter, avoiding the repetition problem.
We have an internal ticket about breaking out the post body into its own block, where that option can be made available, but in the meantime try inserting the post body via a shortcode instead:
As for stripping out unwanted block content or ignoring it, that's a tricky proposition. The implementation of Gutenberg with this format of using comments to delineate blocks is quite brittle, and if you edit it directly to make changes you run the risk of a bunch of broken block messages.
It's certainly a possibility, but you'll likely need to sharpen up your regex skills if you intend to automate this somehow.
Unfortunately I don't really have any tools to share that can help you with it.
That shortcode did what I needed for both the social share and the sugar calendar !
It sure would be nice as a block or block option - the problem with blocks is one tends to spend time trying to make things work when it's much easier to just use a shotcode.
As I expected for the cleanup, I was just checking. It feels like a flaw in WordPress Blocks architecture that everything is now a blob; the very thing which made CMS's popular over HTML 20 years back.
Nigel not really a re-opening but I though it was worth mentioning based on this comment.
We have an internal ticket about breaking out the post body into its own block, where that option can be made available, but in the meantime try inserting the post body via a shortcode instead:
The appropriate repression logic is there when I add a WYSIWIG custom field or two; unfortunately the default setting is somewhat illogically set to Apply third party filters to the output. I just raised a feature request to change this.
Yep, it's an option when inserting via shortcode for both the post content and wysiwyg custom fields, isn't available as an option at all when inserting the post body via the Single Field block, and defaults to apply filters when inserting a wysiwyg custom field using the Single Field block.
The developers already have the existing ticket about the post body, and the head developer will have received your feature suggestion submission about the default values.
