WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 9 months ago

#17609 reopened defect (bug)

'View post' link shown even when post type can't be viewed on the front-end

Reported by: scribu Owned by: nacin
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: has-patch
Focuses: Cc:

Description (last modified by scribu)

I have registered a CPT that's not meant to be displayed on the front-end:

        'public' => false,
        'show_ui' => true,

If I create such a post in the admin area, I still see the 'View post' link after saving and the 'Preview changes' button.

Both send me to the same URL, which gives a 404:

?post_type_name=single-post-slug

Related: #17040

Attachments (6)

17609.diff (4.1 KB) - added by mfields 3 years ago.
17609-new-strings.diff (1.2 KB) - added by mfields 3 years ago.
meta-boxes.php.diff (833 bytes) - added by intoxstudio 2 years ago.
17609-combo.diff (4.6 KB) - added by jmslbam 16 months ago.
class-wp-posts-list-table.patch (1.0 KB) - added by jfarthing84 10 months ago.
17609.2.diff (1.9 KB) - added by theaussiepea 9 months ago.

Download all attachments as: .zip

Change History (43)

comment:1 scribu3 years ago

  • Description modified (diff)

mfields3 years ago

comment:2 mfields3 years ago

  • Cc michael@… added
  • Keywords has-patch reporter-feedback added

I verified this while running trunk with my own custom post type. I've put together a patch which works well for me. This solution should work for all post_types. it will only print links to the front-end if the post type is "publicly queryable".

In hindsight, I think that the patch may do too much. I've also added code to dynamically populate the nouns in each message where appropriate. Instead of hardcoding "Post" it will use the singular label from the post_types labels array. This deviates a bit from the scope of this ticket. I thought that while I was in there I might as well address these issues too.

Definitely needs testing.

comment:3 dd323 years ago

Instead of hardcoding "Post" it will use the singular label from the post_types labels array. This deviates a bit from the scope of this ticket.

It also causes translation problems unfortunately, In quite a lot of languages you can't simply slot a "object label" into a generic string - In English this is no problem, but when you start to deal with feminine/mascular/cultural words, 'Page' and 'Post' require the strings around them to be translated differently.

If a plugin/theme wishes for their Messages to be translated, they should instead use the 'post_updated_messages' filter, as shown in the 2nd half of the example here: Function_Reference/register_post_type#Example

Given the above, The View Post link can already be removed by the plugin since they can modify their strings already.. I like the suggestion of using a placeholder for the "actions" attached, but this would also cause problems for those using the filter and expecting it to be a url (rather than an actual HTML link)

mfields3 years ago

comment:4 mfields3 years ago

Thanks for the detailed overview of some of the concerns with the first patch. Translation is definitely a topic that I can do to learn a lot more about. I have a second patch to offer for consideration (17609-new-strings.diff). This time, I stuck only to the topic of the ticket. Instead of modifying strings, I have introduced similar strings that will get used only when a custom post_type has not provided messages via the 'post_updated_messages' filter and the post_type is not publicly queryable.

comment:5 dgwyer3 years ago

Having the same problem. I can change the 'View Post', and 'Updated Post' phrases via the 'post_updated_messages' filter.

But the 'Preview' and 'Preview Changes' button in the Publish meta box seems hard coded in /wp-admin/includes/meta-boxes.php on line 51. The only way to remove this currently is via jQuery after the page has loaded?

Wouldn't it be sufficient to just add another filter to the Publish meta box so that you could modify the 'Preview' and 'Preview Change' buttons etc?

comment:6 tamlyn2 years ago

mfields' patch looks good to me. Any chance of getting this fixed in core?

comment:7 tamlyn2 years ago

  • Cc tamlyn added

comment:9 scribu2 years ago

  • Keywords reporter-feedback removed

comment:10 nacin2 years ago

  • Owner set to nacin
  • Status changed from new to reviewing

intoxstudio2 years ago

comment:11 intoxstudio2 years ago

I thought I'd searched for related tickets before I created one, but obviously I didn't do it well. Sorry about that.

I've had some thoughts since I made my ticket and read this one: Is there a reason why some post-related labels are stored in the post object while others aren't? (current labels vs. updated message labels)

Also, while the messages can be overwritten with a filter, the preview button cannot be removed without fiddling with some css (or js as already mentioned) which is not a proper solution I think.

comment:12 markoheijnen2 years ago

  • Cc marko@… added

