I see in a search that support and dev are actively looking into this issue. There is a request on the ticket that you want us to report if the issue occurs. I believe it is Beda who is working on these issues.
Following the screenshots, you can see the site showing a block with dynamic content correctly. By just opening the page (homepage) in an editor shows question marks and when highlighted report that "this block contains unexpected or invalid content". Just exiting without saving shows the homepage on the frontend now with the question marks. Note in the fourth screenshot that I also use the same content on the about page.
My workflow was that I first created the blocks in the Types of Projects containers on the homepage. I then set the dynamic block to be a reusable block. I then added it to the About page. After this, I set the dynamic block to a regular block on both pages, so I could edit them separately. When I first experienced this error, I was able to resolve the issue by deleting and recreating the dynamic block.
I am providing full access to the staging site for you to work with. When you are done, I will overwrite with current production. use instant IDE using htaccess/ftp credentials.
Also note that the question marks are currently appearing on my production site. I am going to recreate the block as I know this resolved it in the past. But, I need to do it everytime I open the homepage or about page in the editor.
please hide the screenshots on this ticket when you are done. I don't want them visible to others.
You can press the "3 dots" in the block and then choose "attempt block recovery", which will resolve the issue.
I've done that for one block, see screenshots.
This is currently the only workaround and as out Developer found, as well the only solution, as it is due to some mix in the required markup of Gutenberg that changed over time.
I have added a comment to the internal issue tracker however there is not much hope for a fix - it should however not happen anymore after doing the attempted recovery.
Can you confirm this as well?
The site still showed question marks on all the displayed fields again. When I opened the homepage for editing in the backend the question marks appeared indicating that issues needed to be resolved. However, on selection of the fields and text block the message to resolve did not appear. Without making any changes and saving the page, the question marks on the frontend no longer appear. The about page looked fine without any intervention.
Would you like me to leave the staging site available for further testing by your team? If so, let me know how long you need it for your access.
Otherwise, I am happy to close the ticket and I will overwrite the staging with production.
Yes, I'd offer to have another look on Tuesday when I am back, I want to ensure nothing is out of the ordinary.
This will also leave it a bit of time in case the issue, as you mentioned, comes back later.
I saw nothing unexpected on lien caché today.
As well the backend functions and appeared as expected.
Then I updated the page (just saved), and the question marks were back.
When I click inside the single blocks I do not see anymore the attempt recovery offer, and the question mark will as well disappear.
I also deactivated the plugin "Instant IDE Manager" but it did not fix it.
I see it also on the about page:
lien caché and lien caché
Interesting is that this Question mark is a styled style="text-align: center;" text, it's not related to the "this block contains unexpected or invalid content" issue I think.
It seems to come from within tb-fields-and-text block (Fields and Text), but, if I review the raw code of those blocks in the backend of the page, the question mark or it's wrapping HTML is not there 🙂
The question mark, however, seems to come and go without a clear pattern. It seems as far I saw a placeholder for some image (if missing) according to the code
I'll have to approach this locally as a new bug.
I downloaded a copy of the site and will debug this locally and eventually send to the developers.
I played around with the view locally, inserted it to a new page, and made some changes and reverted.
Suddenly the question marks are gone again.
What I did in the between was to disable the Plugin and Theme (making sure I use only Toolset and Twenty Twenty) then I re-saved and since then the question marks are gone, even if re-activating the theme and plugin you use additionally to Toolset
I cannot explain this any else than something's either stuck in the cache or caused to not update/updated wrongly if one of the plugins/themes is active along with the Toolset.
I tested that on your online staging site and found it's not resolving anything there.
The Question marks seem injected on the fly after the page is done loading.
Only deleting the View, and re-inserting it, did solve the issue finally as well on the staging site.
It seems related to cache.
Can you try these steps on the live site or on a fresh copy of the staging site?
1. Disable all plugins but Toolset
2. Change theme
3. Edit the page and remove the View from it, then insert the View in a new page or the same page again
This should resolve the problem.
Hi Beda,
For now I have caching disabled for both production and staging sites. However, they are on the same server and server wide settings, may be causing issues.
For now, I not been able to recreate the issue on my current production site. I shall overwrite the staging site with this version if you are done working on the staging.
If you would like to have a copy of the current staging site for your testing, I can make a backup copy available for you to use. Let me know if this would be helpful for you.
If the issue is resolved now also on the live site, we will not be able to re-introduce it on a new copy on the staging site.
However, what I would suggest is to simply experiment with the cache settings, maybe you can isolate those settings for staging or simply test what happens if you turn it back on and re-save the pages.
If then the issue comes back and resolves with the same steps, it's due to the cache.
We might then even be able to reach out either to the cache services or maybe add some fixes to toolset - sometimes cache issues can be solved.
I suggest hence, rebuild staging with a copy of the live site, as is, and then re-enable cache and play on the staging site (I can do that) to see if the issue comes back.
Do you want to notify me here once you overwrote the staging, with a new version, and enabled back the cache?
I could immediately see the issue on your newly populated staging site.
I tested my steps:
1. Deactivate all plugins but Toolset
2. Change the Theme (to Twenty Twenty)
3. Edit the page and remove the View from it, then insert the View in a new page or the same page again
It didn't solve the issue.
I then saw in the backend it appeared a modal asking me to edit the original or copy of the view, I chose "original" and saved again.
Then, the issue was gone and is not re-appearing as of yet.
Can you confirm that you also can see, edit and save the page without any issue?
If so, we can then reactivate software to see if it comes back.
I edited both home page and about. After saving, I can confirm the issue does not return.
I would mean then it's safe to say, that my steps to the solution work.
It seems a cache issue, meaning that something's stuck in the cache and gets freed when we remove and readd the view like described.
Can you try that on the live site? It should be relatively quick and ask for a downtime of maximally 10 minutes, being disabling theme and plugins and then remove/re-add the view as described.
Eventually, it should also work if you temporary disable the cache, or better, flush it and resave that page with the view.
You got it!
I recreated the issue on the production site by editing the toolset fields block. After saving page and refresh the "?" appeared. I then purged cache and after a refresh, the "?" disappeared without having to edit page again.
For my side, I am going to wipe the VM and build from a new image. The caching solution I am using through runcloud.io is new, so there are probably still some bugs. By wiping the server and building a new one without using their runcache solution enabled I can be sure of a clean install. I will implement another caching solution that is more mature.
Thanks for your help. I hope this exercise was helpful to you as well.
Thanks for confirming.
Generally, there shouldn't be conflicts with other plugins or themes or servers.
This includes cache mechanisms. If we can confirm an issue we usually will try to resolve it.
But since we confirmed on the staging site that evenewith cache the issue didn't return we should be able to safely say this was an exception, which won't return.
Please let us know if it does. We will immediately resume the investigation.
