Make WordPress Core

Opened 15 years ago

Last modified 3 months ago

#8592 reopened enhancement

Private Pages not listed in the Parent dropdown

Reported by: mtdewvirus's profile mtdewvirus Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: Future Release Priority: normal
Severity: critical Version:
Component: Posts, Post Types Keywords: ux-feedback needs-testing has-patch
Focuses: administration Cc:

Description

Private pages are not available as a choice in the Parent dropdown of the Attributes module.

You should be able to create a hierarchy of private pages if you want to.

Tested with r10194.

Attachments (22)

post.php.diff (713 bytes) - added by mtekk 15 years ago.
8592-post.php.diff (974 bytes) - added by mtekk 15 years ago.
8592-post.php.2.diff (1.2 KB) - added by mtekk 15 years ago.
This has a fix so that Authors, Contributors, and Subscribers don't cause an invalid query to be made
8592-post.php.3.diff (1.0 KB) - added by mtekk 14 years ago.
uses edit_private_pages privlige instead of read_private_pages
post.php (120.9 KB) - added by bsamrajni 14 years ago.
8592-post.php.3RC1.diff (1022 bytes) - added by sillybean 14 years ago.
This patch seems to work around the problem in 3.0 RC 1.
post-r16235.diff (818 bytes) - added by sillybean 13 years ago.
Refreshing patch
8592-post.php.4.diff (837 bytes) - added by kawauso 13 years ago.
Refresh against 3.1-RC2-17315 and don't escape a static string
8592.diff (2.7 KB) - added by nacin 13 years ago.
Not tested beyond confirming it happens to work.
8592.2.diff (3.5 KB) - added by SergeyBiryukov 13 years ago.
8592.3.diff (4.0 KB) - added by SergeyBiryukov 13 years ago.
8592.4.diff (4.0 KB) - added by SergeyBiryukov 13 years ago.
8592-dropdowns.diff (903 bytes) - added by sillybean 13 years ago.
Adds the page's status in admin dropdown menu
8592.patch (5.2 KB) - added by johnjamesjacoby 13 years ago.
Refresh + combination of patches
meta-boxes.diff (1023 bytes) - added by davecpage 13 years ago.
Allow filtering the args for parent dropdown on Page Attributes metabox
8592.2.patch (4.5 KB) - added by SergeyBiryukov 13 years ago.
8592.3.patch (3.3 KB) - added by SergeyBiryukov 12 years ago.
list-pages-args.diff (641 bytes) - added by sillybean 11 years ago.
Allow arguments to be filtered in wp_list_pages() and wp_dropdown_pages()
8592-parent-status-check.diff (6.3 KB) - added by sillybean 11 years ago.
Force children of unpublished parent pages to inherit status. Includes new argument filters for wp_list_pages() and wp_dropdown_pages().
8592.5.diff (9.1 KB) - added by sillybean 11 years ago.
Add filters to args for wp_list_pages() and wp_dropdown_pages() except on Reading Settings; force child pages of unpublished parents to inherit status and password
8592.5.fork.diff (4.8 KB) - added by plocha 10 years ago.
8592.6.diff (699 bytes) - added by sillybean 7 years ago.
minimal argument filters for wp_list_pages() and wp_dropdown_pages()

Download all attachments as: .zip

Change History (268)

#1 in reply to: ↑ description @bethallen
15 years ago

Replying to mtdewvirus:

Private pages are not available as a choice in the Parent dropdown of the Attributes module.

You should be able to create a hierarchy of private pages if you want to.

Tested with r10194.

Also, pending pages are not shown in the drop down either. I use these to set up a theme for a customer to be able to configure their own child pages. Now it is broken!

#2 @mark8barnes
15 years ago

  • Component changed from General to Administration
  • Keywords child added
  • Priority changed from normal to high
  • Severity changed from normal to major

This is a bug that really does need to be fixed. I presume the problem is with the parent_dropdown function in template.php, but I don't understand the code there.

#3 @PeteHoliday
15 years ago

parent_dropdown is not the function responsible for that particular dropdown.

The one you're looking for is wp_dropdown_pages, which is defined in wp-includes/post-template.php. That is just a wrapper for get_pages(), however, which is defined in /wp-includes/post.php.

That function should probably include logic to display private pages for admins and, ideally, running the query through a pages_where filter similar to the one used for posts.

#4 @vinceger
15 years ago

Is there a solution already for this problem, or is it fixed in the newest beta?

#5 @DD32
15 years ago

Is there a solution already for this problem, or is it fixed in the newest beta?

No. When the functionality is offered in the latest nightly, this ticket will be closed.

If you want to be notified of anything related to this, you can check the CC button.

#6 @vinceger
15 years ago

  • Cc vinceger added

Thanks DD32 for the feedback, I do hope a solution comes fast because I'm stuck here. Ok CC button I will do this. Thanks again !

#7 @Viper007Bond
15 years ago

  • Keywords needs-patch added; parent pages child removed

@mtekk
15 years ago

#8 @mtekk
15 years ago

  • Keywords has-patch added; needs-patch removed

I took a quick look at this, try this patch out. Not sure if it is kosher to call is_admin() within post.php, but this seems to work.

#9 @mtekk
15 years ago

Thinking more about this, maybe we should add an option called page_types, which would default to contain just 'publish', but could be a comma delimited list. Then in wp_dropdown_pages we can tell it to include 'publish' and 'private' pages.

#10 @mtekk
15 years ago

  • Keywords dev-feedback added

I suppose it'd probably be a good idea to be able to let drafts be parents as well. Think we need some dev feedback on this.

#11 @jeremyduffy
15 years ago

  • Cc jeremyduffy added

Any progress on this? This is kind of a big issue that's been festering for a while. I've left a lot of my private pages alone because I don't want to break their hierarchy, but I can't last much longer.

#12 @mtekk
15 years ago

jeremyduffy, you can try the patch that I attached 5 days ago, it should work. If you could test it and verify that it works for you, then we can add the 'tested' tag to the keywords. I just think we should get some dev feedback as there may be a better way of implementing it.

@mtekk
15 years ago

#14 @mtekk
15 years ago

ryan, ok I modified that bit to be more like the linked code. See new patch " 8592-post.php.diff"

#15 @vinceger
15 years ago

mtekk,

Next problem after your modification:

  • Now all my child pages of a private Parent page will show up in the sidebar, before all child pages of a private parent page would NOT show up in the sidebar?

Any idea how to solve this ?

#16 @vinceger
15 years ago

Pages or vissible but the drop-down menu (admin) doesnt look like it shoud be

#17 @mtekk
15 years ago

That is only when you are logged in (and have permissions to see them), if you log off you will not see them. Users that are not logged in, or do not have the permissions to see private pages will not see them.

#18 @vinceger
15 years ago

mtekk,

I checked with another login.

With this login the sidebar is totaly empty ??

#19 @mtekk
15 years ago

I'm tracking that problem down right now, will have patch soon.

@mtekk
15 years ago

This has a fix so that Authors, Contributors, and Subscribers don't cause an invalid query to be made

#20 follow-ups: @mtekk
15 years ago

Yeah, I forgot to add $user_ID as a global at the beginning of the function.

#21 in reply to: ↑ 20 ; follow-up: @vinceger
15 years ago

Replying to mtekk:

Yeah, I forgot to add $user_ID as a global at the beginning of the function.

mtekk,

You're The Man !

Is there any possibility doing the same for admin? If I want to change now I have to scroll for ages. Before (older version) they didn't pop up also)

Maybe you can have a look at the dashboard also, notice the scroll down menu-bar, the bar goes out of the frame.

For the rest, thank you very much I really appreciate this ! For now I don't see any problems.

#22 in reply to: ↑ 21 ; follow-up: @mtekk
15 years ago

Replying to vinceger:

Replying to mtekk:

Yeah, I forgot to add $user_ID as a global at the beginning of the function.

mtekk,

You're The Man !

Is there any possibility doing the same for admin? If I want to change now I have to scroll for ages. Before (older version) they didn't pop up also)

Maybe you can have a look at the dashboard also, notice the scroll down menu-bar, the bar goes out of the frame.

For the rest, thank you very much I really appreciate this ! For now I don't see any problems.

I'm not sure I quite understand what you are saying/asking. In the dashboard when editing a page the parent attribute should show all pages now except those that would cause a hierarchical loop (e.g. a page being it's own parent, or a parent being a child of one of it's own children or grandchildren). If you are talking about a styling issue with the dropdown, I think that's already part of separate bug (I remember seeing it recently).

#23 in reply to: ↑ 22 @vinceger
15 years ago

Replying to mtekk:

I'm not sure I quite understand what you are saying/asking. In the dashboard when editing a page the parent attribute should show all pages now except those that would cause a hierarchical loop (e.g. a page being it's own parent, or a parent being a child of one of it's own children or grandchildren). If you are talking about a styling issue with the dropdown, I think that's already part of separate bug (I remember seeing it recently).

Im referring to the blog itself, if I login with permission I can see al pages in the sidebar same problem as before with no permission and you solved already.

I have about 600 pages as child pages and prefer not to see them if logged and reading the blog. (I would only like to see them in the dashboard, to change etc.)

Thank's for the drop-down bug, I will search for it.

#24 @Denis-de-Bernardy
15 years ago

  • Keywords dev-feedback removed

-1. patch should remove the where clause on the status when a user can view all private stuff.

#25 follow-ups: @Denis-de-Bernardy
15 years ago

  • Keywords needs-patch added; has-patch removed
  • Milestone changed from 2.8 to Future Release

also, there is the potential issue when a page is public with a private parent. it seems to imply that private pages should always get listed, regardless of whether the user can view them or not.

moving to Future pending new patch

#26 in reply to: ↑ 25 ; follow-up: @mtekk
15 years ago

Replying to Denis-de-Bernardy:

-1. patch should remove the where clause on the status when a user can view all private stuff.

See the code Ryan linked to, the patch mimics that behavior. If we should remove the where clause entirely from this area, then the same should probably happen there as well.

Replying to Denis-de-Bernardy:

also, there is the potential issue when a page is public with a private parent. it seems to imply that private pages should always get listed, regardless of whether the user can view them or not.

moving to Future pending new patch

I'll test this tonight, but private pages still should not show up with the patch unless the user has permissions to see them.

#27 in reply to: ↑ 26 ; follow-ups: @Denis-de-Bernardy
15 years ago

Replying to mtekk:

I'll test this tonight, but private pages still should not show up with the patch unless the user has permissions to see them.

Err. They should. Or at least the current parent pages should show. Suppose user A publishes a private page that gets used as a stub. And user B publishes a public page whose parent is the private page.

