[Fixed in next Release] Paragraph tag handling (wpautop) in Layouts Post Content cell

[Author]

Posts

[Daniel]

I've just learned the hard way that Layouts Post Content cell can't handle p-tags (wpautop) correctly.

As a glimpse of light in the darkness, this issue is actually very simple to replicate using your Discover-WP service.

1. Create a Magazine site at Discover-WP.

2. Edit an article and add an image with a caption. Update.

3. Go to the front-end and check source. You'll find that the figure tag is wrapped in p tags. This behavior is erroneous, in a vanilla WP this is not happening. The same goes for shortcodes etc, they're all wrapped in p tags while they shouldn't be.

4. Edit the article. Click on the Content Layout Editor button. But just choose to go back and stop editing using the content editor. Now it's getting really funky! The figure tag is no longer wrapped in p tags. But if you add some text in the editor as you normally would, this new text is not wrapped in p tags as it should.

So my questions are:

A. Do you know what's going on here? If so, please explain.

B. How can I get the wpautop functionality in Layouts Post Content cells to work in the same way as in vanilla WP?

Thanks!

[Christian Cox]

I think I understand what you're saying. Try this alternative approach:
- Delete the Post Content Cell from the Post - default Layout.
- Replace it with a Visual Editor cell, and check the "Disable automatic paragraphs" box in the editor popup.
- Insert the post body content in the Visual Editor cell by clicking "Fields and Views", then "Post body"

Does this approach give you enough granular control over paragraph tags?

[Daniel]

Thanks for the suggestion.

I did a quick test with the proposed method and found that the shortcode wpv-post-body doesn't seem to work within another wpv-post-body. I'm using this shortcode (in yet another shortcode) for fetching a post body content (information box) in the correct language (using WPML). How can I solve that?

And I still don't understand why the Post Content cell can't handle p tags just as any vanilla WP installation. What's the idea behind wrapping figure and shortcodes etc in unnecessary p tags?

Also, a big issue is that after clicking the Content Layout Editor button (by mistake or whatever) the paragraph handling in that particular post is destroyed and no automatic p tags are inserted at any time. How can I restore it the post now when that has already happened? And besides, I'd like to hide/remove this button and the Fields and Views button when editing posts and pages, even for admins.

Thanks again.

[Christian Cox]

What's the idea behind wrapping figure and shortcodes etc in unnecessary p tags?
There should be no wrapping tags added around the figure and caption. Can you tell me more about how you add the image and caption? For example, when I follow these steps there are no extra wrapping paragraph tags:
- Copy two paragraphs of lorem ipsum text and paste it into the post content editor Visual tab
- Place your cursor at the end of paragraph 1 and press "return"
- Click "Add Media" and insert an image from the Media Library
- Click the image and click the pencil icon in the context menu
- Add a caption
- Publish the post

Here is the markup produced with a Post Content cell used in the Layout:

<div class="col-sm-12"><p>Lorem ipsum dolor sit amet...</p>
<figure id="attachment_316" style="max-width: 150px" class="wp-caption alignnone"><img class="wp-image-316 size-thumbnail" src="<em><u>hidden link</u></em>" alt="etste" width="150" height="150" srcset="<em><u>hidden link</u></em> 150w, <em><u>hidden link</u></em> 300w, <em><u>hidden link</u></em> 100w, <em><u>hidden link</u></em> 448w" sizes="(max-width: 150px) 100vw, 150px"><figcaption class="wp-caption-text">This is a caption</figcaption></figure>
<p>Duis convallis faucibus...</p>
</div>

Screenshot attached for reference. I do not see any extra wrapping paragraph tags around the image in this case. If you see wrapping paragraph tags following the same steps, it could indicate a difference in our environments (other plugins or theme code is conflicting) or something else. If that is the case, please disable all plugins except Types, Views, and Layouts, and activate a default theme like Twenty Seventeen. Is the behavior any different now?

[Daniel]

As you can see in my initial posting, I can replicate this issue on your Discover-WP platform very easily.

I just did it again, by following your instructions.

The figure tags are wrapped in p tags as soon as I use the Post Content cell in Layouts (which also is the default in the Magazine site at Discover-WP).

Are you able to reproduce the behavior? Do you need access to my Discover-WP or maybe connect for a screensharing?