Any changes this get in 3.4? I'm fine with the patch of intoxstudio only since that is the real problem.
The messages can be changed with the filter. Something what everyone probably should do.

comment:13 scribu2 years ago

  • Milestone changed from Future Release to 3.4

comment:14 husobj2 years ago

  • Cc ben@… added

comment:15 nacin2 years ago

  • Keywords commit added

When the post is published and there is no draft/pending button, there is some extra space in the publish box: http://cl.ly/161h1K29331V3I3Q1T21

This space is made due to the hidden draft-ajax-loading spinner. It uses visibility: hidden, as normally it should maintain its space.

What we'd need to do is calculate for when there is no button and at that point choose not to show the spinner either.

Regardless, the existing patch is better than what we have now.

comment:16 nacin2 years ago

In [20667]:

Don't show the 'Preview Changes' button for a non-public post type. props intoxstudio, see #17609.

comment:17 nacin2 years ago

  • Milestone changed from 3.4 to Future Release

comment:18 sc0ttkclark19 months ago

  • Cc lol@… added

I was a sad panda when I saw this issue come up in my testing, sad panda.

comment:19 SergeyBiryukov18 months ago

#22398 was marked as a duplicate.

jmslbam16 months ago

comment:20 jmslbam16 months ago

  • Cc info@… added

So I took the liberty of merging the two diffs of mfields so the current translations that are using the filter and expecting it to be a url (rather than an actual HTML link) like dd32 pointed out.

I really takes out the hassle of defining custom update messages just to have it say 'Book published'

comment:21 scribu16 months ago

@jmslbam: Please re-read dd32's comment: http://core.trac.wordpress.org/ticket/17609#comment:3

Version 0, edited 16 months ago by scribu (next)

comment:22 scribu16 months ago

  • Milestone changed from Future Release to 3.4
  • Resolution set to fixed
  • Status changed from reviewing to closed

Actually, this ticket was fixed with [20667], so get off my lawn and please open a new ticket for dealing with update messages.

comment:23 Jesper80016 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

This is actually not fixed. Viewing the fix, http://core.trac.wordpress.org/changeset/20667, you can see that it only checks for the "public" property of a post type. When a post type is public but not publicly queryable (public true, publicly_queryable false) posts of the post type are not available by default on the frontend, so the link should not be shown, but currently, they are.

A problem with this is that pages are not publicly queryable, as they are handled separately. What would be a good way to actually check whether a post is available on the frontend?

Last edited 16 months ago by Jesper800 (previous) (diff)

comment:24 Jesper80016 months ago

  • Cc jeve0@… added

comment:25 SergeyBiryukov16 months ago

  • Keywords commit removed
  • Milestone changed from 3.4 to Awaiting Review

comment:26 johnbillion16 months ago

  • Cc johnbillion added

comment:27 DrewAPicture13 months ago

#23814 was marked as a duplicate.

comment:28 netweblogic13 months ago

  • Cc msykes@… added

comment:29 Daedalon11 months ago

  • Cc daedalon@… added

comment:30 alex-ye11 months ago

  • Cc nashwan.doaqan@… added

comment:31 MikeHansenMe11 months ago

  • Cc mdhansen@… added

comment:32 toscho11 months ago

  • Cc info@… added

comment:33 jfarthing8410 months ago

  • Cc jeff@… added

Maybe I'm missing something, but this is a pretty simply fix of just checking publicly_queryable instead of public.

This also applies to a ticket I was going to create, but is actually closely related with this. That is, a View link is shown on the edit.php page even when a post type is not publicly_queryable, because yet again, the code checks public instead.

comment:34 jfarthing8410 months ago

For the record, this can be worked around by setting public to false, and then explicity setting show_ui to true, as well as all of the parameters that inherit from public. However, this shouldn't have to be done.

comment:35 bungeshea10 months ago

  • Cc info@… added

comment:37 theaussiepea9 months ago

Confirming that

class-wp-posts-list-table.patch

Removes the "View" option for each post in wp-posts-lists for custom posts. However, the permalink editing for the edit single post page (wp-admin/post.php) is still visible.

So I added to the patch so permalink editing does not appear in the edit single post page for custom post types that have 'publicly_queryable' set to false.

It seems to make sense to use 'publicly_queryable' instead of 'public' since 'publicly_queryable', in our testing, is what controls whether you can see the post at the specified permalink url. (After talking to Nacin, this is more complicated, so more work is needed)

Props to leogermani and ancawonka for their help!

theaussiepea9 months ago

Note: See TracTickets for help on using tickets.