[Resolved] “this block contains unexpected or invalid content”

[Author]

Posts

[rangesT]

I am trying to: create a content template using views beta blocks

Link to a page where the issue can be seen: it's a staging site behind a coming soon page...

I expected to see: the conditional blocks with single field views able to be edited.

Instead, I got: the error: "this block contains unexpected or invalid content"

This seems to be related to the block-id being changed after an autosave event - see the attached images.

[Nigel]

There have been a lot of changes since the beta was published and I'm trying to replicate this issue (using a number of conditional blocks, as I see in your screenshot) but in the latest development build there is a bug in the conditional block which is preventing me.

I've alerted the developer to the problem and I should have an update for testing fairly soon, and I'll try again to set up a test to replicate. I'll get back to you when I can.

[Nigel]

I discussed with one of the blocks developers and they said when you get the message from Gutenberg about unexpected or invalid content it should show you the raw content compared to what it's expecting. That is what is useful to see rather than the changes in the post revisions.

Are you able to share that?

You can use code tags in your reply to wrap that content for formatting, thanks.

[rangesT]

I'm not sure exactly what you mean by 'should show you the raw content'. Could you guide me in what you're looking for?

what was captured in the screenshot is exactly what it displayed after getting the error.

I get two option buttons in the block:
"resolve" which seems to just add

<p></p>

tags around the inner single field.
"convert to HTML" which transforms the block from the intended conditional field into a custom HTML block containing the toolset shortcodes from the single field.

within the 3-dots menu next to the buttons, I can either:
"Convert to classic block" which just transforms the block into a WYSIWYG editor containing the toolset shortcodes or
"attempt block recovery" which fixes the issue and allows me to continue editing as intended with the conditional logic and the correct single field contents of the conditional block.

As context, this site is fully updated to 5.3 with all plugins also updated - again the problem can be fixed by an 'attempt block recovery' and a save of the template, but the problem comes back after an autosave.

Curiously, the templates still conditionally display the post content correctly as intended in the design.

[Nigel]

Sorry if I was somewhat vague, but it's been some time since I've seen such an error to recall exactly how to handle it.

And I've just been trying to recreate it by making some edits in the database directly to try and corrupt it, but can't reproduce it.

If you can still see those warnings, would you be able to provide a copy of your site that I could pass to my colleagues to identify the exact cause?

If so, you could provide a duplicator package, as described here: hidden link

You can paste a link to dropbox or similar here, it will be hidden. We don't need credentials in that case.

[rangesT]

I can provide direct access to the staging site which might be easier.
Can provide credentials here?

[Nigel]

OK, that might be enough, but I suspect I'll need a copy of the site.

If I get credentials from you we'll take a look, and take a copy ourselves if we need to, if that's okay?

Let me mark your next reply as private so that I can get log-in credentials from you—you may want to create a temporary admin user for me to use that you can later delete. And be sure to have a current backup of your site.

Can you also confirm the url of where I can see the problem.

[Nigel]

My colleague says that with the release candidate for Views 3.0 this is fixed, i.e. that it is an issue occurring with the latest beta, and updating your site and re-saving the affected template will resolve the problem.

So, I uploaded the release candidate for Toolset Blocks to your staging site and activated it in place of Views, then edited and re-saved the content template.

Unfortunately, I still see the same.

I'll share that feedback with my colleague, please bear with me.

[rangesT]

Okay thanks Nigel, I'm rebuilding that template now in the production site and we'll see what happens with your investigations.
Would love a copy of the RC for Blocks to use in prod - I'm hoping to launch in the next week or so. Hopefully some of the beta bugs have been worked out.
In other news I encountered another error while editing the template, though I have no idea if it's related: "Something went wrong while trying to update the sources cache, with message: "The response is not a valid JSON response.". Please reload the page and try again." Is that common for gutenberg or toolset?
I still maintain it's got soemthing to do with the autosave functionality - https://toolset.com/forums/topic/blocks-editor-autosave-is-stuck-loading/

[Nigel]

A second colleague confirmed that after installing the copy of your site locally, updating to the RC, maybe de-activating then re-activating some plugins, re-saving the template, it was fixed.

I've tried the same on your site, but it's not fixed, and I can't see why.

Note, I updated the Blocks RC plugin itself as it's had an update already since yesterday. I also updated Maps, because you were using stable Maps rather than the beta which accompanied the Views beta, and added the RC for Maps.

