categories not appearing in admin - 'prune working set' the culprit ?

[yogomozilla]

Hi

I have some categories that when added do not appear in the "categories" admin after being added, although they do appear in the "Category Parent" select box in "Add Category".

I backtracked through the code and found function _cat_rows in wp-admin/includes/template.php that appears to display the category hierarchy in the admin.
After hacking the code I noticed that the categories missing from the hierarchy were being unset on line 87:

unset($categories[$i]); // Prune the working set

I'm not a WP hacker, so I'm not sure why these is being unset. In any case, I moved the unset as in this diff:

$ diff -U 10 template.php template.php.dev      
--- template.php        2009-02-11 22:50:47.000000000 +1100
+++ template.php.dev    2009-02-11 22:53:56.000000000 +1100
@@ -77,26 +77,26 @@
                        $num_parents = count($my_parents);
                        while( $my_parent = array_pop($my_parents) ) {
                                echo "\t" . _cat_row( $my_parent, $level - $num_parents );
                                $num_parents--;
                        }
                }

                if ( $count >= $start )
                        echo "\t" . _cat_row( $category, $level );

-               unset($categories[$i]); // Prune the working set
                $count++;

                if ( isset($children[$category->term_id]) )
                        _cat_rows( $categories, $count, $category->term_id, $level + 1, $page, $per_page );
-
+
+               unset($categories[$i]); // Prune the working set
        }

        $output = ob_get_contents();
        ob_end_clean();

        echo $output;
 }

 /**
  * {@internal Missing Short Description}}

After moving this line, the categories were shown in the hierarchy.

Here's a listing of the categories in question:

mysql> SELECT t.slug, tx.term_taxonomy_id, tx.term_id, tx.taxonomy, tx.parent, tx.count
FROM cs_wp_term_taxonomy tx
JOIN cs_wp_terms t ON t.term_id = tx.term_id
WHERE (tx.parent = 7 OR t.term_id = 7)
AND tx.taxonomy = 'category' ORDER BY t.term_id;
+-------------------+------------------+---------+----------+--------+-------+
| slug              | term_taxonomy_id | term_id | taxonomy | parent | count |
+-------------------+------------------+---------+----------+--------+-------+
| news              |                6 |       6 | category |      7 |     2 |
| navigation        |                7 |       7 | category |      3 |     0 |
| contact           |               14 |      14 | category |      7 |     0 |
| learn             |               32 |      29 | category |      7 |     2 |
| people            |               40 |      37 | category |      7 |     1 |
| development-notes |               55 |      52 | category |      7 |     0 |
| testing-123       |               56 |      53 | category |      7 |     0 |
+-------------------+------------------+---------+----------+--------+-------+
7 rows in set (0.00 sec)

The slugs 'news', 'contact' and 'people' appear in the hierarchy as children of 'navigation', the other 3 that have a parent of 'navigation' do not.

Hopefully that's enough to go on!

I'm using WP 2.7.1

[idealien]

This also prevents anybody from being able to edit any categories nested beyond 2 layers deep. They will not show up in the primary manage categories table. (CatChild in the example of catParent1 > CatParent2 > CatChild) Raising severity to high due to inability to manage core site data elements.

The table rows are built in the function cat_rows (/wp-admin/includes/template.php) which calls get_categories with an array of arguments. However, the nested categories do show up in the category_parent dropdown of the add/edit category form. This form also calls get_categories with a different set of arguments via wp_dropdown_categories (/wp-includes/category-template.php/)

A duct tape solution was proposed in the original thread on wp.org where this bug was identified (​http://wordpress.org/support/topic/224546). but the author (me) fully admits there are probably more elegant solutions that should be used to resolve this.

[Denis-de-Bernardy]

closing as dup of #9661, which has a candidate patch

[hailin]

this patch doesn't fix the root cause.