WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 2 years ago

#37535 new enhancement

Outputting Post Type Description on admin edit screen

Reported by: simonrcodrington Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.6
Component: Posts, Post Types Keywords: has-patch has-ui-feedback has-screenshots
Focuses: ui, administration Cc:
PR Number:

Description

When registering a custom post type you canspecify the description as part of the arguments you pass into register_post_type. I would expect that somewhere in the back-end of WP this description would be shown, however it isn't.

It would be great if we could output the description right below the title of the post type when viewing the entries table (as I've done below)

https://goo.gl/IwzNmi

I've updated edit.php inside of wp-admin and added the following code after the main H1 tag

<?php
//output description if set
if($post_type_object->description){
	echo '<p class="description">';
		echo esc_html( $post_type_object->description);
	echo '</p>';	
}?>

It's a pretty small update but its pretty useful for clients so that know what this admin edit screen is for. I use them for outlining what type of content will be added here.

If the content type doesn't have a description nothing is outputted.

I can submit a pull request since it's a fairly straightforward change.

Cheers

Simon

Attachments (4)

post_type_description_admin.jpg (47.1 KB) - added by simonrcodrington 3 years ago.
Image of the admin edit screen
post_type_description_admin_mobile.jpg (35.5 KB) - added by simonrcodrington 3 years ago.
Post edit screen (when viewed on mobile)
post_type_description_editphp.jpg (87.9 KB) - added by simonrcodrington 3 years ago.
edit.php after editing
37535-01.patch (600 bytes) - added by Jonnyauk 3 years ago.
I like this idea, would be improve UX for content editors (esp as there is no hook for developers to insert it, so a patch to core is the only way to achieve this)

Download all attachments as: .zip

Change History (21)

@simonrcodrington
3 years ago

Image of the admin edit screen

@simonrcodrington
3 years ago

Post edit screen (when viewed on mobile)

@simonrcodrington
3 years ago

edit.php after editing

#1 @swissspidy
3 years ago

  • Component changed from Administration to Posts, Post Types
  • Focuses ui administration added

@Jonnyauk
3 years ago

I like this idea, would be improve UX for content editors (esp as there is no hook for developers to insert it, so a patch to core is the only way to achieve this)

#2 @simonrcodrington
3 years ago

Exactly what I was thinking @Jonnyauk . I couldn't see any other way to output content / helpful info in that place besides editing the file directly. I also don't know where the 'Description' is ever used (or why it exists if it's never used?)

It would be great to either display the description there or to add a hook so theme / plugin devs can add content there if they require.

Cheers

#3 @Jonnyauk
3 years ago

@simonrcodrington no problem ;) Yes, I think this would be really useful from a UX point of view. By default the description is not used by default in themes generally, but when I'm building custom themes I sometimes do bring it onto the top of custom post archives ;)

#4 @Jonnyauk
3 years ago

  • Keywords has-patch added

#5 follow-up: @joemcgill
3 years ago

  • Keywords ui-feedback added

I like the idea of being able to display this information in the admin in some useful way. I wonder if there are other use cases where adding an action hook here would be preferable?

#6 @swissspidy
3 years ago

  • Keywords has-screenshots added

#7 in reply to: ↑ 5 ; follow-up: @mikeschroder
3 years ago

Immediate thoughts--

Like this idea.

Top of mind concerns would be:

  • Current use cases for the description field -- as you stated, if it's not being output in the admin, what are the current expections/widest uses for the field?
  • Is there content not suitable for display that developers are storing in them, since there's no expectation of admin output?

#8 in reply to: ↑ 7 @simonrcodrington
3 years ago

Hey Mike, thanks for having a look at this ticket.

The way I see the description arg being useful when registering post types is by providing useful info about what this post type does / can do. For example on staff content types I've dynamically outputted text on the admin posts pages (via JS) that's helpful to the site admins / users, letting them know what this content type is and how to manage it.

From what I see, I don't think the description is used anywhere, which is a real waste as it should live on the posts admin page as that's where most people will spend their time managing content..

In regards to the field. When you pass your description as an argument you can only pass in text. I'm not sure what would happen if you pass in a string that's actually a HTML block. When it's being outputted in my proposed code above I've ran it through esc_html but it could easily be adjusted on the output side (or via a filter?)

It would be great to get more feedback on this. It's a small change, but overall would make explaining to people what all these content types do easier.

Replying to mikeschroder:

Immediate thoughts--

Like this idea.

Top of mind concerns would be:

  • Current use cases for the description field -- as you stated, if it's not being output in the admin, what are the current expections/widest uses for the field?
  • Is there content not suitable for display that developers are storing in them, since there's no expectation of admin output?

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


2 years ago

#10 @karmatosed
2 years ago

  • Keywords has-ui-feedback added; ui-feedback removed

This design seems to work and fit patterns. I will remove the ui-feedback as a result.

#11 @simonrcodrington
2 years ago

Hey guys

Does this seem like a good fit for an upcoming version? I'd be keen on getting this into core at some point so we can start setting post type descriptions.

Cheers

#12 @swissspidy
2 years ago

  • Milestone changed from Awaiting Review to 4.9

Worth noting that post type descriptions will now be displayed on the front end when using get_the_archive_description(), see #38487.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


2 years ago

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


2 years ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


2 years ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


2 years ago

#17 @jbpaul17
2 years ago

  • Milestone changed from 4.9 to Future Release

Punting this to Future Release per the 4.9 bug scrub earlier today.

Note: See TracTickets for help on using tickets.