Published failed. Invalid ID.

I suspect some sort of ID conflict got introduced by restoring to live from a backup of temp. Possibly the DB table’s auto-increment value was not updated, so new post IDs were assigned existing IDs, corrupting any posts caught in the middle. Complete speculation, but it fits the symptoms you’ve described.

To verify, get into the phpMyAdmin app. Find the wp_posts table. Click the ID column head to order by ID. Determine the largest post ID used, it should be the last record in the posts table. Then go to the table’s operations tab and ensure that the AUTO_INCREMENT value is one more than the largest assigned post ID. Update it if you need to. Do the same for the postmeta table. If any other tables were added to while you were working on temp, you should check those as well.

This should prevent further problems like this, but will not correct any posts already corrupted. I recommend publishing as new any posts/pages that are suspect, then deleting the original, similar to as you’ve already done, except this time we’re assured the newly assigned ID will be unused. And fully delete any suspect posts after cloning them, don’t just un-publish. Even empty the trashed posts once you’re sure the newly cloned versions are correct.

Thank YOU for

How do I find the corrupted ID of posts that I cannot see if I unlink them, or are you saying that THAT will resolve the invalid post ID?

Because the page itself is NOT corrupted.

I’ve checked the ID of the post and it agrees with what is shown in the following screen print: https://www.awesomescreenshot.com/image/31795036?key=8013e9bd99541c7981be782f4d9fb7de

So, I am still confused.

If I were to create a copy of this page, do I go back inside myPHPAdmin and delete the one with the ID of 222, as shown in the screen print above?

Thanks again for all your help. Much appreciated!

I advise not deleting anything via phpMyAdmin. There can be a lot of other records tied to it. A missing reference could make things worse. It should only be deleted through the WP admin UI. If you cannot do so because of this ID corruption, I think it should be safe to ignore its presence. It shouldn’t be any trouble as long as you don’t try to use it for anything. I’m assuming its ID is lower than the current auto-increment value.

My concept is more to get a copy of the page that behaves normally and shows up where it is supposed to be, rather than to attempt to correct whatever went wrong. As long as everything else seems to be behaving normally, I think this is the prudent course of action.

It’s got something like 16 revisions attached to it… which makes me right back where I was with an OLD over loaded WP database, even though the installation was brand new on the server I built this site on.

Yes, this page is 222 and the greatest ID is 9906.

I will get on creating a copy of the page and dropping the live version now.

Wondering if it would be safe to install a database cleanup plugin once I’ve created copies that actually appear in the All Pages. Seems like the only way I might get rid of all the extra clutter.

I KNEW this new Block Editor was a mistake for WordPress. You cannot keep adding layers of code like they’ve done with this new editor, and expect the scripts to run without issue.

Like I said earlier. This issue makes me want to leave WP as my CMS.

All my work creating a brand new site to use the Block Editor on and what good did that do but nothing.

@bcworkz thank YOU for your time in helping me with a resolution to this mess. Very much appreciated! HUGS!

You’re very welcome! A cleanup plugin should be safe to use, but there’s a small chance it too could corrupt something. Do make a full DB backup before attempting anything like that. I would be most comfortable relying upon the export utility in phpMyAdmin as a reliable backup method. Other backup methods, like a backup plugin, are also acceptable. I just have more experience with phpMyAdmin export, thus I have more confidence in it.

Oooh yeah, you bet… backups are vital before doing ANYTHING like DB cleaning. Thanks again.

Backing up the phpMyAdmin… hmmm, never thought of doing that. Thanks for THAT tip!

Never hurts to have 2 types of backups every so often… like in this case.

Okay @bcworkz, I can save the pages to Draft and they are clearly listed under drafts.

I copied the page again, gave it a new slug… but once I published it… POOF! It disappears.

It HAS to be the custom HTML block that is refusing to function properly. Have even checked that my HTML coding is correct.

The block editor keeps asking to rescue the block when I save the page to draft (now I’m working with copies), and I’m forced to tell the block to be custom HTML.

THAT seems to be the issue here. I’ve also found this issue on another page where I’ve used a similar setup.

The page I originally cloned (and wrote about in my initial ticket here), I wiped out most of the content and only used ONE check mark icon and description as well as the button link. That WP page remains visible from the All Pages.

