[Resolved] This Block has encountered an error and cannot be previewed

[Author]

Posts

[Tracie]

So, I need to log out and log back in to see your updates.

[Tracie]

Just a heads up that if you're ever in a situation where the person you are working with has a different email than the account such as this situation, your company has a feature that allows the creation of additional logins for an account. I was able to create a developer account for myself with the username DaveP-2

[Waqar]

Thank you for waiting.

Can you please take a look at these two screen captures:

From the clone on my server:
hidden link
Screen capture: hidden link

From your clean WordPress Install:
hidden link
Screen capture: hidden link

Based on this I'll need to shift focus to a particular device or browser, that you're using for this testing.

Can you please confirm if you've done all these tests only on a particular device or browser? Is there any specific browser extension involved here?

[Tracie]

From the beginning, I have checked the website live page on Chrome/Firefox on a Mac and Chrome and IE on a PC and Chrome on a Chromebook.

Testing of the editor has been done on the mac and chromebook.

The PC has no extensions. Chrome on mac does, but I disabled all of them for testing.
With IE, on the PC when I try to open one of the pages (ie. Youth), I get a box at the top that says "Your Site doesn't' include support for the 'toolset-views/view-editor" block.

When editing a page In Firefox on Mac The Title is there, the featured image, and the snippet. Then there is a "The selected field has no value". The live page is missing buttons, links, and formatting is off.

On the Mac/Chrome when I try to edit a page on your serverI get a spinning load thing and eventually a white screen.

It took me awhile to realize you had deleted all the content from that page other than the heading. Did you remove the view and start fresh or just delete all the other fields? As this missing content is part of the problem, I just assumed it was still broken. When I looked at your page it was empty. It had Child Welfare, the search box and button, and then the 1234 at the bottom. This is on all browsers. Shouldn't the heading be showing up? (ALL BROWSERS ALL PCS)

To go back to the beginning of this issue, these pages (Menu Under Legal Info) stopped working properly and when I checked I couldn't edit them because of the "This block.." error that we keep seeing. That led to this support thread. All the pages are not working on your site. Do I have to recreate these pages from scratch to get them to work again? I did not make changes to them from when they were working?

If the pages were not edited by the flawed browser, why are the live pages not working on any browser? Wouldn't I have to edit them with the offending browser for them to break if it's the browser causing the problem?

All of the sub-pages under Legal Info should have blocks that look the same as the main Legal Info page (hidden link) which is working. They have the Title, Featured Image, Download PDF, Order Print, Snippet, and Last Update.

All the other Legal Information pages are still missing content:
hidden link

To be clear, these pages were not edited before the fields stopped showing on the website. When I tried to edit I saw the error.

On the Mac in both Chrome and Firefox I see the "This block.." error. On the Chromebook I see the "This block.." error. On the PC, I do not get the message but I also don't get the content on any of the browsers.

This essentially resolves the "This block.." error, but doesn't solve the initial problem.

It seems like the solution is to delete all the pages and create new ones using IE on the PC?

[Waqar]

Thanks for writing back.

Just as you noted, I checked the "Child Welfare" (hidden link) and it was not showing any content in the view's loop on the front-end. But In the back-end, all the blocks were still there.

I used the update button on the back-end and then checked the front-end the blocks started showing correctly again.

As for the other legal info pages, I can see the content on the front-end and the back-end:

hidden link
hidden link

It seems that the reusable blocks used in these pages were created using an earlier version of WordPress or Toolset plugins. If you notice content missing on the front-end of any page(s) on the live website too, please go to its edit screen and save the page's content once using the "update" button.

I hope this helps and please let me know how it goes.

[Tracie]

I'm at a loss as to what to say.

I haven't had much time to work on this problem this week, but was hopeful from this message.

I go on your page at hidden link and almost all the blocks are still missing. I don't understand how that can be considered fixed or working or resolved. I think you are saying that it is working, but the reuseable blocks don't work and you do not think the reuseable TOOLSET blocks are a toolset issue? So, I can't expect our pages to work from one update to the next? I guess that's something to consider going forward.

I follow your process on CPLEA.ca (Live), and get the same results... still broken. I go back into edit, and I get the "Your Site doesn't include support for the "tadv/classic-paragraph" block. I think, Hey apparently it's my browser. I test in Chrome on a PC with Windows, same problem. try Firefox, same problem. Maybe Edge... nope, still there. How about IE.. do people still use that? Anyway gave it a shot just to be sure.

So I come to you with a problem with blocks not showing on a page and an error message. You say the message is due to my browser, and I go with it, but am unable to duplicate your success. I say, Hey that's the error message but the problem is still there, and you tell me I have to click Update.

I reluctantly update Toolset to the new version expecting an implosion, but nothing chagnes.

I click update again. Same problem.

I do as you suggest and nothing happens. It's the same damn thing.

This has been the worst support experiences of all time, and I have been a web developer since 1997! Congrats!

You obviously can't help me with this. Maybe someone else can.

I'm done with this support thread unless I can deal with someone else.

Regards
Dave Pettitt

[Nigel]

Hi Dave

Let me take over here. I've read through the thread, I'm going to start over checking what I see on your own server, and then install a copy of your site locally and possibly on one of our online test servers to compare results. I already checked the live site shared by Waqar where everything appears to be working correctly when I edit the child welfare page with the View, but I'm not confident of the history of that site, so need to go through the steps myself.

