WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 4 years ago

Last modified 4 years ago

#18402 closed enhancement (wontfix)

Confused page ordering if filter drops parent pages

Reported by: erdnah Owned by: nacin
Milestone: Priority: normal
Severity: normal Version: 3.2
Component: Posts, Post Types Keywords: ui-feedback needs-patch
Focuses: administration Cc:

Description (last modified by ocean90)

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 :)

Attachments (4)

21272-trashing-parents.jpg (205.3 KB) - added by pdclark 9 years ago.
Display of proposed changes and patched changes
21272.patch (1.5 KB) - added by pdclark 9 years ago.
Make changes recommended in report; also remove "Page Parent" text when parent is trashed.
18402.diff (1.4 KB) - added by DrewAPicture 8 years ago.
18402.2.diff (1.1 KB) - added by SergeyBiryukov 8 years ago.

Download all attachments as: .zip

Change History (27)

#1 @SergeyBiryukov
10 years ago

  • Keywords needs-patch added

#2 @erdnah
10 years ago

  • Keywords has-patch added; needs-patch removed

#3 @erdnah
10 years ago

  • Keywords needs-patch added; has-patch removed

#4 @erdnah
10 years ago

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
9 years ago

Display of proposed changes and patched changes

@pdclark
9 years ago

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

#5 @pdclark
9 years ago

  • Keywords has-patch added; needs-patch removed
  • Owner set to nacin
  • Status changed from new to reviewing

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.

#6 follow-up: @MikeHansenMe
9 years ago

  • Keywords 2nd-opinion added

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)

#7 in reply to: ↑ 6 @pdclark
9 years ago

  • Keywords ui-feedback added

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?

#8 @SergeyBiryukov
9 years ago

  • Milestone changed from Awaiting Review to 3.6

#9 @SergeyBiryukov
9 years ago

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

@DrewAPicture
8 years ago

#10 @DrewAPicture
8 years ago

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

#11 @ocean90
8 years ago

  • Milestone changed from 3.6 to Future Release

Not a regression, punting.

#12 @SergeyBiryukov
8 years ago

  • Keywords 3.7-early added

#13 @wonderboymusic
8 years ago

  • Milestone changed from Future Release to 3.7

these are all marked 3.7-early

#14 @SergeyBiryukov
8 years ago

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

#15 @nacin
8 years ago

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

#16 @nacin
8 years ago

  • Milestone changed from 3.7 to Future Release

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

#17 @nacin
8 years ago

  • Component changed from Administration to Posts, Post Types
  • Focuses administration added

#18 @chriscct7
6 years ago

  • Keywords needs-patch added; has-patch 2nd-opinion 3.7-early removed
  • Type changed from defect (bug) to enhancement
  • Version changed from 3.2.1 to 3.2

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


4 years ago

#20 @joyously
4 years ago

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.

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


4 years ago

#22 @dotrex
4 years ago

  • Resolution set to wontfix
  • Status changed from reviewing to closed

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.

#23 @ocean90
4 years ago

  • Description modified (diff)
  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.