#28 in reply to: ↑ 27 ; follow-ups: @mtekk
15 years ago

Replying to Denis-de-Bernardy:

Replying to mtekk:

I'll test this tonight, but private pages still should not show up with the patch unless the user has permissions to see them.

Err. They should. Or at least the current parent pages should show. Suppose user A publishes a private page that gets used as a stub. And user B publishes a public page whose parent is the private page.

I'm not sure if that is really part of this bug, it's more of a behavior question that is opened by any fix to this bug. All child pages, if "public" should really inherit their status from their parent (otherwise what's the point of having them hierarchical if they do not). With the patch I submitted you can have future pages be parents as well, but again, their children should really not be allowed to be public until the parent is (otherwise you'll get a "chicken and egg paradox"). Neither of these were problems before as you "couldn't" have a non-published page be a parent.

#29 in reply to: ↑ 28 @bethallen
15 years ago

Replying to mtekk:

Replying to Denis-de-Bernardy:

Replying to mtekk:

I'll test this tonight, but private pages still should not show up with the patch unless the user has permissions to see them.

Err. They should. Or at least the current parent pages should show. Suppose user A publishes a private page that gets used as a stub. And user B publishes a public page whose parent is the private page.

I'm not sure if that is really part of this bug, it's more of a behavior question that is opened by any fix to this bug. All child pages, if "public" should really inherit their status from their parent (otherwise what's the point of having them hierarchical if they do not). With the patch I submitted you can have future pages be parents as well, but again, their children should really not be allowed to be public until the parent is (otherwise you'll get a "chicken and egg paradox"). Neither of these were problems before as you "couldn't" have a non-published page be a parent.

-- Here is what has happened to me. I created a website for someone under 2.5 or so. I used private pages to create sets of child pages. For example: Current events is page id 2. I can create a bunch of child pages that are public for current events.

The template I wrote for this site does not show all pages the same way in the sidebar. I can write code, for example, that only shows the children of page id 2 in my sidebar. At least that is how it worked until 2.7 changed it. So the site got hosed as soon as someone edited one of those child pages. They could no longer make the private or draft page the parent as it worked originally.

The philosophy that child pages should inherit parent page status is a valid argument, but the latest version broke the way something worked in the older version.

#30 in reply to: ↑ 28 ; follow-up: @Denis-de-Bernardy
15 years ago

Replying to mtekk:

With the patch I submitted...

My only concern with it (and I take it the core devs will have the same) has to do with performance. Basically, if a user is admin, he should be able to view it all without any extra db check. Else, you're running a query with scores of OR clauses on the status, which is very slow.

#31 in reply to: ↑ 30 @mtekk
15 years ago

Replying to Denis-de-Bernardy:

Replying to mtekk:

With the patch I submitted...

My only concern with it (and I take it the core devs will have the same) has to do with performance. Basically, if a user is admin, he should be able to view it all without any extra db check. Else, you're running a query with scores of OR clauses on the status, which is very slow.

I agree with the idea. However, when I tried to implement it I think I ran into an issue. It has to do with who we actually want to be able to see what pages in the results from get_pages (in the admin dropdown or elsewhere).

#32 follow-up: @Denis-de-Bernardy
15 years ago

right. and thus, it might make sense to do this instead:

where ( post_status = 'publish' or post_parent = $post->post_parent )

that way, the current behavior is kept around, without the bug you (or I) bumped into.

alternatively, there is a function somewhere that might manages this in the sense that it outputs the correct sql. not entirely sure of its name though. it's likely used in wp-includes/query.php and other template functions.

#33 in reply to: ↑ 32 @mtekk
15 years ago

Replying to Denis-de-Bernardy:

right. and thus, it might make sense to do this instead:

where ( post_status = 'publish' or post_parent = $post->post_parent )

that way, the current behavior is kept around, without the bug you (or I) bumped into.

That would partially fix this bug, however administrators wouldn't be able to make pages children of private pages of editors, or other administrators (not sure if this is a problem or not, however if an admin can change page ownership the should be able to use it as a parent, even if it is private).

From http://codex.wordpress.org/Roles_and_Capabilities it looks like we can give anyone with edit_others_pages capabilities the full page list (ends up being administrators and editors). Seems weird that only admins and editors can create pages. I guess just using a blank would work if we check for the edit_others_pages (or maybe even just the read_private_pages) capability.

