WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 3 years ago

#14827 closed defect (bug)

Clean Up Updated Messages and UI for custom post types — at Version 9

Reported by: johnkolbert Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0.1
Component: Posts, Post Types Keywords: has-patch
Focuses: Cc:

Description (last modified by nacin)

I have two concerns with the post editor for custom post types. First, WordPress has built in generic notification messages when a post type is updated, saved as draft, etc. The only built in support is for posts and pages.

Custom post types must filter their own messages through 'post_updated_messages' filter independently. I propose a pre-built solution that automatically supports these custom update messages. Labels will be pulled from the $labels array defined when registering the custom post type. No new labels are needed, the existing ones are fine. My solution also adds a new filter {$post_type}_updated_messages, where developers can modify these generated messages as before if needed.

Secondly, custom post types listed as 'public' => false, and 'show_ui' => true are still shown "View Post", "Preview", and permalink editing boxes that all lead to a 404 error message. I propose checking if public is true before displaying these items.

I've attached a diff with these modifications. Feed back?

Change History (11)

comment:1 in reply to: ↑ description duck_4 years ago

Replying to johnkolbert:

I propose a pre-built solution that automatically supports these custom update messages. Labels will be pulled from the $labels array defined when registering the custom post type. No new labels are needed, the existing ones are fine.

#12968 and https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2010-05-25&sort=asc#m136782 for why this is bad for translation.

Haven't looked at the second part.

comment:2 johnkolbert4 years ago

  • Cc johnkolbert added

Correct me of I'm wrong, but labels for post types are translated when the post type is registered. So really we can leave that label out of the translation in this function, correct? I'm not around my computer now, but I'll upload another diff with th proposed change the evening.

comment:3 nacin4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

In terms of how translations work, this doesn't: __( $post_type_labels->singular_name . ' updated. ).

In terms of how languages work, this doesn't: __( "%s updated." ).

Regarding the first part: So, the way translations work is that strings are parsed by a tool that does not process PHP. Thus, any variable strings require us to substitute in using %s or %d, basically sprintf() format

Regarding the second part: We still can't do %s in most cases due to the way verbs get conjugated, adjectives have different forms based on the noun, etc. English is one of the exceptions here, where for the most part you can substitute a noun into a sentence and the rest of the sentence won't need a change. But in most languages, we will have serious issues. For more detail on the issues, and about our current stem: #12968.

We have a filter here, post_updated_messages, which was added in 3.0 specifically to allow for these messages to be changed on the post type level.

comment:4 nacin4 years ago

  • Keywords needs-patch added; post types notifications removed
  • Milestone set to 3.1
  • Resolution invalid deleted
  • Status changed from closed to reopened

I didn't see the second part of the patch. The check for 'public' seems to make sense there. Can you rewrite the patch to only include those improvements?

comment:5 nacin4 years ago

s/stem/system/ two comments up.

comment:6 johnkolbert4 years ago

Ok, I understand the problem with translation now. It'd be a nice automated feature, but since devs can hook into 'post_updated_messages' still, I suppose there isn't really an issue, though it would still be nice to format the filter {$post_type}_updated_messages and just send it $messages[$post_type], just for clarity.

I'm attaching a diff that only contains the checks for 'public'. If 'public' is set as false, the permalinks box and preview buttons will not be displayed in the post editor. Also, the 'Preview' and 'View' inline buttons that show up on mouseover in the post editing table (edit.php) are not displayed as well.

johnkolbert4 years ago

checks for public == true

comment:7 johnkolbert4 years ago

  • Keywords has-patch added; needs-patch removed

comment:8 nacin4 years ago

  • Description modified (diff)

A random style note, if ( public == true ) can simply be written as if ( public ). Otherwise, looks good.

comment:9 nacin4 years ago

  • Description modified (diff)
Note: See TracTickets for help on using tickets.