[wp-trac] [WordPress Trac] #8592: Private Pages not listed in the Parent dropdown

WordPress Trac noreply at wordpress.org
Sat Feb 1 07:40:26 UTC 2014


#8592: Private Pages not listed in the Parent dropdown
----------------------------+-----------------------------
 Reporter:  mtdewvirus      |       Owner:  nacin
     Type:  enhancement     |      Status:  reopened
 Priority:  normal          |   Milestone:  Future Release
Component:  Administration  |     Version:  2.7
 Severity:  major           |  Resolution:
 Keywords:  2nd-opinion     |     Focuses:
----------------------------+-----------------------------
Changes (by plocha):

 * keywords:  has-patch 2nd-opinion => 2nd-opinion


Comment:

 '''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 private.

 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 their 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', array( $this,
 'bla_handle_privates_adding' ) );
 }}}

--
Ticket URL: <https://core.trac.wordpress.org/ticket/8592#comment:162>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list