I guess the other question is do we want these unpublished pages showing up outside of the dashboard for users with the proper privileges (the answer to this may be in the code from query.php that Ryan pointed to (it's now a few lines above the line he linked to))?

#34 in reply to: ↑ 25 @mark8barnes
15 years ago

Replying to Denis-de-Bernardy:

also, there is the potential issue when a page is public with a private parent. it seems to imply that private pages should always get listed, regardless of whether the user can view them or not.

Public pages used to inherit their parents' privacy until 2.5 beta 1. This changed in 2.5RC1. When I reported the change, I got a wontfix, with the developers saying:

"If user want a page to be private, he should set it to private. Inheriting the "private" status can be tricky and misleading"

But regardless of the inheritance issues, we really do need to be able to set pages as children of hidden/future posts.

I suggest that when a parent is hidden, the dropdown on the child is pre-selected to "private", and you are not allowed to change it to "publish".

Likewise with future pages, the child page should 'inherit' the publish time of it's parent, and you should be allowed to set the time later, but not earlier than the parent.

Stopping the user doing what is illogical seems to be the only way forward here.

#35 follow-up: @Kanuck54
15 years ago

  • Cc Kanuck54 added

Just adding myself to the CC list, as this is a pretty severe regression for me.

I used to create a hierarchy of pages with the uppermost parent kept in draft mode; "publish" the pages one by one as they were completed; and then make the whole thing public by publishing the parent. (I think. I could be remembering wrong.)

Anyway, this is obviously not possible right now. Bit of a pain.

I suggest that when a parent is hidden, the dropdown on the child is pre-selected to "private", and you are not allowed to change it to "publish".

Two cents: the only problem I see with this is that it would then be highly troublesome to make a private page with many private descendants public. Adding a bulk action would reduce the pain here, of course.

#36 in reply to: ↑ 35 @mtekk
15 years ago

Replying to Kanuck54:

I suggest that when a parent is hidden, the dropdown on the child is pre-selected to "private", and you are not allowed to change it to "publish".

Two cents: the only problem I see with this is that it would then be highly troublesome to make a private page with many private descendants public. Adding a bulk action would reduce the pain here, of course.

I agree and that's why I think child pages should actually default to the currently hidden "inherit" option. That way you can launch many pages at once by publishing the parent.

#37 @mcrea1248
15 years ago

  • Cc mcrea1248 added

#38 @Denis-de-Bernardy
15 years ago

  • Milestone changed from Future Release to 2.9

#39 @vinceger
15 years ago

  • Version changed from 2.7 to 2.8

Upgraded to 2.8

  • same problem -

editing 8592-post.php.2.diff from mtekk
OK again . . .

#40 follow-up: @Denis-de-Bernardy
15 years ago

@vincegerg: please upload the amended patch

#41 in reply to: ↑ 40 @vinceger
15 years ago

Replying to Denis-de-Bernardy:

@vincegerg: please upload the amended patch

File already attached by mtekk, see top of page.

#42 @Denis-de-Bernardy
15 years ago

  • Keywords has-patch added; needs-patch removed

oh, sorry. I was trying to apply this to wp-includes.

#43 @vinceger
15 years ago

  • Version changed from 2.8 to 2.8.1

#44 @vinceger
15 years ago

  • Version changed from 2.8.1 to 2.8.2

#46 @vinceger
15 years ago

  • Version changed from 2.8.2 to 2.8.4

#47 @j_cockin@…
15 years ago

Hello.

I have confirmed that the patch (v2) works as expected in WordPressMU.

What has to happen to get this code into the next version of WP?

#48 @rwbbonn
15 years ago

  • Cc rwbbonn added

#49 @Yves
14 years ago

  • Cc Yves added

Very much interested in the resolution of this bug. This is one more step to a proper CMS like management of content in core.

#50 @sillybean
14 years ago

  • Cc sillybean added

#51 @cnorris23
14 years ago

Version 2 of the diff appears to be working as of revision 1265 of trunk. Tested under all user roles.

#52 follow-up: @deoli
14 years ago

  • Cc deoli added
  • Version changed from 2.8.4 to 2.8.5

Just a quick hello from me. I'm using the patch on WP 2.8.5 and I haven't had any problems up to now. I hope this is still being worked on... or that it will be included in future WP updates, it would make work on my current project much easier. Thanks!

#53 in reply to: ↑ 52 ; follow-up: @vinceger
14 years ago

Replying to deoli:

Just a quick hello from me. I'm using the patch on WP 2.8.5 and I haven't had any problems up to now. I hope this is still being worked on... or that it will be included in future WP updates, it would make work on my current project much easier. Thanks!

Just updated to 2.8.5 and now it's working without the patch ? Is this problem fixed already in version 2.8.5 ?

#54 in reply to: ↑ 53 ; follow-up: @mtekk
14 years ago

Replying to vinceger:

Replying to deoli:

Just a quick hello from me. I'm using the patch on WP 2.8.5 and I haven't had any problems up to now. I hope this is still being worked on... or that it will be included in future WP updates, it would make work on my current project much easier. Thanks!

Just updated to 2.8.5 and now it's working without the patch ? Is this problem fixed already in version 2.8.5 ?

Nope, still broken in unpatched versions of 2.8.5. Patch still works with r12135 (haven't synced with SVN trunk for a week or so).

#55 in reply to: ↑ 54 ; follow-up: @sillybean
14 years ago

Still working as of r12181. I believe this patch also fixes #6939.

#56 in reply to: ↑ 55 ; follow-up: @vinceger
14 years ago

Replying to sillybean:

Still working as of r12181. I believe this patch also fixes #6939.

You're right still working. (also in 2.8.6)

Only one problem remains - if I log in as admin all the child-pages are also there on my blog, is there any patch for this ?

#57 in reply to: ↑ 56 ; follow-up: @mtekk
14 years ago

Replying to vinceger:

Replying to sillybean:

Still working as of r12181. I believe this patch also fixes #6939.

You're right still working. (also in 2.8.6)

Only one problem remains - if I log in as admin all the child-pages are also there on my blog, is there any patch for this ?

If you have permissions to see the pages, then they should show up (even if they are private or future).

#58 in reply to: ↑ 57 @vinceger
14 years ago

Replying to mtekk:

Replying to vinceger:

Replying to sillybean:

Still working as of r12181. I believe this patch also fixes #6939.

You're right still working. (also in 2.8.6)

Only one problem remains - if I log in as admin all the child-pages are also there on my blog, is there any patch for this ?

If you have permissions to see the pages, then they should show up (even if they are private or future).

Thank sillybean,

I thought that they only had to show up in the 'dashboard' not when reading the blog if logged in.

Thanks again!

#59 @ryan
14 years ago

  • Milestone changed from 2.9 to Future Release

#60 @sillybean
14 years ago

Nooooo, don't punt! This has been tested, works great in the latest beta, and fixes two problems at once!

#61 @sillybean
14 years ago

  • Keywords tested added
  • Version changed from 2.8.5 to 2.9

#62 @mark8barnes
14 years ago

I agree with sillybean. What is the point of asking for community involvement in developing and testing patches if they're then ignored?

#63 follow-up: @Denis-de-Bernardy
14 years ago

  • Keywords needs-patch added; has-patch tested removed

patch potentially introduces loads of bugs:

  • the check on is_admin() seems kind of weird.
  • $author_query is pointless if the author can view private pages and/or edit others' page
  • I'm pretty sure the current parent needs to be passed to the query. (haven't tested, but if a non-privileged author creates a page whose parent is owned by someone else and becomes private or pending, what happens when he edits it?)

#64 in reply to: ↑ 63 @mtekk
14 years ago

Replying to Denis-de-Bernardy:

patch potentially introduces loads of bugs:

  • the check on is_admin() seems kind of weird.
  • $author_query is pointless if the author can view private pages and/or edit others' page
  • I'm pretty sure the current parent needs to be passed to the query. (haven't tested, but if a non-privileged author creates a page whose parent is owned by someone else and becomes private or pending, what happens when he edits it?)
  1. Agree, but we need to make sure in the admin/dashboard, any user capable of writing a page and make it a child of anyone's future, pending, or draft page.
  1. Authors can't create, publish, or edit pages. Only editors can, and AFAIK editors can access anything private (or so says edit_private_pages ability).
  1. Ties in with my thought that the page inheritance model of WordPress needs to be rethought. At the moment, it is not very useful in a single site, multiple user setup.

I'm alright with this getting punted, IFF (if and only if) we get one of the core developers to give some input on fixing the page inheritance model.

After looking at get_pages, it looks like we may be able to place this higher up, where it belongs, which will completely eliminate #2 (and allow us to use read_private_pages again instead of edit_private_pages), but I don't remember where that was.

I'm attaching what I have on my current testbed, it's different than the code in patch 2 (uses edit_private_pages).

@mtekk
14 years ago

uses edit_private_pages privlige instead of read_private_pages

#65 @vinceger
14 years ago

Thanks for the update mtekk !!!!!

#66 @jcollier
14 years ago

  • Cc jcollier added

#67 @hakre
14 years ago

  • Keywords has-patch added; needs-patch removed

#68 @hakre
14 years ago

  • Milestone changed from Future Release to 3.0

#69 follow-up: @Denis-de-Bernardy
14 years ago

  • Keywords needs-patch added; has-patch removed

see also #11697, and I don't like the patch much. it'll slow the query down (#11375). also, even if the author cannot edit a private parent page, that page should remain available as a potential parent. in particular when it already is the parent.

#70 in reply to: ↑ 69 @mtekk
14 years ago

Replying to Denis-de-Bernardy:

see also #11697, and I don't like the patch much. it'll slow the query down (#11375). also, even if the author cannot edit a private parent page, that page should remain available as a potential parent. in particular when it already is the parent.

The only thing I'm going to say on #11697 is I feel it is a way to make this issue go away, along with others, with out actually fixing them (you even admitted to it in the comments on #11697).

Anyways, the proper permission level for this problem does not exist at this time (AFAIK). Implemented as is through the patch, most setups would only notice the proper behavior, only editors and admins can access, create, or modify pages. However, in setups with more user levels this could be a problem. So it is not a complete solution.

#71 @voyagerfan5761
14 years ago

  • Cc WordPress@… added

#72 @sillybean
14 years ago

See also #4711.

#73 in reply to: ↑ 20 @sillybean
14 years ago

mtekk, I've worked your diff2 into a <a href="http://wordpress.org/extend/plugins/private-suite/">plugin</a> of mine that had a lot of other privacy-related features. Your later patch has better logic, but this one fixes the front end and the back end all at once. My code is clunky as hell, but I desperately needed to stop patching core and move this into a plugin.

#74 @Denis-de-Bernardy
14 years ago

  • Keywords bug-hunt added

#75 @Denis-de-Bernardy
14 years ago

  • Keywords featured added; bug-hunt removed

#76 @bsamrajni
14 years ago

  • Owner changed from anonymous to bsamrajni
  • Status changed from new to assigned

#77 @bsamrajni
14 years ago

  • Cc bsamrajni added
  • Keywords has-patch added; needs-patch removed

I have tried fixing this bug.
Now I'm able to get drafts ang private pages in the dropdown.
All I did was a change in a query in post.php
$query = "SELECT * FROM $wpdb->posts $join WHERE (post_type = 'page' AND (post_status = 'publish' OR post_status = 'draft')) $where ";

@bsamrajni
14 years ago

#78 follow-up: @vinceger
14 years ago

  • Version changed from 2.9 to 2.9.2

Still not fixed in 2.9.2 . . . .

#79 @dd32
14 years ago

  • Version changed from 2.9.2 to 2.7

Please do not change the version tag. The Version tag allows Developers to know when the bug was first noticed.

Since this ticket is open, We know that the bug exists in 2.7~Latest Nightly.

#80 in reply to: ↑ 78 @bsamrajni
14 years ago

Replying to vinceger:

Still not fixed in 2.9.2 . . . .

Hey..I fixed it.I would be glad if u check out that and report me.

#81 follow-up: @Victor Delta
14 years ago

  • Cc Victor Delta added

bsamrajni
Thanks. This bug is really annoying - I'd like to try out your fix. As a newbie, can I just confirm that I need to download your updated post.php file above and replace the existing one. Is that all one has to do? Thanks.

#82 in reply to: ↑ 81 @cnorris23
14 years ago

Replying to Victor Delta:

bsamrajni
Thanks. This bug is really annoying - I'd like to try out your fix. As a newbie, can I just confirm that I need to download your updated post.php file above and replace the existing one. Is that all one has to do? Thanks.

If you're referring to bsamrajni's most recent attachment, then yes you can just replace your existing post.php with the one here. For all the other files attached to this ticket, and most others you find on Trac, this will not work.

#83 follow-up: @mtekk
14 years ago

bsamrajni,

Why did you attach a full post.php rather than a .diff? Also you fix trashes permissions (sort of). I don't see this going anywhere for a while, no matter how annoying it may be (a real fix requires some rethinking of the permission system for pages, and I don't see that making 3.0).

#84 @dd32
14 years ago

  • Keywords early added; featured removed
  • Milestone changed from 3.0 to 3.1

Due to no traction on this, I'm moving this to 3.1 early.

A few options have been outlined, including relying on edit_private_pages & read_private_pages, but i'm not sure any are actually solid for inclusion due to the change in output from the function in question.

#85 @rooodini
14 years ago

The same problem exists for draft pages (i.e. draft pages are not listed in the parent dropdown).

I'm wondering if (due to permissions) the draft pages version of this problem might be easier to fix?

#86 follow-up: @rooodini
14 years ago

New ticket created for the draft page version of this problem: #12890

#87 @cnorris23
14 years ago

  • Cc cnorris23+wordpress@… added

#88 in reply to: ↑ 83 @icc97
14 years ago

Replying to mtekk:

bsamrajni,

Why did you attach a full post.php rather than a .diff? Also you fix trashes permissions (sort of). I don't see this going anywhere for a while, no matter how annoying it may be (a real fix requires some rethinking of the permission system for pages, and I don't see that making 3.0).

Thanks @bsamrajni. I did find the whole post.php file useful as I could just apply it to my site directly.

@mtekk is right though - when you list posts / pages after putting your fix in, it displays all the draft ones as well, even when you're not logged in. On top of that it only works for draft and not private pages.

However it does provide a useful work around, until a correct fix is found. You can use the exclude pages http://wordpress.org/extend/plugins/exclude-pages/ or set the pages to be private to exclude them.

@sillybean
14 years ago

This patch seems to work around the problem in 3.0 RC 1.

#89 @mikemcmurray
14 years ago

  • Cc mikemcmurray added

#90 @vinceger
14 years ago

Thank you sillybean, the patch indeed seems to work around the problem in 3.0 !

#91 in reply to: ↑ 86 @probablepossible
14 years ago

  • Version changed from 2.7 to 3.0

Replying to rooodini:

New ticket created for the draft page version of this problem: 12890

New ticket created for the pending/scheduled version of this problem; 14441

#92 follow-up: @westi
14 years ago

  • Version changed from 3.0 to 2.7

Please don't change the version something was reported in to a newer version - we lose the information about how old an issue is then.

#93 in reply to: ↑ 92 @probablepossible
14 years ago

Replying to westi:

Please don't change the version something was reported in to a newer version - we lose the information about how old an issue is then.

Whoops! I apologise for the gaffe!

@sillybean
13 years ago

Refreshing patch

#94 @nacin
13 years ago

  • Keywords early removed
  • Milestone changed from Awaiting Triage to Future Release
  • Priority changed from high to normal

@kawauso
13 years ago

Refresh against 3.1-RC2-17315 and don't escape a static string

#95 @nacin
13 years ago

  • Keywords needs-patch added; has-patch removed

I don't think this logic belongs in get_pages(). It's too low in the stack.

Instead, get_pages() should be allowed to accept an array for post_status. Each status should probably be verified before then going into an IN() into the query.

Then the parent dropdown can call get_pages() and request private pages as well -- the cap check would need to occur at that level.

@nacin
13 years ago

Not tested beyond confirming it happens to work.

#96 @nacin
13 years ago

  • Keywords has-patch 3.2-early added; needs-patch removed
  • Owner changed from bsamrajni to nacin
  • Status changed from assigned to reviewing

This has been sitting around long enough. Accepting for potential 3.2 inclusion. Please review/test.

#97 @SergeyBiryukov
13 years ago

8592.2.diff fixes several issues:

  1. A warning in Quick Edit:
    Warning: mysql_real_escape_string() expects parameter 1 to be string, array given in .../wp-includes/wp-db.php on line 791
    
  2. Quick Edit was still showing only published pages.
  3. The change in wp_dropdown_pages() seems unnecessary.

#98 @nacin
13 years ago