I have other tasks, but this has been going on for some time so I'll prioritise this and update again soon.

[Nigel]

A few notes on where I'm at.

First, a list of the various sites and status:

1. live site: I have no access to the backend, nothing to report
2. beta site: Not sure of the history here. There is an untitled draft page with a broken View (I named it Beta View). There are errors in the browser console, but I don't know how we got here. I created a new page (Nigel View) with a similar View, and it works as expected on the front end, and there don't appear to be any problems editing it in the back end. You might like to edit it yourself to confirm the same (and if you see any problems, that may be significant so please let me know).
3. waqar online copy of live site: when I enter the site and edit the child welfare page in the back end everything appears normal, I can edit the View, and everything looks to be intact, with no errors.
4. locally installed copy of live site: when I installed the duplicator package you provided on my localhost, I first had to disable WordFence and make some edits to wp-config.php to be able to enter the site (normal). When I tried to edit the child welfare page it clearly wasn't working correctly; most of the View output section was empty, and while I could edit the heading block it had no text and was not using dynamic sources.

I inspected the database (using phpMyAdmin) and checked the content in wp_posts of that particular page (id = 12566).

I saw much of the scaffolding for the View block (you may be familiar with how the Gutenberg editor stores blocks in commented sections of the post content), but checking section for the heading block I could see that the expected content relating to dynamic sources was missing.

Here's an example of how it should look:

<!-- wp:toolset-blocks/heading {"dynamic":{"content":{"isActive":true,"provider":"__current_post","source":"post-title"}},"level":3} -->
[tb-dynamic-container provider='__current_post' source='post-title' field='']
<h3 class="tb-heading" data-toolset-blocks-heading="1" data-last-update="1.4">[tb-dynamic provider='__current_post' post='current' source='post-title' force-string='first' ]</h3>
[/tb-dynamic-container]
<!-- /wp:toolset-blocks/heading -->

There are quite a few post revisions for this page. The link to review the post revisions (part of the page meta in the sidebar) didn't work correctly, so I reviewed wp_posts to find the revisions for that page, the most recent of which had post ID of 29892.

So I edited that post (in phpMyAdmin) and simply copied the entire text from the post_content from that revision and pasted it into the post_content of the current version of the page (ID = 12566).

I then returned to the WP admin screens and edited the child welfare page there.

Now everything appeared to work as expected. The View block content loaded normally, and the individual blocks could be edited and their settings updated.

So a solution for you on the live site might be to try the same on whichever pages you are having problems editing in the back end. (I'm guessing if you have been developing since 1997 you'd be familiar with phpMyAdmin, but if you need help with it let me know.)

Take a backup beforehand, and when you have completed it such that things appear to be working correctly take another backup, in case the problems reoccur.

Because we don't know how the problem arose in the first place.

The fact that the link to edit the post revisions (core WP) is broken points to some underlying issue. The link is broken because there is no such entry in wp_posts for the post revision the link is pointing to.

Before going much further can you verify if you are able to get things working by replacing the post_content of problem pages with that from a post revision?

I'm going to set a private reply in case you need help with that, as I'll need credentials for the live site in that case.

[Tracie]

I was going to go through the private message you suggested, but to do that I need to upload a database etc. just to reply. I'm not sure why that's required at this point? Are you not able to set this as private without? I would have preferred this entire thread get deleted permanently as I had thought it was private since message 2 when I went through the private message and sent the sensitive information. I don't recall a notice that it had switched back to public.

I actually thought I had submitted this response a long time ago, but came back to the window to find it hadn't because I didn't attach a database or some silly requirement like that. Anyhow... here's my response from earlier:

I appreciate the work you put in yesterday, and I was able to duplicate your work.

The reuseable blocks have been the problem since the beginning, but either I didn't communicate that well, or my emails were misunderstood. I felt that Waqar's solution was getting rid of the error message, but not the problem. Kind of like putting electrical tape on the check engine light kind of solution. If the easiest thing is rebuilding the reuseable blocks, which is actually a lot quicker than going through the phpMyAdmin process, then it should have been said.

The corrupt (or however you want to describe it) reuseable blocks were created with a beta version of your VIEWS plugin over a year ago. There were a lot of issues with that version, but I was able to get it working. Somewhere along the way updates changed things and it stopped working.

I have decided to rebuild those views, and have run into another strange issue. I don't need it resolved but it's a weird one, that you may come across in the future. I think it's related to some issues I'm having with the litespeed server caching.

I created a new page/view and created new reuseable blocks. One change I made was using buttons instead of links. Both buttons have the same style settings, and they look great. I find an unrelated CSS error on the site and go into Site Editor and change the css (on a css element that doesn't exist on the Toolset page). When I go back to the toolset page, the font sizing is gone on one of the buttons and I have to recreate it.

I make another small change on the page, in a different block, and the same thing happens to that button. It seems like whenever I change anything on that page and save, it resets the formatting of that one button.

I don't want to get into it, as I just go in and redo the formatting for now. It was so strange, I had to try it again, and it worked the same way. The styles aren't being overridden, they are vanishing. I'll just put them back in for now.

Thanks for your time.

You can mark this resolved, even though there wasn't really a resolution.