[Resolved] Attempt Block Recovery

[Author]

Posts

[keithH-4]

Tell us what you are trying to do? When I save a page and view it again later in the block editor. I have to recover each block to again be able to edit. I rebuilt this page a few times already because it kept happening. I think it might be because of where I am putting the short codes. Not really sure... Advice?

Is there any documentation that you are following?nope but i've watched just about every toolset video I can get my hands on.

Is there a similar example that we can see? just my site, I seem to be the only one who can't figure this out

What is the link to your site? images linked below

[Nigel]

Hi Keith

Content created with blocks (generally) is saved in a very specific format, the details of the block are stored in HTML comments that store related attributes etc.

It is quite a brittle format that can easily be broken were you to edit the HTML directly.

The other way that it is normally broken is if a plugin update occurs which changes some details of the block such as the available attributes, so that what is currently saved for the block no longer corresponds to what the block declares as expected.

This shouldn't happen—any updates we make to blocks with such changes include a mini-migration method to handle it.

We didn't provide such migration methods for changes to the early beta versions, so the only time I would say it is expected that you see this is if you had created content with one of the early betas, and then edited the pages with the current version of Blocks or Views installed.

We've been talking in another thread about a problem using a table inside a conditional block, is this the same page?

I requested access details in that other thread, when I get those I can take a look at this.

If you have any specific info about the steps you take that lead to this, please let me know.

[keithH-4]

I have two bugs in - Layouts that were created by deleting the post type before removing the layout from the custom post type archive. So now I have layouts that are assigned to something that no longer exists. I have phpmyadmin installed on wordpress if there is anyway you can get rid of those two layouts that would be great.

"The other way that it is normally broken is if a plugin update occurs which changes some details of the block such as the available attributes, so that what is currently saved for the block no longer corresponds to what the block declares as expected."

So rebuilding that page in blocks should prevent the issue from recurring.

"We've been talking in another thread about a problem using a table inside a conditional block, is this the same page?"

Yea I think it is important to be able to show tables based on the conditions- I was trying out the group function today ( I still have a lot to learn about it ) is there a way to assign a group as a conditional for the table? I have been using the filter for the view to filter the same author - currently logged in.

[Nigel]

1. I just checked the scenario of trying to delete a Layout where the CPT no longer exists, and I found that although the trash link has been disabled, it is still possible to use the Change usage link and then unassign the Layout from the now non-existant CPT (screenshot), which then restores the trash link.

2. yes, if you rebuild the page with blocks it shouldn't re-occur (although it could happen if you use blocks from other vendors on the same page and they make changes to their blocks without some kind of migration).

3. Can you elaborate what you mean here? Which groups?

There are several kinds of conditional display with Toolset.

One is at the level of individual custom fields, whose display is conditional upon some other field value.

There is something similar with front-end forms where whole sections can be conditionally displayed depending on some field value.

Then entire custom field groups have settings about where they should be displayed which can include conditions based on the template used for posts, the assigned taxonomies etc.

And then there is the conditional shortcode (now available as a conditional block) which will output what's inside depending on some test run at the time the page is being constructed on the server.

I'm not sure from your comment what you are referring to.

[keithH-4]

1. I just checked the scenario of trying to delete a Layout where the CPT no longer exists, and I found that although the trash link has been disabled, it is still possible to use the Change usage link and then unassign the Layout from the now non-existant CPT (screenshot), which then restores the trash link.

I was able to fix the others but this is linked to a post type archive that no longer exists. Any idea how to delete this one? The old credentials should work still to log you in.

[keithH-4]

The only way i know of deleting the views is by going through each wordpress page 1 by 1 to find a page with a view. Is there any other way - something faster?

[Nigel]

To delete the Layout assigned to a non-existent archive, you could either temporarily create a post type that uses the same slug as that of the archive the Layout is assigned to (if you can remember it), or you can delete the Layout by editing the wp_posts table of the database directly, using phpMyAdmin or similar.

You will note that the Layout has an ID. That is the post ID from the wp_posts table, so you can look up the post with that ID and delete it. You will likely want to look up the entries in wp_postmeta with the same post_id and delete those, too.

As for finding Views, on the page listing your Views you can use the Scan button to find the pages or templates where they are in use, to decide whether they need to be deleted.

Otherwise, Views are also stored in wp_posts, with a post type of 'view'.