For issue 1, I forgot to cast. Thanks for the fix. Might still prefer my solution with a string cast, to avoid an unnecessary IN when you pass array('publish'). We're pretty lame at trying to use = where it can speed things up, though I'm also not sure how current versions of MySQL handle that optimization underneath.

Same with issue 2, thanks. Issue 3: The change in wp_dropdown_pages() was indeed unnecessary, as the whole thing gets passed to get_pages(), but I think it's good to be explicit about what is accepted.

#99 @SergeyBiryukov
13 years ago

Thanks, revised the patch.

#100 @JohnNull
13 years ago

To also allow scheduled pages to be parents, and to support this in the Quick Edit as well as Edit Page areas, it appears that the post_status array must include 'future' as well in the changes to class-wp-posts-list-table.php and meta-boxes.php.

Are there other statuses that should be considered as well?

Edited: this is in response to 8592.3.diff posted by the wonderful SergeyBiryukov

Last edited 13 years ago by JohnNull (previous) (diff)

#101 @sillybean
13 years ago

I think this fixes #4711. Will do some extensive testing next week.

#102 @sillybean
13 years ago

I tested this patch on a site where I have a deep hierarchy of private pages and a bunch of users a) creating more pages in that hierarchy, and b) viewing lists of the private pages on the front end.

The patch solves the dropdown issue beautifully, but I'm looking at resolving #4711 and #6939 as well as this ticket. Casting $post_status as an array causes problems if you've passed more than one status in an argument string -- e.g. wp_list_pages('post_status=publish,private') returns false because the resulting array doesn't pass the array_diff() test with get_post_stati().

If, in wp-includes/post.php, instead of:

$post_status = (array) $post_status;


we do this:

if (!is_array($post_status))
	$post_status = explode(',', $post_status);

... then it becomes possible to call wp_list_pages() with more than one status, and that warning in Quick Edit is still taken care of.

#103 @nacin
13 years ago

Ah, yes, I forgot about supporting query string calls. I should have seen that though, because WP_Query only accepts comma-delimited, and not an array of statuses. We should be consistent. Personally, I think both should be supported in both places.

#104 @sillybean
13 years ago

Fixing the dropdown brings up the question of what to do with the post status of a new page created under a private parent. Nacin, after you left the powwow between sessions in Phoenix, Ryan Duff and I came up with this suggestion: When the private parent is chosen, do a bit of JS to change the current page's status to private (/draft/future/etc.), gray out the visibility and/or status sections and disable their Edit links, and maybe put a tiny-print message in that section that the status cannot be changed unless a public parent has been chosen.

#105 @nacin
13 years ago

  • Type changed from defect (bug) to feature request

The problem there is then the private status isn't properly communicated in the dropdown.

I know this ticket has been open for years, but it's time it gets moved to a feature request, because that is what it is. There are a number of UX considerations here, which is why the functionality doesn't exist yet.

#106 @sillybean
13 years ago

Yes, any pages that aren't public really ought to be noted as such in the dropdown, as they are in the Edit page lists.

#107 @sillybean
13 years ago

Not sure I agree that this is a feature request; it's definitely a problem with an existing feature, even though fixing it properly is going to involve omg-bbq levels of UX work on the page Edit screen. The underlying get_pages() problem is almost taken care of. What if we finish that up, then start a new feature request ticket for the UI changes to make it clear what's going on with the newly included page statuses?

#108 @SergeyBiryukov
13 years ago

Updated the patch as per sillybean's correction.

Should we also allow scheduled pages to be parents, as suggested by JohnNull?

@sillybean
13 years ago

Adds the page's status in admin dropdown menu

#109 @sillybean
13 years ago

Added a patch to include non-publish statuses in the admin dropdown menus.

I like the idea of including scheduled pages in this project, but I skipped them for this patch.

#110 @vinceger
13 years ago

For me i.c.w. WordPress 3.1 http://core.trac.wordpress.org/attachment/ticket/8592/post-r16235.diff (added by sillybean) works A-Okay. Others won't ?

Last edited 13 years ago by vinceger (previous) (diff)

#111 @nacin
13 years ago

  • Keywords 3.2-early removed
  • Milestone changed from Future Release to 3.2

At the very least, let's get this logic into get_pages(). Closed #17056 as a duplicate.

#112 @johnjamesjacoby
13 years ago

Attached patch is a combo of Segey and sillybean. Rather than hard-coding the statuses, I took a cue from the post-row post_state logic, and added all post states to the drop down.

@johnjamesjacoby
13 years ago

Refresh + combination of patches

#113 @nacin
13 years ago

In [17889]:

Allow get_pages() to take multiple post statuses. see #8592.

#114 @nacin
13 years ago

  • Milestone changed from 3.2 to Future Release

I need to punt the rest of this, but that should allow a plugin to implement the rest without bad hacks.

#115 @wikichaves
13 years ago

  • Cc wikichaves added

#116 @inge12
13 years ago

  • Cc inge12 added

Whew! I see that this bug has been crawling around for years!

I sure hope that "Future Release" comes up soon -- like before 3.2!

Even a plugin would be nice as a stop-gap. I see the patch, but am not sure where to insert it -- shows you how much I need the plugin or updated Wordpress release. ;)