Also, as I mentioned earlier, if one clicks the Content Layout Editor button when editing a post and then regrets it and back out and try to restore the earlier page there will still be an ongoing issue with wpautop (it won't add p tags). Have you been able to reproduce this? I'd like to know how I can restore the affected posts.

[Christian Cox]

Hi, yes I'm able to replicate the extra paragraph tag on discover-wp.com and on a local reference site installation, but not in a site that was not created from one of the reference sites. So I suspect there is something else going on, and I have asked my 2nd tier support team for some additional clarification here. I'm not clear why the behavior is different on the reference site, so I hope to find out and have an answer for you shortly.

I'd like to know how I can restore the affected posts.
This modification looks like a side effect of switching from the Post Content cell (which is in the Template Layout) to a Visual Editor cell (which is used in the Content Layout). I will ask for some clarification, but I am pretty sure these behaviors are linked. May I ask, in how many posts did you activate the Content Layout editor, then cancel and restore the basic editor? If you only did this in a single post, only that post was affected. The Template Layout assigned to all posts was not changed, nor was the content of any other post. That change only applied to the single post you edited. So you should only have to restore markup it in the individual posts where you temporarily activated the Content Layout editor.

[Daniel]

I'm developing a site based on the Toolset Starter Theme and use a couple of plugins and custom code on top of the Toolset components. Hence, it actually was a small relief for me to be able to reproduce the wpautop misbehavior on Discover-WP and not only in my own environment. Nevertheless, I'd like a solution other than adding additional content filters to remove the unnecessary p tags, since they shouldn't be there in the first place.

Regarding the Content Layout Editor. Yes, it only affects the "converted" posts. But the issue is that I haven't found a way to restore the post after pressing the button. Contentwise, sure, but when I add some more text it's evident that the wpautop function is out of order. I noticed that a couple of hidden custom fields were added to the post during the "conversion", but other than that I don't really know what happened to the post, and again how to restore it properly. Not too many posts are affected, so worst case scenario I could just delete them and create new posts I guess.

As I mentioned, I'd like to remove or at least hide the Content Layout Editor button and also the Fields and Views button when editing posts and pages (even for admins). If the buttons could stick around only when editing views, content templates and layouts, that would be cool. Any idea how to do this?

Thanks!

[Christian Cox]

Hi, our 2nd tier support team has discovered that the Visual Editor cell in the first row of the Magazine site has a direct influence on the behavior of the Post Content cell beneath it. If you edit the Visual Editor cell and enable automatic paragraphs, the image in the Post Content cell is no longer surrounded by extra paragraph tags. If you move the row containing the Post Content cell above the Visual editor, then disable automatic paragraph tags in the Visual editor cell, the image tag continues to be shown without extra paragraphs. So we will continue to investigate this but for now the best workaround is to enable automatic paragraphs in any Visual Editor cell above the Post Content cell.

But the issue is that I haven't found a way to restore the post after pressing the button.
Assuming you published the post once before you clicked the Content Layout button, then saved again after clicking the Content Layout button, the earlier version should still exist in the post's Revisions. You can find a link to browse Revisions in the Publish panel in the post editor. Screenshot attached. You can restore an old version of the Post from here, however you should be aware that custom fields are not stored along with revisions. The title and post contents will be restored, but the current custom field values will still be in place.

If you did not save again after clicking the Content Layout button, you can click "Stop using Content Layout Editor" and select the contents that were in use before you clicked the Content Layout button. If you remove the Visual Editor cells above the Post Content cell, or activate automatic paragraphs in those cells, automatic paragraphs in the Post Content cell should work correctly. Please let me know exactly what's happening if that's not the case for you. I may need to inspect the markup generated before and after clicking the Content Layout button.

I'd like to remove or at least hide the Content Layout Editor button and also the Fields and Views button when editing posts and pages (even for admins).
Add this code to your child theme's functions.php file:

function vm_wptypes_remove() {
  $scr = get_current_screen();
  $disable_slugs = array('post','page','custom-post-type-slug');
  if( is_admin() && in_array($scr->post_type, $disable_slugs, TRUE )) {
    wp_enqueue_style( 'wp-types-special', get_stylesheet_directory_uri() . '/wp-types-special.css' );
  }
}
add_action( 'current_screen', 'vm_wptypes_remove' );

You must modify the $disable_slugs array to include a comma-separated list of the slugs of any post types where you want to disable the buttons. By default, the buttons will appear, so if you create new post types they must be added here to disable their buttons.

Create a new text file called wp-types-special.css. Copy and paste this code into the file:

.button.js-wpv-fields-and-views-in-toolbar,
.button.js-cred-in-toolbar,
.button.js-wpcf-access-editor-button,
#qt_content_bs_component_show_hide_button,
.mce-ico.mce-i-icon.wpv-conditional-output-icon,
.js-layout-private-add-new-top {
  display:none !important;
}

Save the file in your child theme folder.

[Christian Cox]

Hi, just checking in to see if you were able to use one of the workarounds presented above to resolve the problem on your site. If not, please let me know.

[Daniel]

Hi,

I'm not using any workaround at the moment. So the outputted html is not correct, but it still renders ok in tested browsers. Looking forward to a bugfix in the coming version.

Thanks!

[Christian Cox]

Okay thanks, I will mark this ticket as "Fixed in the next release" so I will be reminded to update you when the next release occurs, and we can confirm the resolution then.