Confused page ordering if filter drops parent pages

[erdnah]

Problem

In WordPress's page management section, the page ordering is confused if a page filter drops a page parent.

Originally, I experienced this with the User Access Manager Plugin:
​http://wordpress.org/extend/plugins/user-access-manager/
This plugin only shows allowed pages to the user.

Example

Page A
- Page A1
-- Page A1.1
-- Page A1.2

By dropping page A, the ordering becomes for example:

-- Page A1.1: Parent Page is Page A1
-- Page A1.2: Parent Page is Page A1
- Page A1: Parent Page is A

But should become:

Page A1: Parent Page is A
-- Page A1.1
-- Page A1.2

Solution

The confusion results from the function _display_rows_hierarchical
in wp-admin/includes/class-wp-posts-list-table.php which only adds pages to $top_level_pages whose parent is 0 – the wrong assumption here.

By adding pages to $top_level_pages whose parent is either 0 or doesn't exist in $pages we get a usable order:
So I added to the above-mentioned file:

function is_parent_in_pages( $parent, $pages ) {    
    foreach ( $pages as $page ) {
        if ( $page->ID == $parent ) return true;
    }
    return false;
}  

and changed _display_rows_hierarchical
from

if ( 0 == $page->post_parent )
    $top_level_pages[] = $page;
else 
    $children_pages[ $page->post_parent ][] = $page;

to

if ( 0 == $page->post_parent || !$this->is_parent_in_pages( $page->post_parent, $pages ))
    $top_level_pages[] = $page;
else
    $children_pages[ $page->post_parent ][] = $page;

And finally - in order to remove the leading dash of $top_level_pages - I removed
the $level++ in function single_row (same file) below "case 'title':"

Small change, better user experience :)

[erdnah]

Correction of my Example section:

It should become:

Page A1: Parent Page is A
- Page A1.1
- Page A1.2

(one dash only of course, not two)

[pdclark]

Display of proposed changes and patched changes

[pdclark]

Make changes recommended in report; also remove "Page Parent" text when parent is trashed.

[pdclark]

Attached a patch for the proposed changes, as well as a screenshot. It seemed awkward to me to display "Post Parent: X" when "X" had been trashed, so I also removed that text for that case. See the attached screenshot, ​21272-trashing-parents.jpg.

[MikeHansenMe]

Tested on 3.5-alpha-21751 and it works as described. My only question would be should "grandchild" then show "child" as the parent? ex (Grandchild | Parent Page : Child)

[pdclark]

Replying to MikeHansenMe:

Tested on 3.5-alpha-21751 and it works as described. My only question would be should "grandchild" then show "child" as the parent? ex (Grandchild | Parent Page : Child)

The ​code that adds the filter for "Parent Page:" to display is commented:

//sent level 0 by accident, by default, or because we don't know the actual level

Because this patch causes the child and grandchild page's hierarchical level to be set correctly (not sent in error or unknown), "Parent Page:" doesn't display for either the child or the grandchild. See the furthest-right window in ​this screenshot

Who should make the final call on this?

[SergeyBiryukov]

As noted in the ​IRC discussion, the patch would make the output more consistent with the default behavior of wp_list_pages().

[DrewAPicture]

18402.diff​ adds an @since to the method docblock and completes the @return tag.

[ocean90]

Not a regression, punting.

[wonderboymusic]

these are all marked 3.7-early

[SergeyBiryukov]

18402.2.diff​ uses wp_list_pluck() instead of introducing a new function.

[nacin]

We should probably rename the $top_level_pages variable in that case.

[nacin]

Not a regression and patch is still a bit confusing with regards to variables. Let's make sure this is right.

[joyously]

I don't like the proposed change at all. This entire change is about disguising what is actually in the database. The production version of the code is accurately conveying what the database contains.
If a Page is deleted or filtered out of the view, that does not change what the "parent" column of the post table has. Maybe on deletion, the child should be updated. I'm not sure, but having it output that there is still a parent set is a good thing. It allows the user to update it, whereas hiding it does not.

There is an odd thing, though. When I delete the parent Page, clicking on Quick Edit for the child page shows a blank in the Parent Page dropdown. This makes sense since the number from the database is not in the Page list, because the Parent is Trash. So that part is not quite accurately saying what is in the database. Of course, restoring the parent from the Trash makes everything back the way it was, so if the child had been updated on deletion, it wouldn't have been able to restore exactly back.
It seems to me that there's nothing actually wrong here.

[dotrex]

This ticket is over 6 years old and has not gained much traction at this time.

The Design team decided to close this ticket for now.