Opened 14 years ago
Last modified 3 months ago
#18264 new defect (bug)
Future private posts listed as already published with future date specified
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Awaiting Review | Priority: | normal |
| Severity: | normal | Version: | |
| Component: | Posts, Post Types | Keywords: | editorial-flow has-patch |
| Focuses: | ui, administration | Cc: |
Description
Setting a post to private, and scheduling it for some future date or time, results in the stamp that the post was "Published on (future date)" in the publish module.
The discussion on tickets #5608 and #9136 suggests that all private posts are published immediately (and privately), and that this is intentional. So, it's misleading and confusing to report that it already was published on some future date.
In source:trunk/wp-admin/includes/meta-boxes.php#L163, I suggest we replace:
else if ( 'publish' == $post->post_status || 'private' == $post->post_status ) { // already published
$stamp = __('Published on: <b>%1$s</b>'); }
with:
else if ( 'publish' == $post->post_status ) { // already publicly published
$stamp = __('Published on: <b>%1$s</b>');
} else if ( 'private' == $post->post_status ) { // published privately
$stamp = __('Published privately'); }
Attachments (1)
Change History (24)
#3
@
14 years ago
I think the whole concept of Privately Published is wrong, and we should re-evaluate it completely. The way that language is used on wordpress.com (private to the group of your choosing) makes a lot more sense. Saving content so it's viewable only to author/admin is more like a private save. If no one else can view it, it's not really published in the normal sense, right?
#4
@
14 years ago
I just ran into this exact issue myself. Ideally, we would deprecate the "private" status altogether and leave it to plugins to implement "publish to group" or whatever else they need using taxonomies.
#5
@
14 years ago
My quick fix for not showing future private posts on the front-end:
function fix_future_private( $sql, $wp_query ) {
global $wpdb;
$sql .= $wpdb->prepare( " AND $wpdb->posts.post_date <= %s", current_time('mysql') );
return $sql;
}
if ( !is_admin() )
add_filter( 'posts_where', 'fix_future_private', 10, 2 );
#9
follow-up:
↓ 10
@
13 years ago
- Cc danielbachhuber added
@kovshenin maybe we can assess this as a part of editorial flow user testing and make a decision what should be done. Personally, I think "Privately Published" is confusing but I don't know that deprecating it is the right answer.
It's also odd that the "View Page" link doesn't show:
#10
in reply to:
↑ 9
@
13 years ago
@danielbachhuber I agree, though I don't think deprecating the post status is the way to go. I think it can live, but perhaps it should become like any other post status, and not a UI of its own. I also think that scheduling a transition from one post status to another should work, regardless what the two statuses are, so the new statuses API (as discussed) should be flexible enough to support this.
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
8 years ago
#14
@
8 years ago
- Keywords needs-design added
I agree this should be fixed, we discussed as a team in queue triage today. It would be great to have a visual for this so adding tag for 'needs-design'.
This ticket was mentioned in Slack in #design by boemedia. View the logs.
7 years ago
This ticket was mentioned in Slack in #design by joshuawold. View the logs.
7 years ago
This ticket was mentioned in Slack in #design by michelemiz. View the logs.
7 years ago
This ticket was mentioned in Slack in #design by joshuawold. View the logs.
7 years ago
This ticket was mentioned in Slack in #design by boemedia. View the logs.
7 years ago
#20
@
7 years ago
This was discussed during design triage.
The flow for private and public posts should be the same. After updating, if it’s not published yet, it should remain "Scheduled", whether it's a private post or not.
So the status has two part: public or private, and scheduled or published or draft.
This seems like it needs a patch, not more design.
#21
@
6 years ago
- Keywords ux-feedback ui-feedback needs-design removed
I am going to remove the design keywords as yes I agree with you @ibdz so let's make sure this has the right keywords. Thanks for triaging!
#22
@
3 months ago
Reproduction Report
Description
This report validates that the issue can still be reproduced, but in a different way.
Environment
- WordPress: 6.9-alpha-60093-src
- PHP: 8.2.25
- Server: nginx/1.27.2
- Database: mysqli (Server: 8.4.4 / Client: mysqlnd 8.2.25)
- Browser: Chrome 138.0.0.0
- OS: macOS
- Theme: Twenty Twenty-Five 1.3
Actual Results
✅ Error condition somewhat occurs.
From the screenshot below, we can see that for every other status of the post, except private, namely public and protected, whenever we schedule a publish, on the posts list page, we see the keyword Scheduled attached to them.
But in the case of private, even though the post is scheduled to be published, there is no indication on the list. This will make accounting for the posts very difficult if the post list is very long and contains mixed statuses.
While the original issue reported has changed, the crux of the issue still remains.
Additional Notes
I think it would be much clearer and better if we could correctly display the scheduled status on the posts list.
Naturally, I would like to investigate further on this one and see the cause of the issue.
Supplemental Artifacts
Screencast of the editorial flow of scheduling private posts - Link
Screenshot of all three types of posts -
This ticket was mentioned in PR #9389 on WordPress/wordpress-develop by @abcd95.
3 months ago
#23
- Keywords has-patch added; needs-patch removed

Yeah, this is a UI issue. A post cannot be both future-scheduled and privately published.