[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