Yet… when I take a Draft page from the one I’m TRYING to fix… that’s where all the issues are.

Is there a limit of how much HTML a Custom HTML block can handle, perhaps?

Everything has a limit ?? But I imagine it’d be quite large, larger than any web page has any business being. If you manually alter (via code editor) most block HTML code, it’s common for the editor to not like it and for it to ask if it should be repaired. But not custom HTML. I’ve not known valid custom HTML to ever be problematic. This HTML doesn’t have any <script> tags in it, does it? That could mess things up. How sure are you that it’s valid HTML? Did you run it through a validator like the one at W3.org?

If something in content is causing grief and you cannot discern the cause, you could use the “divide and conquer” method of debugging to isolate the cause. Working on a clone of the content, divide it into large sections. Remove one of the sections and re-test. If the problem goes away, it was in the removed section. Restore it and divide that section into smaller sections. If the problem remained, then the removed section was likely fine and the problem is in the remaining section. Repeat the division process on that problematic section.

Continue the dividing and testing process until you’ve narrowed down and identified the precise problem. Tedious but effective, assuming there’s only one problem. Multiple problems can still be found this way once one is eliminated, but the effort needed to isolate each problem grows geometrically.

Well, you’re hearing it from me now, and I’d GLADLY let you inside my site to see for yourself.

I’ve even tried re-creating the page using the Custom HTML block and the page STILL remains unseen on the All Pages once I publish it.

No, there is no scripttag in my Custom HTML block anywhere.

When WP as me if I want to repair the block, it only offers to Convert to HTML. When I create a new Custom HTML block, then copy and past the code from the one block to the new block, and then I go to delete the now empty HTML block, it even asks me if I want to delete the Custom HTML block… go figure, because I cannot.

Yes, I’ve even run it through the HTML validator, because I thought of that too.

And, yes, your “divide and conquer” idea had crossed my mind. Especially after that ONE cloned page that was edited down to one list item and the button is appearing in the All Pages.

This “headache” is EXACTLY why I postponed converting my site to the new block editor. Grrrrr… makes me NOT like WP at all, anymore!

Thanks again for all of your assistance with this.

Think I’ll also explore another, more reliable CMS too.

I appreciate the offer of access, but I must decline. Such access is not permitted by any forum members. Doing so incurs risks and liabilities much greater than should be expected from volunteer strangers.

If you don’t like the block editor, you can revert back to the much older TinyMCE based editor from pre-Gutenberg times via the “Classic Editor” plugin. While I use the block editor for common, straight forward content, I often fall back to the classic editor for more esoteric HTML coding. Not that it couldn’t be accomplished in a custom HTML block, but the classic editor is what I’ve long been used to. I don’t think the classic editor would help any in this particular case, since switching editors would not alter the HTML in any way. Might be worth a try though, since the classic editor updates posts through a slightly different mechanism.

I don’t think the block editor is the root cause of your issue. It is a lot more vocal about content it doesn’t like. And allowing it to “recover” something could possibly compound the problem.

Failure to appear in the list table is entirely unrelated to which editor is used. It shouldn’t even matter if the HTML in content is valid or not. It is possible for a theme or plugin to alter what appears, but it’s hard to imagine how it would affect only this one page, regardless of which ID is assigned. You could examine the actual SQL query made to see if any unusual criteria is being added to the query. You can view the SQL use through the “Query Monitor” plugin. After you’ve loaded the problematic list table, in the plugin’s queries view, filter for the main query caller. Look for anything seeming out of place in the WHERE criteria of the SQL query. Criteria would normally be just the post type and a number of different possible statuses.

Hey, now there’s a thought — the statuses. If for any reason your page’s status was corrupted so it’s not one of the ones listed in the query, it’ll never show up on the list table. Switching to draft mode, then re-publishing it should correct the status if it were corrupted.

If you’re reasonably confident there’s nothing outwardly wrong with this page, aside from the fact that it’s not behaving normally, it could be something your theme or a plugin is doing. As a test, try switching to a default twenty* theme and deactivating all plugins. If the page now appears in the list table, then one of the deactivated modules was interfering. Determine which by restoring them one at a time and testing after each until the problem returns.