(Views is still installed on your site but not active. The Toolset Blocks plugin is the blocks-flavour of Views, or will be.)

I de-activated all plugins, then re-activated only the required plugins, edited and saved the template, but it is still broken, with JS errors in the console. I tried in a different browser, just in case there was a browser cache problem.

I'm going to re-assign this to my second-tier colleague Beda, so that he can interact with you directly.

Can you confirm that it's okay for Beda to use this site for testing? (It's a staging site, yes?)

Also, FYI, I uploaded a plugin called "WP Downloader" which adds download links to the plugins. If you are willing (and have a another backup) you can try installing the RC plugins on your production site and compare what you find there.

[Beda]

Hi There, I am that second colleague, and I have initially motivated for escalating this because I could see that "error" sometimes during my tests, but never had "steps" to replicate it.

I had hopes that the "autosave" as you mention might be the "cause" of the problems.
But as hard I tried to trigger some similar issue by letting the "autosave" doing its job, I could not replicate anything like that.

The Block, in fact, won't "autosave", this meaning, you cannot leave the page without actually manually saving that post even if the autosave of WordPress was triggered.
That means the blocks or post will always be saved with the latest version, and cannot cause any issue with "unexpected" ID's or similar.
In short, I was not able to find any step to replicate the issue.

So I analysed your site and all I can/could see was that the block was mentioned to be broken due to a missing wrapping "p" (paragraph) tag.
This again made poor sense, since just because a Paragraph tag is not present, the block would not fail.

However, I noticed that you used container blocks - and kadence elements - and conditionals inside each other.
I noticed that if I disabled all plugins, and reactivated only Toolset and Kadence, it told me the "container" block is not supported.
And in fact, this is a Newer feature, that was not there in the very first Blocks Beta.
It might be, that you use Blocks (Views with Blocks) since the very first beta release, and in that case, there are indeed things that will not proceed to work in even if upgrading to the latest Release.

But, to my surprise - all it took on the Duplicate to fix the issue was to deploy our RC (Release Candidate) over the existing Toolset Plugins.
By doing so I discovered another issue, which I already reported to the DEV as well, who already fixed it and armed me with a new fresh RC copy of Toolset Maps, this time.

I would like to try all this on the site you provided here https://toolset.com/forums/topic/this-block-contains-unexpected-or-invalid-content/#post-1393157

But - if simply installing new RC versions will not solve the issue, I will have to go in a bit harder than usual.
This means, I will have to start removing Themes, Plugins, also the Must Use Plugins, disable and delete cache folders in the FTP of this install, and other things.
This effectively can manipulate the site to a degree that later you will be left with deleting it and creating a new staging site.
If this is OK, I will go ahead as soon as you confirm this.
If not, we do understand it and will try on a fresh copy again locally, but given we have had no success with that, it will be a lot harder for us to find and solve the actual core cause, which we believe as it stands now to be solved within the new RC candidates.

I have a hunch that when Nigel deployed the RC's, some cache kept old scripts active, and hence, it's like he never installed the new RC for certain features, and that cache I would have to remove as first.

I would need from you permission to do whatever testes needed on that staging site, and also SFTP access to the actual install to deal with Cache folders and configuration files.
Could you provide me with that?

PS, related to https://toolset.com/forums/topic/blocks-editor-autosave-is-stuck-loading/, it seems that is not related to Toolset, as per Christians latest reply there, however, you are right that it sounds too similar, and I am keeping a close eye on that ticket as well now.

Thank you for your patience, and I hope to hear back soon 🙂

[Beda]

This error seems to show when they are used in conjunction (nested) and after an update/save - so I've been trying to find ways around it using raw HTML and conditional shortcodes with CSS (I'm working on the production copy)

I am interested in the precise steps you take.

So you do a Kadence Column, then inside a Container Block, inside that a Conditional with any content?
And then save, to see the issue?
I have done that many times and did not find and (replicable) steps to the issue.
As said, sometimes it happened to me as well to see blocks with that message, more often than I would like, but never I was able to say when and how this happens.

Sometimes it was on plain simple blocks, sometimes in nested ones, sometimes after a save, sometimes after days of inactivity

I would be really happy to have some "1, 2, 3" steps to that issue if you have something?

Anyway, on your site, I noticed that still the beta-1 Views was installed, not the latest RC which would be full 3.0 version.
So I went ahead and deactivated ALL plugins and changed the Theme - then I uploaded all-fresh RC packages of Views, BLocks and Maps.
The issue wasn't gone.

