Categories are missing in admin category list when child category linked to non-existant parent id

[ShawnLunny]

I did a dive into this as our own categories were not showing up and think that this is a user experience nightmare.

I have detailed the issue here: ​http://stackoverflow.com/a/31663554/1361532

A quick google search for "wordpress missing categories" shows many threads on wordpress.org with users who never had a resolution since at least 2010.

As an additional note though the bug does not impact the actual use of the category when creating new posts, although the categories are not nested correctly, but are still usable. To be clear this bug only impacts category management.

My recommended solution to this is for the category list to show all categories in the list even if they are not properly linked AND to show (in red?) ones that are not linked correctly so they can be fixed.

[adrianosilvaferreira]

That was my first contribution to WP core. I'm now showing all terms even the ones with broken parent. Also I'm testing whether the parent exists in order to get the slug and add to the archive URL.

[boonebgorges]

@ShawnLunny Thanks for the ticket, and for the link to your WPSE thread.

@adrianosilvaferreira Thanks to you for the patches. Welcome to WP Trac :)

I am a bit confused at how the situation in question arises in the first place. As I understand it, the problem is that you have three terms A, B (child of A), and C (child of B). B is suddenly missing from the database. Now, C does not show up in category lists, and term links are incorrect.

Is that right? If so, how are we getting into this situation? Calling wp_delete_term() on B will result in C being reassigned to parent=A. I assume it arises when deleting something directly from the database, without going through wp_delete_term()? If that's the case, I'm not sure that we should be accounting for the situation: by bypassing WP's built-in attempts to preserve data integrity, you risk messing up your data, and if we paper over that messed up data, it can result in further corruption.

All this being said, if there is a way to reproduce the problem without directly access the database, then I think we need to address it - though I'd wager that the correct solution then is to prevent WP from allowing orphaned terms in the first place.

[ShawnLunny]

@boonebgorges This was submitted around 6 months ago. Let me do some inquiries with the team and get back to you after I do some digging. What's curious is how many folks have had this issue historically. I do think having a way to show the orphaned children in red or with a note would be helpful incase they did create the record directly, or if some plugin had a side effect or something they were unaware of. I don't know if that was what happened in our case but will update this thread as I find out.

[ShawnLunny]

I was unable to reproduce the issue doing basic wordpress actions so I must assume this issue came from a plugin or something else like a db query or custom code. Having the issue be dated back to a previous wordpress 2 versions back doesn't help and the issue hasn't happened again. Either way here is what I tested.

Tested criteria:

1. Created a parent-child-grand-child (A->A1->A2) category set in the category tab. Added some posts, and deleted the child (A1) without issue. Category (after page refresh which was required to see the change) realigned to the parent-child (A->A2) as appropriate. So in other words could not reproduce the issue.

2. Tested the same criteria as in 1. but created the categories on the Add a Post page without issue.

3. Tested with great-grandchildren (A->A1->A2->A3), twice with the first time removing (A1) and then an attempt with removing (A2) on the categories tab. Could not reproduce the issue.

4. Tested the same as on 3. in the Add a post page, could not reproduce the issue.

5. Tested with some sub-categories on the children (A->A1->A1a->A1a1->A1b->A2->A3->A4). Attempted to remove (A2), as well as same structure removing (A1a). Could not reproduce the issue.

6. Tested the same as 5. but on the Add a post page. Could not reproduce the issue.

7. Tried similar tests as in 3. and 5. above but instead of deleting the category tried to align it to a different parent and see if its grandchildren had an issue. For example started with (A->A1->A2->A3) and moved that sub-tree under a new category with the result (B->A1->A2->A3 i.e the new B->B1->B2->B3). Could not reproduce the issue.

So I am usure where this would leave this item? Do we add sanity checking/prevention just in case @boonebgorges ?

[adrianosilvaferreira]

@ShawnLunny I believe that the parent has been changed directly on DB. Also I did a test with wp_update_post trying to change the post_parent to any random number (lost parent), the function doesn't update the post which is totally expected.

[dlh]

I too am unable to replicate this bug through the normal routes for deleting terms.

I'm sympathetic to the bad user experience that results when a term is orphaned, especially because the children of the orphaned term disappear from the list table, too. But because there doesn't seem to be an issue in core, there are ways to restore the term's parent (like the fix described in the original SO post), and there doesn't seem to be a lot of traction with figuring out how the list table would support this case, perhaps this issue could be closed for now in favor of encouraging developers to use the core deletion functions?

[boonebgorges]

I guess I'm not totally opposed to making a change in the way we display terms in the admin in order to account for this sort of data-integrity issue, as long as the changes are fairly lightweight and targeted. Showing orphaned terms but highlighting them in red seems like a good first step. It's probably also a good idea to show them only to users who have the taxonomy's edit_terms cap, since only these users will be able to fix the problem. We should only be doing this in the admin list table, so a modification like what's suggested in taxonomy.diff​ is probably too broad.

We definitely should *not* do any automatic modification of content in the database. When a term is orphaned, there are multiple ways to "solve" the the problem, and WP can't know which one the admin wants.

[JoshuaWold]

Howdy! Wanted to followup with a few quick questions.

1. Could we have a screenshot added to this issue? I see there's one on Stack Overflow, but not sure if it's fully relevant to what's needed here. From a UX perspective it's helpful for any design folks giving feedback :)
2. Is this still an issue in the latest release of WordPress?

[gb_jlm]

@ShawnLunny Can you please add a screenshot of the issue?

[Studiofreya]

We have just encounted this bug in version 4.9.6. We copied our production database to the test-server. Did some manual insert of child categories. Than copied the database back to production. We could see the number of categories was correct in the admin panel, but the categories themselves were missing from the table.

We fixed as described in SO thread by searching for one of the missing categories and just clicking on update button. We changed nothing. The parent was set correct in the database. After updating this one child category all other children appeared in the admin panel.

[christhompsontldr]

We encountered this issue recently on one of our WordPress installs.

Following the instructions of editing a missing category, resolved the issue.

I recorded a screenshare of the process: ​https://drive.google.com/file/d/1qLJjVqmIwfl2Z6xYRekqfL5mRfiEFR9z/view?usp=sharing

[siteadvice]

This issue is still extant in Version 5.7.2. The solution (manually updating a category via the dashboard) still works.

[siteadvice]

I think it's worth pointing out that this problem occurs on the front end of the site, not just the Dashboard. As you might expect, the list of categories is only partial, no matter where you're calling it from.
In my case, I think I may have isolated the source of this issue.
Someone deleted the category "Uncategorized" (not sure if this was done via the dashboard, using a plugin or possibly via phpMyAdmin - I don't have any log of it) but they did not set a new default category in Settings > Writing. Setting a new default category seems to have fixed the problem, but it's hard to be 100% certain because the issue arises occasionally and I haven't been able to identify what triggers the results set to stop working properly.

[adrianosilvaferreira]

@siteadvice wow, 6 years ago I sent a patch to fix this issue and I can't believe it is still floating around :D