Thanks, guys, for all your hard work. I just ran into this because I could not make private pages hierarchial and posted in the Requests and Feedback forum. (http://wordpress.org/support/topic/private-parent-pages)

#117 @husobj
13 years ago

  • Cc ben@… added

#118 follow-up: @sillybean
13 years ago

JJJ, your updated patch to page_attributes_meta_box() isn't working for me anymore in 3.1.3 -- the parent dropdown disappears entirely. If it's working in trunk, though, I'll just upgrade to the nightly.

#119 in reply to: ↑ 118 ; follow-up: @vinceger
13 years ago

Replying to sillybean:

JJJ, your updated patch to page_attributes_meta_box() isn't working for me anymore in 3.1.3 -- the parent dropdown disappears entirely. If it's working in trunk, though, I'll just upgrade to the nightly.

sillybean,

I always used your patch ( http://core.trac.wordpress.org/attachment/ticket/8592/post-r16235.diff ) and this worked A-Okay for me. Bad enough i's not working anymore with WordPress 3.2.

Is there a new or other patch like this one but will work with the new WP version ?

Thanks in advance !

Version 1, edited 13 years ago by vinceger (previous) (next) (diff)

#120 @vinceger
13 years ago

  • Keywords needs-patch added; has-patch removed

#121 @vinceger
13 years ago

  • Keywords has-patch needs-refresh added; needs-patch removed

#122 in reply to: ↑ 119 @sillybean
13 years ago

Replying to vinceger:

I'm sure my old patch is too outdated to work anymore. The newer patches do work (turned out to be some weird glitch in the 3.1.3 site I was talking about), but not in the same way. You have to be explicit about which statuses you want in your loops. For example, I have this in several page templates where I need the private pages to appear:

<?php
global $wp_query;
query_posts( array_merge( array( 'post_status' => 'publish,private' ), $wp_query->query ) );
?>

#123 @vinceger
13 years ago

Thank's for the QUICK feedback sillybean !!

Last edited 13 years ago by vinceger (previous) (diff)

#124 @vinceger
13 years ago

Just upgraded to WordPress 3.2.1 and tried all the patches above but non of them work, some of them already implemented in 3.2.1.

The problem I have is wen I change a page, or create a new one, private pages are not available as a choice in the Parent dropdown of the Attributes module.

Please help....

@davecpage
13 years ago

Allow filtering the args for parent dropdown on Page Attributes metabox

#125 @davecpage
13 years ago

  • Cc davecpage added

Just ran across this issue for a client. They wanted to be able to structure a large quantity of pages, with the pages still marked as Draft or Pending, but the parent page dropdowns shown within the Quick Edit or Page Attribute metabox would only show Published pages.

Fortunately there is a filter on the arguments used for the Quick Edit called 'quick_edit_dropdown_pages_args' which i've hooked into the add the other statuses (see code below). The Page Attributes metabox doesn't have any filter. So I changed the code to add one (patch provided - meta-boxes.diff ).

None of the patches previously on this ticket seem to add this filter, but it'd be nice for it to be there to match up with the Quick Edit one at least.

function show_all_pages_in_admin_parent_pages_dropdown($args) {
  $args['post_status'] = array('publish', 'draft', 'pending', 'private');
  return $args;
}
add_filter( 'quick_edit_dropdown_pages_args', 'show_all_pages_in_admin_parent_pages_dropdown' );
add_filter( 'page_attributes_dropdown_pages_args', 'show_all_pages_in_admin_parent_pages_dropdown' );

#126 @sillybean
13 years ago

Interesting. I hadn't noticed that JJJ's patch adds only the private pages, but you're right.

To maintain support for custom statuses, we should probably use 'any' rather than enumerating each status... but when I tried that, either as a string or an array, my parent dropdown disappeared entirely and I got some weird capability errors.

#127 @sillybean
13 years ago

Any chance JJJ's patch can go into 3.3, and we can continue working out the rest of the details after that? The piece that went into 3.2 made it much easier to display private pages on the front end, but as davecpage has discovered, it's still virtually impossible to deal with the back end issues without hacking core.

#128 @SergeyBiryukov
13 years ago

  • Keywords needs-refresh removed
  • Milestone changed from Future Release to 3.3

Refreshed for 3.3, incorporated page_attributes_dropdown_pages_args filter.

#129 follow-up: @kmklr72
13 years ago

  • Cc kmklr72 added

Like davecpage, I ran into this issue for a client. I wanted to fix it without hacking core, and this function seems to be working fine (based on 3.2.1 stable):

function admin_private_parent_metabox($output)
{
	global $post;

	$args = array(
		'post_type'			=> $post->post_type,
		'exclude_tree'		=> $post->ID,
		'selected'			=> $post->post_parent,
		'name'				=> 'parent_id',
		'show_option_none'	=> __('(no parent)'),
		'sort_column'		=> 'menu_order, post_title',
		'echo'				=> 0,
		'post_status'		=> array('publish', 'private'),
	);

	$defaults = array(
		'depth'					=> 0,
		'child_of'				=> 0,
		'selected'				=> 0,
		'echo'					=> 1,
		'name'					=> 'page_id',
		'id'					=> '',
		'show_option_none'		=> '',
		'show_option_no_change'	=> '',
		'option_none_value'		=> '',
	);

	$r = wp_parse_args($args, $defaults);
	extract($r, EXTR_SKIP);

	$pages = get_pages($r);
	$name = esc_attr($name);
	// Back-compat with old system where both id and name were based on $name argument
	if (empty($id))
	{
		$id = $name;
	}

	if (!empty($pages))
	{
		$output = "<select name=\"$name\" id=\"$id\">\n";

		if ($show_option_no_change)
		{
			$output .= "\t<option value=\"-1\">$show_option_no_change</option>";
		}
		if ($show_option_none)
		{
			$output .= "\t<option value=\"" . esc_attr($option_none_value) . "\">$show_option_none</option>\n";
		}
		$output .= walk_page_dropdown_tree($pages, $depth, $r);
		$output .= "</select>\n";
	}

	return $output;
}
add_filter('wp_dropdown_pages', 'admin_private_parent_metabox');

As you might be able to tell, it is pretty much just a copy of wp_dropdown_pages from /wp-includes/post_template.php with a few customizations. It could probably do with being cleaned up, but it seems to be doing what I want for now. Hopefully it will help someone here.

#130 @nacin
12 years ago

+1 on 8592.2.patch for 3.3.

#131 @nacin
12 years ago

  • Keywords commit added

#132 @nacin
12 years ago

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

In [18818]:

Add filter for the args into wp_dropdown_pages() in the page attributes box. Give the list_pages filter the context of the post object. fixes #8592 for 3.3.

#133 @nacin
12 years ago

  • Milestone changed from 3.3 to Future Release
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Type changed from feature request to enhancement

#134 @mattheweppelsheimer
12 years ago

  • Cc mattheweppelsheimer added

#135 @mbijon
12 years ago

  • Cc mike@… added

#136 in reply to: ↑ 129 @vinceger
12 years ago

  • Version changed from 2.7 to 3.3

'Thank's 129 kmklr72 !

This did the trick with 'my problem' , other patches won't work here...'

Replying to kmklr72:

Like davecpage, I ran into this issue for a client. I wanted to fix it without hacking core, and this function seems to be working fine (based on 3.2.1 stable):

function admin_private_parent_metabox($output)
{
	global $post;

	$args = array(
		'post_type'			=> $post->post_type,
		'exclude_tree'		=> $post->ID,
		'selected'			=> $post->post_parent,
		'name'				=> 'parent_id',
		'show_option_none'	=> __('(no parent)'),
		'sort_column'		=> 'menu_order, post_title',
		'echo'				=> 0,
		'post_status'		=> array('publish', 'private'),
	);

	$defaults = array(
		'depth'					=> 0,
		'child_of'				=> 0,
		'selected'				=> 0,
		'echo'					=> 1,
		'name'					=> 'page_id',
		'id'					=> '',
		'show_option_none'		=> '',
		'show_option_no_change'	=> '',
		'option_none_value'		=> '',
	);

	$r = wp_parse_args($args, $defaults);
	extract($r, EXTR_SKIP);

	$pages = get_pages($r);
	$name = esc_attr($name);
	// Back-compat with old system where both id and name were based on $name argument
	if (empty($id))
	{
		$id = $name;
	}

	if (!empty($pages))
	{
		$output = "<select name=\"$name\" id=\"$id\">\n";

		if ($show_option_no_change)
		{
			$output .= "\t<option value=\"-1\">$show_option_no_change</option>";
		}
		if ($show_option_none)
		{
			$output .= "\t<option value=\"" . esc_attr($option_none_value) . "\">$show_option_none</option>\n";
		}
		$output .= walk_page_dropdown_tree($pages, $depth, $r);
		$output .= "</select>\n";
	}

	return $output;
}
add_filter('wp_dropdown_pages', 'admin_private_parent_metabox');

As you might be able to tell, it is pretty much just a copy of wp_dropdown_pages from /wp-includes/post_template.php with a few customizations. It could probably do with being cleaned up, but it seems to be doing what I want for now. Hopefully it will help someone here.

Last edited 12 years ago by vinceger (previous) (diff)

#137 @SergeyBiryukov
12 years ago

  • Keywords needs-refresh added
  • Version changed from 3.3 to 2.7

Version number indicates when the bug was initially introduced/reported.

#138 @Master Jake
12 years ago

  • Cc chappellind@… added

Definitely needs refresh. I discovered another issue today where if you assign a page as a child of another page, and then set that parent page's status to private, the child page is still associated with the parent but the dropdown list on the child pages shows (no parent).

#139 @seancojr
12 years ago

  • Cc seancojr added

#140 @vinceger
12 years ago

Just updated to WordPress 3.3.2. and still without success. This ticket opened 3 years ago :-(

#141 @SergeyBiryukov
12 years ago

  • Keywords needs-refresh removed

#142 @daveagp
12 years ago

I have tried this patch - which is sorely needed - and it is working fine for me. Thanks!

#143 @SergeyBiryukov
12 years ago

  • Keywords 3.5-early added

#144 @knutsp
12 years ago

  • Cc knut@… added

This problem is also present with the Options - Reading - Posts Page dropdown. Do I need to create a separate ticket for that?

Update: Yes, I will have to. I have tested the latest patch and it fixes this issue, but not the issue on Options Reading.

Last edited 12 years ago by knutsp (previous) (diff)

#145 @knutsp
12 years ago

The latest patch uses the capability 'read_private_posts' to check if status 'private' should be included in the list. Should it not check the 'read_private_pages' capability instead?

#146 @SergeyBiryukov
12 years ago

Closed #21205 as a duplicate.

#147 @ManuelRazzari
11 years ago

  • Cc manuel@… added

#148 @sillybean
11 years ago

Roundup of where we stand on this issue as of 3.5b3.

Things that can be fixed with filters:

  1. Add private/draft/future/pending pages to parent dropdown in page attributes metabox and Quick Edit
  2. Add (status) to titles in page parent dropdowns
  3. Filter front-end page loops to include privately published ones.
  4. Add all statuses to the menu admin screen's page metabox.
  5. Filter lists of pages (wp_list_pages, wp_page_menu, and menu functions) to include privately published ones.

See https://gist.github.com/4091448 for examples.

Items 1 and 2 are covered by 8592.3.patch (which probably should be changed to use the 'read_private_pages' capability as knutsp pointed out).

Item 3 uses a well-known mechanism for altering loops, and I think we can leave that alone.

I do think we need to do something to fix item 4. My example doesn't include the "(status)" labels, but a patch probably should.

My example solution to item 5 is inefficient, since we have to wait until the output is generated before we can overwrite it with new arguments. I think it would be better to either add a filter on the arguments array in wp_list_pages(), or put in a few lines to let us filter the post_status alongside the excluded page IDs.

Things that can't (easily) be fixed with filters:

  1. The page dropdown in Settings -> Reading. You'd have to go through the same contortions as in item 5, with the addition of an is_admin() conditional. (Plus, in my testing, it doesn't work, although that could be a quirk of my test setup or a bad cache or who knows.)

I'm ambivalent about "fixing" 6, as it's the most likely to lead unwary users into doing something they didn't intend. On the other hand, adding an argument array filter in wp_dropdown_pages() would let developers do it if they really, really wanted to, and might provide flexibility in other areas beyond the scope of this ticket.

Have I missed any other places where other page statuses need to be included?

What needs to be done to get this issue fixed in 3.6? I think:

  • Refresh the patch and change the capability
  • Write a patch to cover the page metabox in the nav menu admin screen, preferably with (status) titles, keeping in mind that plugins can register custom statuses.
  • Discuss whether to filter the entire argument array in wp_list_pages() or just the post_status, and write a patch accordingly.
  • Discuss whether to do the same for wp_dropdown_pages().

#149 @miss_jwo
11 years ago

  • Cc miss_jwo added

Could someone explain how to implement the patches/fix that sillybean mentions?

#150 @robwil0
11 years ago

  • Cc robwil0 added

#151 @sillybean
11 years ago

  • Keywords 3.5-early removed

Minimum number of things that have to get done in order to resolve this ticket:

  • Allow arguments to be filtered in wp_list_pages() and wp_dropdown_pages() (related: #23734).
  • Scrub core for remaining hard-coded status lists (related: #12706, #24722) and make sure they can be filtered (to add custom statuses registered by plugins, or add labels in parentheses as described upthread).
  • When saving child pages of restricted (private, password, draft) parents, enforce the same status/visibility on the child. This prevents weirdness like published children of draft parents.

At that point, while core still won't allow hierarchies of private/password/draft pages, plugins should be able to accomplish it by applying various filters.

Comments? I'll start on the argument filters and save_post hook before tackling the status lists; more eyes on that aspect would be especially welcome.

@sillybean
11 years ago

Allow arguments to be filtered in wp_list_pages() and wp_dropdown_pages()

#152 @sillybean
11 years ago

Also welcome: thoughts about what to do with children of password-protected pages. Do we reuse the parent's password, or toss it back to the user with an error?

#153 @mbijon
11 years ago

Regarding re-using password on child pages ... it doesn't seem like the most-secure thing, but I think it should be allowed.

As for usability, I think two user experiences are needed:

  1. A no-choice option where the child can inherit the password without the user doing anything, but one that might be highlighted with a subtle alert to call the user's attention to this fact (Ideally without any buttons or overlays that might force a user action or click)
  1. The standard password field so the user could change the password if they want to, possibly with a small text note that "The password will be copied from the parent page, unless changed here"

#154 @sillybean
11 years ago

Fun fact: with the two-line change in list-pages-args.diff​ alone, we no longer need the much longer 8592.3.patch, and can do almost everything with filters. (See updated https://gist.github.com/sillybean/4091448.)

New parent status check patch includes the filters, but also tinkers with the publish metabox and admin-ajax functions to start enforcing unpublished parents' status on their child pages.

@sillybean
11 years ago

Force children of unpublished parent pages to inherit status. Includes new argument filters for wp_list_pages() and wp_dropdown_pages().

#155 @sillybean
11 years ago

Updated the patch just a bit. wp_dropdown_pages() now tosses out the filtered post_status and reverts to 'publish' on the Reading Settings page, preventing admins from doing something unwise there.

I have not yet incorporated mbijon's suggestions for password-protected pages. That'll be my next step. If anyone has time to try out the current patch with draft and private pages, I'd appreciate feedback on the general direction of things.

#156 @sillybean
11 years ago

Related to the password issues: #13821

#157 @helen
11 years ago

  • Keywords commit removed

#158 @sillybean
11 years ago

  • Keywords 2nd-opinion added

8592.5.diff includes checks for password-protected pages' children.

To sum up the current approach, there are new args filters on wp_list_pages() and wp_dropdown_pages(), to allow devs to change post_status (among other things). And then there is a bunch of sanity checking as a result:

  • Reading Settings forces public status for the front page setting, in case wp_dropdown_pages() has been filtered to include other statuses.
  • If the user attempts to publish child pages of draft or private pages, the children will inherit the parent's status instead, and their status can't be changed until the parent is published (with a note to that effect in the Visibility section of the Publish box).
  • If the user attempts to publish child pages of password-protected pages, the children will also be set to password-protected and will inherit the parent's password if none was set (also with a note in the Publish box).

@sillybean
11 years ago

Add filters to args for wp_list_pages() and wp_dropdown_pages() except on Reading Settings; force child pages of unpublished parents to inherit status and password

#159 @nofearinc
10 years ago

Related: #13222

Last edited 10 years ago by nofearinc (previous) (diff)

#160 @nacin
10 years ago

#6939 was marked as a duplicate.

#161 @nacin
10 years ago

#4711 was marked as a duplicate.

#162 @plocha
10 years ago

  • Keywords has-patch removed

Top down inheritance code

The previous patch has only 'bottom up' inheritance checks in wp_insert_post. What if you set a published parent, which has published children, to private? You get published children with a private parent: not good. We need recursive inheritance code to modify all descendants in such cases.

Password inheritance

In previous patch you can create a child from a password protected parent from another user. Then you can steal the password from the parent looking into the input field at html code. I think we have three options for that issue:

  • Hold on to the same pw inheritance system. But do not print the password in the forms. Seems to be weird imho: user do not know password of a page but can edit it.
  • Only inherit password in some cases. For example if child and parent have the same author or if user has the edit_others_pages capability. Looks complicated imho.
  • Treat pw protected parents as published parents without inheritance. It is my favorite not least because it simplifies the code but pw inheritance is not relevant to this ticket. A password does not affect the visibility in menu. Okay, sometimes pw inheritance may be useful but it is not necessary for our problem. I think it should implemented in a plugin or got an own ticket

Status limitation instead of strict inheritance

Example: published parent, draft child. If you set parent to "future", the children gets the same status. Such a feature can be annoying. Maybe we should switch to a status limitation feature: A parent status limits the possible status for the descendants. The 'top down' inheritance code should only force a descendant to have the same status if the descendant has an 'higher' status. Example: published parent, future child. If you set the parent to draft, the child should also be set to draft.

Other example: future parent. A child can be for example draft,private or future but it cannot be published.

Such a system looks possible in my view. But maybe I does not fully understand all the post status with their several relationships between themselves.

Gui suggestions

Some of these suggestions are maybe overdone:

  • In previous patch we have ajax gui adjustments with autosave requests. We can take this js code to implement a second adjustment check: immediately upon the user choosed a parent in attribute box an ajax request is fired to check for new adjustments. We can use the same js code to decide which post status and post visibility gui limitations are needed.
  • But the gui limitations of the previous patch are not enough. We should implement appropriate gui limitations for each status. If I'm not mistaken with the previous patch you can set a child of a private parent to draft in the gui although it is not possible to save a draft child with a private parent. We should improve gui limitations at static html generation and at ajax gui adjustments.
  • You forgot to implement gui limitations for quickedit. We need static html and ajax limitations, for parent choosing as stated above, here. Furthermore we could implement an adjustment for descendants, which are modified by 'top down' inheritance code, in the page list. Without this feature you need to reload to see the changed descendants.

My patch

I wrote a patch which implements some of my suggestions. It has the old 'bottom up' and the new 'top down' inheritance but the patch only supports parentships for published, pw protected and private pages. It does not support pw inheritance. I removed the gui limitations from the previous patch. I added checks for post status which do not support parentship in my patch. I removed most of sillybeans filter code because I did not found the time to understand the related tickets. Look into my code for more details because my code is better than my potato english skills.

I know the patch is incomplete but I needed it for my own projects and it could be useful for you imho. :D The patch works with 3.8.1

I added the feature to view private pages in the menu with a plugin. I did not integrated it into the patch. Sorry for that. The code was something like this:

function bla_handle_privates_adding( $args ) {
        if ( ! current_user_can( 'read_private_pages' ) ) {
                return $args;
        }
        $defaults = array( 'post_status' => 'publish,private' );
        return wp_parse_args( $args, $defaults );
}
add_filter( 'wp_page_menu_args', 'bla_handle_privates_adding' );
Last edited 10 years ago by plocha (previous) (diff)

@plocha
10 years ago

#163 @nacin
10 years ago

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

#164 @vinceger
10 years ago

Thank's plocha, works A-Okay !

Vielen Dank plocha, funktioniert einwandfrei !

Last edited 10 years ago by vinceger (previous) (diff)

#165 @alexfurr
10 years ago

Hi - I don't fully understand all this thread but it describes my problem very well.

The quirk I have is when a parent page is set to draft / scheduled or private, the child pages:
a) 'Lose' their parent from the dropdown admin page
b) Start appearing in the root of the front site main menu (using the wp_page_menu function)

This is stopping me promoting WP as a serious contender for the 'go to' tool in our institution.

Is there a patch? Seems crazy that an established tool like WP does not have something simply sorted like scheduling a parent (and therefore all child pages) to appear in a menu.

Any help would be appreciated.

Alex Furr

#166 @plocha
10 years ago

I know this bug. In current WP versions you can't set a page to a child of a non published page directly. That's okay because we still don't supporting it. But we forgot to check for parentships if we set a page to non published. At fist view it looks like the parentship is removed if you reproduce this bug. But it isn't. Look at the 'All Pages' screen: there is still a hierarchy. But it's an invalid hierarchy.

My patch contains code which really removes parentships in such cases. We could extract that code and use it until this ticket is fixed.

I found found another problem: what if you're currently in wp_insert_post while another request is also in the same function? Example: you try to create a published child page of a published parent page. You pass the status inheritance code and the status of your child is still 'published' because the parent is also published. Suddenly a lightning-fast second user sets the parent to private before you inserted your child into the database. Result: we've got a private parent with a published child. Omfg!

How handle WP such synchronization problems?

#167 @alexfurr
10 years ago

Plocha - thanks (again!) for your input. What do you mean by 'we still don't supporting it.' Does this mean its not on the radar of things to be fixed?

I've stated it on other forums, but I'll re-iterate for the sake of other people - it makes using WP as a time release CMS tool pretty useless. We often need to release entire topics to students on a specific date - logically you'd schedule the parent page for that date, and that would hide the page, AND children pages (if it worked logically) from the main menu.

Unfortunately it also affects the has adverse affects on the main wp_page_menu function meaning that if you set a parent page to scheduled, ALL child pages suddenly appear in the root menu. Absolutely the opposite of what users would want!

I've been using WP for over 5 years and this is the first 'WTF?' problem I've found.

I see no real problem with a parent page being set to 'private/draft/scheduled' and a child to 'published'. How would this work in reality? As you'd expect:

  1. You could search for page content on the 'published' child page and view the page directly
  2. You wouldn't be able to view the parent page in the main menu - and therefore the child page would also be hidden

That makes perfect logical sense to me, AND to everyone I've spoken to.

The key thing is currently, setting a parent page to anything other than published COMPLETELY screws up the dynamic menu system which pretty much ALL themes use.

Happy to discuss further - I hate tinkering with the WP core code so won't bother with the patch, but really do appreciate the response.

Alex

#168 @OSD
10 years ago

Need help...

When I create a new child page for a private parent page it's not possible to publish this new child page, it will go back to private.

solved

Last edited 10 years ago by OSD (previous) (diff)

#169 @vinceger
10 years ago

Like alexfurr wrote "it makes using WP as a time release CMS tool pretty useless".

Who can fix this mess ?

Any help would be appreciated!

#170 follow-up: @plocha
10 years ago

  • Keywords needs-patch added

You convinced me. Your suggestion seems to be the simplest. My thoughts aren't really relevant to the menu structure, thus they aren't relevant to this ticket. I will create new tickets or write a plugin to implement the status inheritance and status limitation ideas.

To implement your suggestion a patch should do the following:

  • complete the list of allowed statuses in parent selection
  • use the walker classes to exclude descendants of unpublished parent pages

Time permitting, I will ask other developers for feedback and write a patch.

@OSD & vinceger: that's off topic. We try to solve problems within this ticket. And replies like theses are counterproductive.. :P

#171 @alexfurr
10 years ago

Hi plocha,
That's great news. I know this will be a huge improvement.

The workaround we have implemented at the moment is to use a custom menu which DOES do what you'd expect I.e. pages in the menu that are set for future publish dates do not appear until that date, and child pages are also hidden. Unfortunately the majority of our users do not know how to use custom menus properly so it causes more problems than it solves.

In order to use the workaround, I also needed to add a patch that allowed child pages to pick parent pages that were private / future published etc. this should probably be addressed as well.

I would be very happy to test / provide feedback for this patch, please keep me in the loop if you think I can help in anyway.

Kind regards,

Alex

#172 in reply to: ↑ 170 @OSD
10 years ago

Replying to plocha:
@OSD & vinceger: that's off topic. We try to solve problems within this ticket. And replies like theses are counterproductive.. :P

Thank's for the update but I'm confused now, maybe it's my English but I thought this thread had everything to do with "Private Pages not listed in the Parent drop down" ?

Solved

Last edited 10 years ago by OSD (previous) (diff)

This ticket was mentioned in IRC in #wordpress-dev by edik. View the logs.


10 years ago

#174 @divisj
10 years ago

+1. Looking to use convention over configuration here, to tell when I'm on a private child page in order to show a menu, and not show it when I'm on a private parent page. I'll have multiple sets of parent-child related pages, all using the same page theme, and this feature would allow me to keep the one page theme, rather than having to specify two different themes, or having to resort to using custom fields to specify "child pages".

#175 @Victor_Delta
10 years ago

  • Version changed from 2.7 to trunk

It would be so good if this problem could be resolved once and for all.

#176 @Victor_Delta
10 years ago

  • Version changed from trunk to 2.7

(sorry!)

Last edited 10 years ago by Victor_Delta (previous) (diff)

#177 @McGuive7
10 years ago

+1 on this. I just saw that this ticket was filed 6 years ago. Wow. Any update on this one? Thanks.

#178 @Flexxo
10 years ago

  • Version 2.7 deleted

+1

#179 @Viper007Bond
10 years ago

  • Version set to 2.7

Putting the version back.

#181 @chriscct7
9 years ago

#13222 was marked as a duplicate.

#183 @sccr410
9 years ago

+1 please

#184 @SergeyBiryukov
9 years ago

#31958 was marked as a duplicate.

#186 in reply to: ↑ description @chasman
9 years ago

Replying to mtdewvirus:

Private pages are not available as a choice in the Parent dropdown of the Attributes module.

You should be able to create a hierarchy of private pages if you want to.

Tested with r10194.

Any news on this? Has it been released?

#187 @michalzuber
9 years ago

  • Keywords ux-feedback added

It would be cool if some UX guru would comment some feedback how should this work for the user. There exists too many use cases for this. (tackeling this one with guys on Contributors Day in Slovakia)

#188 @alexfurr
9 years ago

Well from our users point of view its pretty simple.

How we'd want it to work
In the 'Page Attributes' window (post.php) ALL pages should appear in the 'Parent' drop down option.
That bit seems to be quite simple - someone (I forget the source) has already written a code snippet to do this

// Add draft / aprentpending etc for pages in the drop down
add_filter( 'page_attributes_dropdown_pages_args', 'wps_dropdown_pages_args_add_parents' );
add_filter( 'quick_edit_dropdown_pages_args', 'wps_dropdown_pages_args_add_parents' );
/**
 * Add private/draft/future/pending pages to parent dropdown.
 */
function wps_dropdown_pages_args_add_parents( $dropdown_args, $post = NULL ) {
    $dropdown_args['post_status'] = array( 'publish', 'draft', 'pending', 'future', 'private', );
    return $dropdown_args;
}

The tricky bit (I believe) is changing what happens to child pages when a parent is made private.
The default functionality is that they 'lose' their parent - consequences of which means that if using the default navigation system these sub pages now appear in the main menu.

How we'd like child pages of private pages to behave
When a child page has a 'private', pending' or 'future' status:

  1. It should retain the original parent in the page attributes drop down
  2. They should NOT appear in the default nav system

That way it would allow people do to the following, which we really really need.

  1. Create a set of sub pages under a single parent page
  2. Make this page private, or future release
  3. Therefore hiding the parent page and ALL child pages from the menu until the parent is 'published'

Basically, as a normal CMS would handle things. Currently the behavior is not what users predict.

I'm sure there are discussions to be had regarding children pages inheriting parent pages status (e.g. are children of a private page ALSO private?) but I'll leave that as for us, the main thing is NOT having children of private pages appearing in the main nav menu.

Hopefully that makes sense - I appreciate my agenda my differ from other peoples, but this is a major reason I can't fully recommend WP as the default CMS in our institution.

Thanks for listening and good luck.
Alex

#189 @OSD
9 years ago

Opened 6 years ago . . . . .

#190 @atomicjack
9 years ago

  • Keywords needs-testing added

If anyone can test the patches still work, or if they need updating, then maybe we can see this be pushed in to 4.4.

Believe we also need UX feedback on this?

@wonderboymusic @SergeyBiryukov

#191 follow-up: @OSD
9 years ago

Thank you!

To be honest, for me the 8592.3.patch, only the two first files (wp-admin/includes/class-wp-posts-list-table.php and wp-admin/includes/meta-boxes.php) works okay in my particular case. With this patch the Private Pages are listed in the Parent dropdown.

Last edited 9 years ago by OSD (previous) (diff)

#192 in reply to: ↑ 191 ; follow-up: @atomicjack
9 years ago

Replying to OSD:

Thank you!

To be honest, for me the 8592.3.patch, only the two first files (wp-admin/includes/class-wp-posts-list-table.php and wp-admin/includes/meta-boxes.php) works okay in my particular case. With this patch the Private Pages are listed in the Parent dropdown.

Can you show/confirm it is working in:

4.3
4.3.1 (trunk)

#193 @OSD
9 years ago

Have it up and running in 4.3

Last edited 9 years ago by OSD (previous) (diff)

#194 @EBurden
9 years ago

My goal was to make "Page 2" a private page a child of "Page 1" also a private page.
It was working a couple months ago but now can't get it to work. I made the parent public first then was able to select the child page and then make the parent private. Looked good but doesn't work. Link from parent private page won't find child and updating child takes away child status.
Any possibility for a solution without hacking.

#195 @wonderboymusic
9 years ago

  • Keywords 2nd-opinion removed
  • Milestone changed from Future Release to 4.4

we should revisit this

#196 @wonderboymusic
9 years ago

  • Owner changed from nacin to SergeyBiryukov
  • Status changed from reopened to assigned

Sergey, can you see what we can salvage from this?

#197 in reply to: ↑ 192 @OSD
8 years ago

Replying to atomicjack:

Replying to OSD:

Thank you!

To be honest, for me the 8592.3.patch, only the two first files (wp-admin/includes/class-wp-posts-list-table.php and wp-admin/includes/meta-boxes.php) works okay in my particular case. With this patch the Private Pages are listed in the Parent dropdown.

Can you show/confirm it is working in:

4.3
4.3.1 (trunk)

Just updated to WP 4.3.1 and changed wp-admin/includes/class-wp-posts-list-table.php and wp-admin/includes/meta-boxes.php and it's working (in my case).

Last edited 8 years ago by OSD (previous) (diff)

This ticket was mentioned in Slack in #core by sergey. View the logs.


8 years ago

#199 @wonderboymusic
8 years ago

  • Milestone changed from 4.4 to Future Release

#200 @alexfurr
8 years ago

Thank you to all who worked on this. Good job!

#201 follow-up: @OSD
8 years ago

Updatet to WP 4.4 today but things keep getting worse regarding this ticket.

Most pages are 404's now because some do not have the ../private/.. url and others now have a ../private/private/.. url ?

Had to go back to WP 4.3.1 and changing wp-admin/includes/class-wp-posts-list-table.php and wp-admin/includes/meta-boxes.php to have a working site with over 1000 pages..

Last edited 8 years ago by OSD (previous) (diff)

#202 @telephag
8 years ago

+1 on something in core that makes it possible for you to select a private page as a parent. The inheritance of visibility part seems like bonus to me, personally.

However, if you did do that, I don't think you'd need to change UI. You'd only need to change behavior.

If I set a parent page to Private, all children inherit Private visibility (but are not set to Private).

If I set a parent page to Public, children settings are not changed, and Public is not inherited.

#203 in reply to: ↑ 201 @netweb
8 years ago

Replying to OSD:

Updatet to WP 4.4 today but things keep getting worse regarding this ticket.

Most pages are 404's now because some do not have the ../private/.. url and others now have a ../private/private/.. url ?

Had to go back to WP 4.3.1 and changing wp-admin/includes/class-wp-posts-list-table.php and wp-admin/includes/meta-boxes.php to have a working site with over 1000 pages..

@OSD, see #35084 for your issue here, it will ship with WordPress 4.4.1
(Note: #35084 is nothing to do with this ticket here, different issue ;) )

#204 @alexfurr
8 years ago

@telephag describes the desired functionality perfectly. Is this still not implemented? I thought there was agreement on the spec. Will keep waiting and hoping!

#205 @Victor_Delta
8 years ago

After several years of waiting, I don't think this will ever be fixed.

#206 @mordauk
8 years ago

I just ran into this in the wild and would love to see it happen in some form.

#207 @OSD
8 years ago

Updated to WP Version 4.5 - bummer....

This ticket opened 7 years ago and I still need to use 8592.3.patch to make WP work !

Last edited 8 years ago by OSD (previous) (diff)

#208 @benwb
8 years ago

Bump as well, i'd like to see this fixed.

#209 @OSD
8 years ago

Just updated to WordPress 4.6 “Pepper” and guess what, after this ticket opening 8 years ago, not working again....

@sillybean
7 years ago

minimal argument filters for wp_list_pages() and wp_dropdown_pages()

#210 @sillybean
7 years ago

  • Keywords has-patch added; needs-patch removed

Patch 8592.6.diff is a minimalist refresh. It does away with all the code pertaining to status inheritance. The only sanity check included is to prevent the dropdown filters from being applied on the Reading Settings page.

#211 @sillybean
7 years ago

I've rewritten and updated the small plugin I'd posted as a Gist some time ago. It's now in the repo as Inclusive Parents (and on GitHub, if you want to contribute). The proposed patch would be more comprehensive, but this does add unpublished pages to parent dropdowns (edit, quick edit, and bulk edit), the nav menu checklists, the page widget, and wp_page_menu().

#212 @lkraav
7 years ago

@sillybean need to be careful with pre_get_posts. This can be fired earlier than you might think and get_current_screen() may not exist yet. Adding is_main_query() helps.

  • inclusive-parents.php

    diff --git a/inclusive-parents.php b/inclusive-parents.php
    index a74ff4c..a485c13 100644
    a b add_filter( 'the_title', 'scl_menu_checklist_status_label', 10, 2 ); 
    9191 * @return object $query
    9292 */
    9393function scl_menu_screen_add_private_pages( $query ) {
    94        if ( is_admin() && 'nav-menus' == get_current_screen()->base ) {
     94       if ( is_admin() && $query->is_main_query() && 'nav-menus' == get_current_screen()->base ) {
    9595               $query->set( 'post_status', array( 'publish', 'private', 'password' ) );
    9696       }       
    9797       return $query;

#213 @pscolv
7 years ago

  • Severity changed from major to critical
  • Type changed from enhancement to defect (bug)
  • Version 2.7 deleted

Hi all, I'm stumbling upon this issue today, after a few months of using WP, and I'm very surprised to see that this issue has been pending during 8 years already...

I guess there is a general consensus from many users about how this should be managed, ie that private and protected pages are visible in the "parent" dropdown, and that changing the privacy status of a page doesn't affect its hierarchical relationships.

I tried the snippet provided in comment #188, and it seems to fix both aspects. Why wasn't it already integrated into the core ?

Add draft / aprentpending etc for pages in the drop down
add_filter( 'page_attributes_dropdown_pages_args', 'wps_dropdown_pages_args_add_parents' );
add_filter( 'quick_edit_dropdown_pages_args', 'wps_dropdown_pages_args_add_parents' );
/

  • Add private/draft/future/pending pages to parent dropdown. */

function wps_dropdown_pages_args_add_parents( $dropdown_args, $post = NULL ) {

$dropdown_argspost_status? = array( 'publish', 'draft', 'pending', 'future', 'private', );
return $dropdown_args;

}

Regards,

Pascal.

BTW I cannot choose the latest (4.6) WP version in the drop down list here... it seems to stop at 2.7... I hope this forum is still active though !

#214 @OSD
7 years ago

WordPress 4.7 “Vaughan”, I hoped it worked, but sadly not.

#215 @graphicscove
7 years ago

+1

In all my years using Wordpress I've literally just noticed you can't do this! And I was even more surprised to see the ticket is 8 years old with no fix.

Unfortunately I'm not a backend developer so I can't help push it forward but I'll be watching this ticket closely.

#216 @webheadllc
7 years ago

I added the ability to do this in my plugin, WH Tweaks, until this gets added to core.

#217 @Victor_Delta
7 years ago

Thanks @webheadllc - With no proper fix available for this problem, your plugin is a real help.

#218 follow-up: @tha_sun
7 years ago

There is more specific and mature plugin, which only adjusts the filtering of posts in the necessary spots:

https://wordpress.org/plugins/inclusive-parents/

Sorry for the noise. This is not a forum and we should get back to the actual issue and patch now.

#219 in reply to: ↑ 218 @creativetopia
7 years ago

Replying to tha_sun:

There is more specific and mature plugin, which only adjusts the filtering of posts in the necessary spots:

https://wordpress.org/plugins/inclusive-parents/

Sorry for the noise. This is not a forum and we should get back to the actual issue and patch now.

DO NOT INSTALL THIS PLUGIN - It does not work. WH Tweaks worked for me until this old issue is finally resolved.

#220 @grahamjones
7 years ago

The plug-in "Nested Pages" also allows you to create child pages for private pages.

https://en-gb.wordpress.org/plugins/wp-nested-pages/

#221 follow-up: @gulliver
7 years ago

I think https://www.mightyminnow.com/2014/09/include-privatedraft-pages-in-parent-dropdowns/ has an interim fix with some simple code which can be added to functions.php.

#222 in reply to: ↑ 221 @cbratschi
6 years ago

Replying to gulliver:

I think https://www.mightyminnow.com/2014/09/include-privatedraft-pages-in-parent-dropdowns/ has an interim fix with some simple code which can be added to functions.php.

Yes, this works and the article describes the issue accurately.

#223 @SergeyBiryukov
6 years ago

#43474 was marked as a duplicate.

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


5 years ago

#225 @joyously
5 years ago

As part of #design triage on Jan 28, 2019 I read through this ticket, and it had several parts implemented in two different releases, but not all of it.
The ticket was closed as fixed and then reopened. It went from bug to enhancement to bug. It went from normal to major to critical, but these are changes from whoever encountered the problem last, not devs.

Someone added ux-feedback keyword 4 years ago (so 6 years into the ticket), and I think it's because it's not really obvious what should happen with Pages that are private or draft or future.

  • Should they show up in the dropdown lists?
  • Should you be able to make a child page for Page that is not Published?
  • Does the child inherit the status? If so, does it inherit any change in the parent Page status?
  • And if a parent Page is Published and then changed to draft or private, what happens to the child?

There is a 2 year old patch on comment 210, but comment 212 indicates a small change is needed. I don't know which part is actually fixed and which is still a problem, or what anyone is waiting on.

We can move this forward by answering the above questions. It might help to consider this as more than one ticket, as in the various places that Pages are listed or used, such as menus and Page on front and Posts Page.

#226 @lkraav
5 years ago

I'm actively using private parent pages and Inclusive Parents plugin, with a small patch on top of current master to get rid of various PHP notices.

See https://github.com/lkraav/inclusive-parents

Main use case: including admin-manageable content partials via various shortcodes in various published pages.

No such partials are ever supposed to become published, and I have private page trees, sometimes more than one.

Feedback for the latest comment:

Someone added ux-feedback keyword 4 years ago (so 6 years into the ticket), and I think it's because it's not really obvious what should happen with Pages that are private or draft or future.

Should they show up in the dropdown lists?

Yes, including their status like Title (private), if anything other than published.

All dropdowns should be Select2-based for easy searching.

Should you be able to make a child page for Page that is not Published?

Yes. Private page trees are completely OK.

Does the child inherit the status? If so, does it inherit any change in the parent Page status?

As long as frontend rewrite rules are able to load the page, any page in the tree could be allowed to be whatever status admin wishes it to be.

And if a parent Page is Published and then changed to draft or private, what happens to the child?

Nothing happens. Same as above.

#227 @vinceger
5 years ago

Followed this threat for 10 years now.... I gave it up waiting for a good solution and changed all url and got lost of child and parent pages recently... vinceger signing off - thank you all

#228 @mark8barnes
5 years ago

Should they show up in the dropdown lists?

Yes. As @lkraav says, it would be useful if the dropdown also appended (Private)

Should you be able to make a child page for Page that is not Published?

Yes. Why not? The most obvious use case is when you want to work on a batch of pages for future publication. Currently, you can't properly test those pages.

Does the child inherit the status? If so, does it inherit any change in the parent Page status?

No. It adds unnecessary complexity. Let's just get the pages in the dropdown first.

And if a parent Page is Published and then changed to draft or private, what happens to the child?

No, as there's no inheritance. See above.

This ticket was mentioned in Slack in #core by joyously. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by sergey. View the logs.


5 years ago

#231 @danielbachhuber
5 years ago

Closed #12890 (which requested Scheduled and Draft pages) in favor of this ticket.

https://github.com/WordPress/gutenberg/issues/9089 is also related

#232 follow-up: @danielbachhuber
5 years ago

#12890 was marked as a duplicate.

#233 in reply to: ↑ 232 ; follow-up: @BeeVee
5 years ago

Replying to danielbachhuber:

Amazing that this issue has been rumbling on for 10 years. I came here looking for a solution for my needs, which are "add new pages to a private hierarchy"... I guess I have my answer - wait more. :)

B

#234 in reply to: ↑ 233 @OSD
5 years ago

  • Resolution set to invalid
  • Status changed from assigned to closed

Replying to BeeVee:

Replying to danielbachhuber:

Amazing that this issue has been rumbling on for 10 years. I came here looking for a solution for my needs, which are "add new pages to a private hierarchy"... I guess I have my answer - wait more. :)

B

LOL - same here - waiting so long I'm getting to old for this nonsense. I got rid of these pages and rebuild my site's (several hundred pages) already and beginning a new life... over and out

#235 @userrame
5 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

This should not be marked as closed. Insane that this hasn't been fixed in 10 years.

For any other poor souls looking for a patchwork solution, none of the above work with the Gutenberg editor (from my experience). Here's what worked for me:

  • Install the aforementioned WH Tweaks.
    • It has a lot of options enabled by default. Adjust them as you like, but leave "Show private pages in Parent dropdowns" enabled.
  • If you're using Gutenberg, private pages still won't show under the Parent Page dropdown, so install Classic Editor.
    • Optionally, set your preferred default editor under Settings > Writing.
  • Use the classic editor to set private pages as parents.

When you switch back to Gutenberg, the page will appear to have no parent. From my testing, however, this appears to just be visual. The hierarchy does indeed remain.

#236 @BeeVee
5 years ago

I went a different route and got the Nested Pages plugin. It gives an All Pages page where pages can all be dragged and dropped. It still means a two-step process, and there are still problems with other dropdown menus, but it's better than the nothing that has been provided over the last ten years :)

B

#237 @Kipperlenny
5 years ago

  • Type changed from defect (bug) to enhancement

Thats a crazy ticket :-D

We want to create a few new pages, as draft first - of course.
Now we cannot select any of these as parents and cannot create the page tree in draft or private mode as needed.

This is stupid

Please include this in core https://www.mightyminnow.com/2014/09/include-privatedraft-pages-in-parent-dropdowns/ and stop discussion useless stuff for 10 years.

Oh and Gutenberg - just get rid of it ;)

#238 in reply to: ↑ description @fazzo
5 years ago

Replying to mtdewvirus:

Private pages are not available as a choice in the Parent dropdown of the Attributes module.

You should be able to create a hierarchy of private pages if you want to.

Tested with r10194.

I realy need this. Partners create drafted sub pages but can not set as a child for a drafted category. If everybody has completed there sub pages I have to publish the category and have to touch every single sub page for moving it into the desired category. What a waste of time.

This ticket was mentioned in Slack in #docs by joyously. View the logs.


4 years ago

#240 @SergeyBiryukov
4 years ago

#48749 was marked as a duplicate.

#241 @SergeyBiryukov
4 years ago

#50386 was marked as a duplicate.

#242 @cr0ybot
4 years ago

Related to this ticket, I've submitted a pull request to the Gutenberg repository that allows for filtering the query that is responsible for populating the parent page dropdown:

https://github.com/WordPress/gutenberg/pull/25221

This is a potential fix for the issue @userrame brought up, as currently there is no way to alter this dropdown in Gutenberg.

#243 in reply to: ↑ 27 @ritterml
3 years ago

Replying to Denis-de-Bernardy:

Replying to mtekk:

I'll test this tonight, but private pages still should not show up with the patch unless the user has permissions to see them.

Err. They should. Or at least the current parent pages should show. Suppose user A publishes a private page that gets used as a stub. And user B publishes a public page whose parent is the private page.

Chiming in on a ooooooooold thread so I don't lose the thought as I scroll down. Suggesting parent option always available for pages based on published status (draft, private, password, public) AND inherit most restrictive permissions of parent:

  1. Drafts can be assigned to any status.
  1. Private pages can be assigned to any but Drafts.
  1. Password pages can be assigned to Password or Public.
  1. Public can be assigned to Public.

IF user attempts to assign to parent with more restrictions Notification will prompt that cascading changes on affected children will occur or cancel.

#244 in reply to: ↑ description @indypldano
3 years ago

I agree that Private Pages should be allowed in the Parent dropdown of the Attributes module, as well as searchable in the 'Appearance > Menus' building tool, and selectable in the Pages manager 'Quick Edit > Parent' dropdown menu.

Replying to mtdewvirus:

Private pages are not available as a choice in the Parent dropdown of the Attributes module.

You should be able to create a hierarchy of private pages if you want to.

Tested with r10194.

#245 follow-up: @pbiron
15 months ago

I just encountered this problem (don't use private pages a lot)!

In addition to the limitations everyone has mentioned about the "Parent Page" in the editor (both GB and Classic) and Quick Edit, private pages also do not show when creating a link (both GB and Classic). Sorry if this has been mentioned before...there's a lot of history to read through in a 14 year old ticket, and I may have missed it :-)

#246 in reply to: ↑ 245 @savionlee
3 months ago

Replying to pbiron:

I just encountered this problem (don't use private pages a lot)!

In addition to the limitations everyone has mentioned about the "Parent Page" in the editor (both GB and Classic) and Quick Edit, private pages also do not show when creating a link (both GB and Classic). Sorry if this has been mentioned before...there's a lot of history to read through in a 14 year old ticket, and I may have missed it :-)

This would be a very helpful enhancement to create my membership/collaboration site without adding an extra plugin to maintain. I could then build out the menus, links, and organize private pages without having to password protect them all.

Note: See TracTickets for help on using tickets.