The only difference to the (duplicate of your site) local tests is:
- The server and PHP/MySQL versions
- The MU Plugin
- The cache.

So I SFTP'd into the server and I notice BIG differences to the Duplicate I received.
The wp-config.php for example, your server version features a lot of customizations that are not there on the Duplicate.
Charsets are not defined, keys are not defined and specific write permission restrictions are in place on the server, which was not present in the Duplicate.
This is strange, but it could be the All In One Migration plugin that made those changes.

In any case, deleting cache and MU Plugins did not solve anything either.

I still see the same JS error causing the issue, as I saw locally BEFORE the upgrade fixed things.

But then... I "attempted block recovery".
That is a semi-hidden feature of the blocks - there are 3 dots to the right of the Blocks and if clicked you will see "Convert to HTML" but also "Attempt Block Recovery".
That ... believe it or not, it worked.

I did this for one (the third in the rows) block.
Please, can you try the other remaining blocks?
Note, I have already converted the FIRST one into HTML so forget that one, try the second, and the 4th.
I've added a screenshot of where you find the "Attempt" option.

If you succeed with this as well, please then try on the live site.
Note, your staging site at this point looks nothing like what you saw when you provided it to us.
I had to change things massively, and it may be that the recovery attempt only works if all those changes are made.
So for that purpose, I already grabbed a copy of the now very slim staging site, just in case I need to send that to the DEV (I think I will anyway, just to be sure, the "Attempt Recovery" is not somehow avoidable.)

They can then also look at the JS error (which BTW should be gone as soon you recovered ALL the blocks).

Can you confirm that does the trick?

PS the issue seems, the conditionals have someone large "empty space" between them, which seems to knock the expected content over, so they fail to display.
That may be due to some save action - where the condition did NOT yet have any content, and later saved WITH content.
So the expected condition is "empty" but instead, saved with content, and even that should of course not break things, it seems exactly what is happening on your site (or, better: Happened).
Because I am not able to replicate that even on your site, with new blocks.

[rangesT]

Wow that's a long reply! Thanks for persisting with it.
So in terms of precise steps, I'm not sure there's a lot I can say about them before the error. But after it happened I became aware of my actions. I was using a more freeform test and adjust process rather than a structured build approach.
The blocks that had the error were the ones not placed inside the container or the kadence columns row - they were the standalone full width blocks that developed the problems. I knew about the attempt recovery feature and that they worked on the blocks to be able to edit them again. I had used that feature to recover and to re-save my template, but when I went back in later to edit it once more a few hours later, the error re-appeared.
I did log into the staging site and recovered the blocks, saved them and checked the front-end and there were some blocks that didn't render after recovery. Not sure what happened there, but the site isn't what it was so there may be some missing dependencies.
I think I'm going to try to rebuild the site into oxygen templates so that I can avoid gutenberg for my listings layouts until the blocks editor is a little more stable. I need to launch this site in a few days.

[Beda]

No worries, meanwhile our Developers located the issue and are working on a persistent fix.
Right now you should be able to recover the blocks with the mentioned feature, and as soon the Developers fixed the issue I can then either send you another RC version (this is a question of maximally a couple of days) or ... you'll be able to install the final release of Toolset Blocks or Toolset Views 3.0. It is as said just a question of days, in fact, the plugins are running already on our sites in the "final" version, but of course, we can't release towards a weekend, so my personal guess is next week you'll see the final downloadable versions.

This is no guarantee, but the least would be that I can send you a new RC that will finally fix it for good.

Related to the staging site, yes, this site is not the same anymore.
I suggest removing it and deploy a fresh copy from the production to it so that you have again what you see on the production site.

This is why I wanted to be so sure you don't mind if the staging site will be unusable after our (my) testing, you'll see the FTP is stripped down to a minimal install, so I was able to grab a classic "duplicate" without All In One Migration Plugin
This then allowed the developers to put their hands on the issue in a minimal environment.

So concluding:
- right now you can use "recover" methods
- next week I can either send you a fixed RC version or... if we are all lucky you can install a stable version already.
- I will for this purpose leave this ticket in escalated status so I can then update you at the given time.

Thank you for your patience and the report!

[rangesT]

Oh okay that's great news that the devs have a persistent fix already! I can wait a few more days I guess - I'll work on something else while I wait.
I'll look forward to a new RC file - in the meantime, I'll restore my staging site from production and keep working.
Cheers Beda, thanks for your efforts.
Brendan