Which HTML is better, pre-Gutenberg or post-Gutenberg?

I imported post content from an old and large WP site into a fresh install and new database. Almost 1200 posts along with their meta and related media. The xml file is 15mb. I used the standard wordpress import/export along with a media export [plugin][1] for featured images. The origin site uses tinymce advanced to maintain the classic editor look for the client.

Most everything carried over, but in the new setup, the html of the imported content changed.

Here's how it looked on the front-end. left is origin, right is import.

left=exported front-end, right=imported front-end

Here is how the html changed. Left is the origin. Right is after import.

enter image description here

At what point in the process did the entire content block get wrapped in <p>’s, with <br>’s and &nbsp’s added and original line breaks missing?

Apparently, something about Gutenberg is changing the basic html of post content.




I was able to fix the front-end paragraph spacing issue with this css courtesy of Themeisle

{   content: "A" !important;
    display: block !important;
    margin-bottom: 1em !important;

Even so, I want to know how to best move forward in terms of the html. Is this some kind of bug with Gutenberg or should I just go ahead with the CSS fix? What is the proper html here? if it's wrong, is there some kind of regex magic that would fix it?


In response to @tomjnowell, I ran the export with no active plugins and imported it into a fresh installation with no active plugins. Here are the results:

enter image description here

The xml was imported into the blank site. The post content then appears in a Gutenberg "Classic" block in "edit as html" mode with the space between parargraphs removed and br's and nbsp's added. BR's do not appear in the database, but nbsp's do.

Here is another comparison showing from left to right, the XML, the origin db and the destination db. Also, I noticed the following differences between the databases. Not sure if it matters.

Origin db post_content has as type: MyISAM with collation set as: latin1_swedish_ci

Destination db post_content has as type: InnoDB with collation set as: utf8mb4_unicode_520_ci

enter image description here

  • Can you compare DB to DB rather than post content to DB or some other combination? The act of displaying post content in an editor changes it
    – Tom J Nowell
    Nov 10, 2019 at 23:23
  • Also &nbsp; is necessary as HTML won't display 2 spaces in a row, they collapse into eachother, otherwise your page would be full of the whitespace indenting of tags. Otherwise your final comparison looks correct
    – Tom J Nowell
    Nov 10, 2019 at 23:24
  • @TomJNowell - I added an image showing the differences between the origin and destination db's. Also noted differences between type and collation settings between the two.
    – Ted
    Nov 11, 2019 at 19:17
  • If this happens on a fresh unmodified latest WP, with the standard importer exporter, then I'd suggest you raise this as a bug on the main WP bug tracker/Trac. Unless you're opening these posts and saving them to change their HTML, this won't have much of anything to do with the block editor, as the only thing touching it will be the importer/exporter plugin
    – Tom J Nowell
    Nov 11, 2019 at 21:01
  • I believe I have also just experienced this issue. It seems like it's the Wordpress Importer that is changing it. So I guess the precise answer to your question is "No", but the spirit of it is: Yes, Wordpress did change it :) I found a related Github issue if you want to follow along github.com/WordPress/gutenberg/issues/13049 - did you happen to find a workaround to this?
    – jaredlt
    Jul 23, 2020 at 13:38

1 Answer 1


Gutenberg is an editor, it's not an active process that runs in the background. Unless you opened the post in the block editor there is no way for it to modify the HTML

Think of it this way, a PDF is a PDF, it's content, data. If I create it with one application, then copy it to a machine that has a different PDF reader, the PDF is still the same. To modify it I would have to open the PDF in an editor and resave it.

The same is true of Gutenberg. Unless you open a post in gutenberg and press save/publish, there are zero opportunities for Gutenberg to make modifications.

Try to imagine what would be involved for Gutenberg to actually do this. It would need to update every single post in the database, track what it had and hadn't modified, and it couldn't do this in a single request, it would have to continuously poll itself until the job was done, creating major server load.

So gutenberg is not the cause of your issue. It can't be, unless you opened all 1200 posts then edited and resaved every single one of them.

So what can you do?

First, do a standard WP export, without any additional plugins interfering or meddling.

Second, check the markup in the wxr and see if it has the same content or if it's been modified.

Third, import the data, and check the markup in the database, not the editor/frontend.

Fourth, do all of the above with the standard default themes and no plugins.

Put simply, there is no evidence Gutenberg is at fault ( there's no evidence of what is at fault, the cause is currently unknown ), and Gutenberg doesn't work that way.

As a final note, what you're referring to is not normal content, and those aren't paragraphs. Those are TinyMCE Advanced "classic paragraph" blocks, and they may not work the same way. For example, it might be that how the content looks and what the actual HTML is are not the same.

I'd suggest making sure TinyMCE Advanced is also installed on the target site. Otherwise you should ask for TinyMCE Advanced support at the TinyMCE Advanced support forum

  • Thank you for that feedback and explanation. I'm going to consider what you said and look closer into the role of tinymceAdvanced.
    – Ted
    Nov 9, 2019 at 1:23
  • I took your suggestions and updated the post at the bottom with screenshot and description. @tomjnowell
    – Ted
    Nov 10, 2019 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.