WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#9674 closed task (blessed) (fixed)

Better support for custom post types

Reported by: wnorris Owned by: ryan
Milestone: 3.0 Priority: normal
Severity: normal Version: 2.9
Component: Administration Keywords: has-patch tested early
Focuses: Cc:

Description

Similar to the improved support for custom taxonomies in WP 2.8, we really need to have better support for custom post types. At the database layer, this is completely supported, and used for things like post revision, attachments, pages, etc. However, the administration pages used to manage these objects (edit-page-form.php and edit-form-advanced.php for example) contain lots of duplicated code, and do not expose any of their functionality in a way that is re-usable by plugins, or other parts of WordPress.

Correcting this will take a bit of work, so I'll be using this ticket to track progress. (I'm surprised I didn't find an existing ticket for this... if there is one, I'll use that instead)

Attachments (39)

meta_boxes.diff (58.6 KB) - added by wnorris 5 years ago.
meta-boxes.diff (91.4 KB) - added by wnorris 5 years ago.
Updated patch, for WP 2.9
9674.diff (23.3 KB) - added by ryan 5 years ago.
9674.2.diff (53.6 KB) - added by ryan 5 years ago.
9674.3.diff (56.1 KB) - added by scribu 4 years ago.
Replace 'Edit Post' with 'Edit Thingy'; adds 'add_meta_boxes' hook
include-exclude-boxes.php (197 bytes) - added by scribu 4 years ago.
Example usage for 'add_meta_boxes' hook
9674.4.diff (56.8 KB) - added by scribu 4 years ago.
Replace 'Edit Post' with 'Edit Thingy' and 'Add New Post' with 'Add New Thingy'
9674.5.diff (57.2 KB) - added by scribu 4 years ago.
Resolve conflict with [12132]
9674.6.diff (58.2 KB) - added by scribu 4 years ago.
Resolve conflict with [12144]
9674.7.diff (32.2 KB) - added by scribu 4 years ago.
Resolve conflict with [12162]
9674.8.diff (32.0 KB) - added by ryan 4 years ago.
Bring up-to-date with 12559
post-types-dialogue.png (151.8 KB) - added by mikeschinkel 4 years ago.
Dialog for Post Types Plugin (as of 2009-12-28)
9674.9.diff (32.0 KB) - added by ryan 4 years ago.
Minor cleanups
9674.10.diff (58.4 KB) - added by ryan 4 years ago.
Menu parenting fix for edit-tags.php. Add is_object_in_taxonomy().
9674.11.diff (4.3 KB) - added by ryan 4 years ago.
Post type capabilities (incomplete and untested)
9674.12.diff (7.9 KB) - added by ryan 4 years ago.
Post type capabilities (tested)
post-type.php (223 bytes) - added by ryan 4 years ago.
Test plugin, drop in mu-plugins dir
9674.13.diff (2.2 KB) - added by dd32 4 years ago.
9674.14.diff (19.1 KB) - added by ryan 4 years ago.
Merge edit-page-form.php into edit-form-advanced.php
9674.15.diff (9.3 KB) - added by ryan 4 years ago.
register_post_status() and friends
9674.16.diff (66.5 KB) - added by ryan 4 years ago.
Merge edit-pages.php into edit.php, introduce $current_screen, and more
post.diff (1.5 KB) - added by waltervos 4 years ago.
Replaces my previous post.diff. This diff makes default => public in register_post_status and register_post_type comply with the documentation by making it default to true.
9674-183.patch (416 bytes) - added by prettyboymp 4 years ago.
allows installs without permastructure set to use ?p=post_id to display custom post_types
9674.17.diff (3.9 KB) - added by prettyboymp 4 years ago.
allows post_type to be set as public query var by limiting it to post_types with 'publicly_queryable' value set to true
9674_pluralcaps.diff (570 bytes) - added by technosailor 4 years ago.
9674.18.diff (455 bytes) - added by prettyboymp 4 years ago.
modifies handling for single template to first check for %post_type%.php template
register_meta_box_cb.diff (2.6 KB) - added by ryan 4 years ago.
Allow registering a meta box callback for setting up meta boxes when creating the edit form for the post type.
9674_taxonomies.diff (1.3 KB) - added by technosailor 4 years ago.
Support default registration of post_tag and category taxonomies for custom content type
9674.19.diff (409 bytes) - added by prettyboymp 4 years ago.
Include $leavename variable in 'post_type_link' filter
register_post_type_description.diff (1.7 KB) - added by ptahdunbar 4 years ago.
register_post_type() should have a description arg which could be displayed in the UI or used with plugins.
changes.diff (1.0 KB) - added by jfarthing84 4 years ago.
post.php.diff (923 bytes) - added by jfarthing84 4 years ago.
Can we please get this or something similar commited?
inline-edit-post.dev.js.diff (367 bytes) - added by jfarthing84 4 years ago.
Actually, just change the variable to 'typenow' in the POST data.
admin-ajax.php.diff (635 bytes) - added by jfarthing84 4 years ago.
Another instance where checking against 'show_ui' is being used and should be changed to check for public in admin-ajax.php for inline-save (which breaks inline saving for custom created UI's not using 'show_ui' argument
template.php.diff (1.8 KB) - added by jfarthing84 4 years ago.
Fix trash/untrash/delete links for custom post types.
inline-edit-tags.diff (1.0 KB) - added by prettyboymp 4 years ago.
only show tags in inline-edit for post_types that support them
inline-edit-tags.2.diff (1.0 KB) - added by prettyboymp 4 years ago.
checked against wrong taxonomy, fixed check against post_tag
inline-edit-custom-taxonomies.diff (9.6 KB) - added by prettyboymp 4 years ago.
adds support for custom taxonomies to inline-edit
post.php.2.diff (4.9 KB) - added by mikeschinkel 4 years ago.
Update to /wp-includes/post.php to add a filter called 'initial_post_types'

Download all attachments as: .zip

Change History (329)

wnorris5 years ago

comment:1 wnorris5 years ago

  • Keywords has-patch needs-review added

So as a first step, I've moved all of the meta_box functions into a separate file, and removed all of the duplicate code. Specifically...

  • moved all *_meta_box functions into wp-admin/includes/meta_boxes.php
  • removed page_password_meta_box and post_password_meta_box, since those are part of the publish box, and weren't being used anyway
  • went through each of the page meta box functions, and modified the corresponding post meta box function to accommodate different post types. This was actually very straightforward for all but the publish meta box. Even then, it's not too bad... just a couple of if ($post_type == 'post') to conditionally show the sticky checkbox.
  • updated edit-page-form.php to use the post meta box functions where possible. The only page meta box function left is for page attributes.

With the exception of dropping the password meta box functions (which wasn't being used by WP core), these changes shouldn't introduce any backwards compatibility issues.

This patch is only a first step toward better support for custom post types, but one that can be applied immediately without worrying about compatibility issues. It sets up a lot of the other changes that will need to happen.

comment:2 Denis-de-Bernardy5 years ago

  • Keywords early added
  • Milestone changed from Unassigned to 2.9

probably a bit too large for 2.8, but good candidate for 2.9 early imo.

comment:3 aesqe5 years ago

  • Cc aesqe@… added

comment:4 ryan5 years ago

I like all of the red in that patch. Definitely good for early 2.9.

comment:5 ryan5 years ago

  • Owner changed from anonymous to ryan
  • Status changed from new to accepted

comment:6 scribu5 years ago

  • Cc scribu@… added

comment:7 chrisscott5 years ago

  • Cc chrisscott added

comment:8 Denis-de-Bernardy5 years ago

  • Keywords needs-patch added; has-patch needs-review removed

comment:9 Denis-de-Bernardy5 years ago

  • Type changed from defect (bug) to feature request

comment:10 prettyboymp5 years ago

  • Cc prettyboymp added

comment:11 henrikmelin5 years ago

  • Cc h.melin@… added

comment:12 JohnMyr5 years ago

  • Cc JohnMyr added

comment:13 ryan5 years ago

Patch needs refresh and meta_boxes.php should be meta-boxes.php.

comment:14 ryan5 years ago

  • Type changed from feature request to task (blessed)

wnorris5 years ago

Updated patch, for WP 2.9

comment:15 wnorris5 years ago

I've updated the patch for the current trunk. This does effectively the same thing as the old patch, with the addition of moving over link related meta_boxes to the meta-boxes.php file. None of these are really able to be re-used in WordPress core (like the page and post ones were), but it's good to have them pulled out so that plugins can use them.

comment:16 scribu5 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

comment:17 westi5 years ago

Kicking the tires on this now and all looks good.

Will place into trunk to get some more testing and leave this open for now for any tidy up issues.

comment:18 westi5 years ago

(In [11815]) Refactor the meta boxes out of the edit pages and into an include file. See #9674 props wnorris.

comment:19 follow-up: wnorris5 years ago

westi: looks like your commit missed adding the includes/meta-boxes.php file :)

comment:20 in reply to: ↑ 19 westi5 years ago

Replying to wnorris:

westi: looks like your commit missed adding the includes/meta-boxes.php file :)

I always forget to check for new files :-(

[11816]

comment:21 themattharris5 years ago

  • Cc themattharris added

comment:22 scribu5 years ago

Related: #10717

comment:23 ryan5 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

Let's call this part done. Open new tickets against a future release for further custom post type work.

comment:24 ryan5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

ryan5 years ago

comment:25 ryan5 years ago

Oh, what the heck, might as well give all of this a purpose in 2.9. Patch allows registering a post type and having it appear in the menus as a new object type. Taxonomies registered for the post type will also show in the menus. edit-tags.php is not post_type aware, yet. Drop post-type.php in mu-plugins to test.

comment:26 markjaquith5 years ago

How would you view them? Would you have to explicitly query them in a template? It generates post permalinks that don't work. (still, wow, you should get bored more often)

comment:27 ryan5 years ago

I have no idea how they would be viewed. Maybe all of the people who keep asking for it could fill me in. :-) I'm guessing they just want ways of adding and editing objects that can be later queried in their templates.

ryan5 years ago

comment:28 ryan5 years ago

Anyhow, enough playing. This is probably too much for 2.9. I did run across a couple of bugs in the process. I'll do separate patches for those.

comment:29 Denis-de-Bernardy5 years ago

Replying to ryan:

I have no idea how they would be viewed. Maybe all of the people who keep asking for it could fill me in. :-) I'm guessing they just want ways of adding and editing objects that can be later queried in their templates.

Personally, I can picture myself trying to use this stuff to manage typed data through the WP API, without needing to rewrite the various WP functions to generate post meta boxes and the like. Actual page generation would be handled by the plugin. It's clearly not WP's job to handle it imo. :-)

This prompts me to ask a few questions, though...

Some of the typed data is so special that it really doesn't belong in the posts table with boat loads of other things. Yet many of the built-in admin functions are useful. A quick glance at the meta-boxes.php file reveals the assumption that things are always stored in the wp_posts table. It's arguably better, but definitely not ideal imo.

Other note: the get_permalink() function is missing custom post type handling in trunk.

comment:30 willmot5 years ago

  • Cc willmot added

comment:31 follow-up: Denis-de-Bernardy5 years ago

Following up on the previous remark...

some kind of is_custom() function would be useful, and a means to bypass the WP query entirely in the workflow immediately after the query is parsed. else WP_Query may get loaded with junk.

init_query_flags() for instance, probably also needs some reference to is_custom = false. after parse_query is done, $wp_query filters itself through do_action_ref_array(), and if it ends up with is_custom set to true at that stage, the actual WP query gets skipped entirely -- WP should then make the assumption that it has been set up already.

I don't think we actually need anything in the template loader, since there is a hook in there already. But there definitely needs something over in the wp_query query class to go something like: please bail the WP query.

comment:32 sivel5 years ago

So far I am loving this. Great work Ryan. Is it possible you could let us know what bugs you have run across? With not having even hit beta yet I really see no reason we cannot get this into 2.9 since a large majority of the work has been completed already. Even if we only get some of the basic functionality of this into 2.9 it would still be a big help and a basis of something to build off of for 3.0.

comment:33 sivel5 years ago

  • Cc matt@… added

comment:34 joehoyle4 years ago

  • Cc joehoyle added

comment:35 ryan4 years ago

I don't know if I'll have time to drive this for 2.9. I need to get some work done on the unified upgrader. Assuming we have someone to drive it and everyone agrees to put it on the schedule for 2.9 during the next dev meeting, here are some of the remaining things that would need to be done.

  • Fix Quick Edit. It eats data for custom post types.
  • Make edit-tags.php post type aware and get the menus working for edit-tags.php?taxonomy=foo&post_type=bar
  • Fix screen options for both custom taxonomies and post types. They share with the default taxonomy and type at the moment.
  • Easy means of including/excluding metaboxes from the custom post type edit screen. Maybe register a callback that does remove_meta_box() and add_meta_box() calls.
  • Make sure we don't bust everything in the process. :-)

comment:36 dj-wp4 years ago

  • Cc jdelisle@… added

comment:37 rmccue4 years ago

  • Cc ryanmccue@… added

comment:38 gcorne4 years ago

  • Cc gcorne added

comment:39 scribu4 years ago

9674.3.diff uses get_post_type_object() instead of in_array() and replaces 'Edit Post' with 'Edit Thingy'.

scribu4 years ago

Replace 'Edit Post' with 'Edit Thingy'; adds 'add_meta_boxes' hook

scribu4 years ago

Example usage for 'add_meta_boxes' hook

comment:40 scribu4 years ago

  • Keywords tested added; needs-testing removed

I've tested 9674.4.diff on a site with 2 custom post types, with real data and it's working great.

The issues mentioned by ryan seem minor and can be addressed in separate patches.

scribu4 years ago

Replace 'Edit Post' with 'Edit Thingy' and 'Add New Post' with 'Add New Thingy'

scribu4 years ago

Resolve conflict with [12132]

scribu4 years ago

Resolve conflict with [12144]

comment:41 GIGALinux4 years ago

  • Cc GIGALinux added

I've tested the last patch (9674.6.diff), works great.

But "Add New Posts" is wrong, maybe add to register_post_type a new parameter like "name"?

scribu4 years ago

Resolve conflict with [12162]

comment:42 grosbouff4 years ago

  • Cc grosbouff added
  • Type changed from task (blessed) to feature request

@All : this is exactly what is missing in Wordpress.
We need this !!!

I successfully patched the wordpress 2.9 (from SVN) files and it seems to work. I got the "thingy" menu in WP and I can add tags. But not categories. Is it a bug ?
How can I do this ?

@Ryan : you said : "Drop post-type.php in mu-plugins to test" : how do you make this work under WPMU ? I'm really interested in it.

Thanks !

comment:43 grosbouff4 years ago

  • Type changed from feature request to task (blessed)

(oups sorry I changed the type... I'm not used to post on tracs :))

comment:44 ryan4 years ago

  • Milestone changed from 2.9 to 3.0

We'll land this early in the 3.0 dev cycle.

comment:45 aaroncampbell4 years ago

  • Cc aaron@… added

comment:46 tturner4 years ago

  • Cc tturner added

comment:47 mikeschinkel4 years ago

  • Cc mikeschinkel@… added

comment:48 jeremyclarke4 years ago

  • Cc jer@… added

comment:49 beaulebens4 years ago

  • Cc beau@… added

comment:50 patrickhoefler4 years ago

  • Cc patrick@… added

comment:51 ryan4 years ago

Let's update scribu's latest patch and have this ready to pitch at the January dev meetup we're we'll be deciding on 3.0 features.

comment:52 sirzooro4 years ago

  • Cc sirzooro added

comment:53 carlosmendoza4 years ago

  • Cc carlosmendoza added

ryan4 years ago

Bring up-to-date with 12559

comment:54 follow-up: ryan4 years ago

There have been suggestions to refer to post type as content type in the API.

comment:55 janeforshort4 years ago

Per Ryan's comment, some of the thinking behind using 'content types' rather than 'post types' as a label is because the end user generally thinks of post types in terms of having a different template for a specific type of post, like a review, recipe, blog post, aside, etc., and doesn't think about it in CMS terms (products, listings, etc).

comment:56 scribu4 years ago

Using "content type" as a label makes sense.

Will this affect the wp_posts table or function names?

comment:57 scribu4 years ago

It would be a real pain to rename the column in the wp_posts table and all the functions that use post_type. Plus, if the table is called wp_posts, it wouldn't really help anything.

Having only the functions and arguments renamed would actually add cognitive load.

So the only place we could use "Content Type" would be in the admin. But with the current patch, I don't see any appearance of "Post Type".

comment:58 filosofo4 years ago

Replying to ryan:

There have been suggestions to refer to post type as content type in the API.

How about something else, such as "object type"? The problem with "content type" is that "content-type" has well-known MIME / HTTP header definitions, so if we use it here it's guaranteed to cause confusion, especially in the context of media attachments.

Besides, "content" is only part of what posts, pages, attachments, etc. comprise. They differ not just in content but in function, modality, etc.

comment:59 mikeschinkel4 years ago

  • Version changed from 2.8 to 2.9

I agree with @scribu; calling it something other than post type will just add confusion. In the Drupal world they have content and node and it means the same thing and I witnessed far too much confusion over that term; it wasn't worth it.

Strongly believe that you should stick with "Post Type" and then just educate people what it means. That terminology is not that difficult for people to grasp.

comment:60 technosailor4 years ago

  • Cc technosailor added

How safe is it to assume that 9674.8.diff is pretty darn close to what the final implementation of Custom Post/Content Type UI will look like?

comment:61 in reply to: ↑ 54 ; follow-up: mikeschinkel4 years ago

Replying to ryan:

attachment 9674.8.diff added

Hey Ryan, can you describe where I'm support to find these changes in the UI? I've installed a patched copy and can't find anything in the admin that is different from 2.9.

The reason I ask is I'm working on a Post Type plugin that allows the user to specify custom post types and I want to make sure I don't duplicate functionality. Ideally, I'd prefer to use anything you do instead of coding it myself, or if you'd like I can donate my plugin code into the core. It's not complete yet but I've uploaded a screen shot for you to see what it (currently) looks like.

mikeschinkel4 years ago

Dialog for Post Types Plugin (as of 2009-12-28)

comment:62 dd324 years ago

How safe is it to assume that 9674.8.diff is pretty darn close to what the final implementation of Custom Post/Content Type UI will look like?

Looking at the patch, It seems it pretty much mimicks the current Post/Page screen, Which is what i'd expect. There'll be subtle changes here and there i'd say though.

Slight bug in the code:

$user_posts_count = $wpdb->get_var( $wpdb->prepare("SELECT COUNT(1) FROM $wpdb->posts WHERE post_type = 'p%s' AND post_status != 'trash' AND post_author = %d", $post_type, $current_user->ID) ); 

That should be written as ...post_type = %s AND...}

comment:63 in reply to: ↑ 61 scribu4 years ago

Replying to mikeschinkel:

Replying to ryan:

attachment 9674.8.diff added

Hey Ryan, can you describe where I'm support to find these changes in the UI? I've installed a patched copy and can't find anything in the admin that is different from 2.9.

You have to register a new post type first. See post-type.php


The reason I ask is I'm working on a Post Type plugin that allows the user to specify custom post types and I want to make sure I don't duplicate functionality. Ideally, I'd prefer to use anything you do instead of coding it myself, or if you'd like I can donate my plugin code into the core. It's not complete yet but I've uploaded a screen shot for you to see what it (currently) looks like.

The plugin should stay a plugin, IMO. Just like there's a plugin for managing custom taxonomies from the admin - Simple Taxonomies.

comment:64 scribu4 years ago

Shouldn't the current patch get committed already so that it can be polished?

comment:65 ryan4 years ago

I'd like to decide on nomenclature first so we're not bouncing function names. Getting away from post type would be good because of the conflict the notion of post templates and because the functions that play with the post_type field already suck up some of the good *_post_type field. I have no problem having post_type in the db and the use of it higher up the stack by a different term. Content type could cause confusion with content-type, as noted above. Object type may be a bit too generic, but we already use object for things like wp_get_object_terms(), is_object_in_term(), get_object_taxonomies(), etc. Extending the use of object to maintain consistency with the taxonomoy object API may be the way to go.

comment:66 ryan4 years ago

Let's make that a little more readable:

Getting away from post type would be good because of the conflict with the notion of post templates and because the functions that play with the post_type field already suck up some of the good *_post_type function names.

ryan4 years ago

Minor cleanups

comment:67 follow-up: ryan4 years ago

Small cleanups including fix for bug noted by dd32. Renames register_taxonomy_for_post_type() to register_taxonomy_for_object_type() since all of the other object/taxonomy functions use the term object instead of post.

ryan4 years ago

Menu parenting fix for edit-tags.php. Add is_object_in_taxonomy().

comment:68 scribu4 years ago

object_type sounds better than content_type.

comment:69 in reply to: ↑ 67 ; follow-up: strider724 years ago

Replying to ryan:

Renames register_taxonomy_for_post_type() to register_taxonomy_for_object_type()

Did you rename the existing function or simply create an additional function?

If replacing one with the other, it seems the old one should be moved to the deprecated.php file, and (perhaps) be made a simple wrapper for the new function to ensure they remain in parity with each other.

comment:70 mikeschinkel4 years ago

@scribu object_type sounds better than content_type.

Pros for object_type: Consistent with certain other internals.

Cons for object_type: Too generic and abstract for most end users to grasp.

@ryan: Getting away from post type would be good because of the conflict with the notion of post templates

Mind if I ask you to elaborate on why this is an issue? Not being a core developer I'm not aware of why it's a problem.

@ryan: because the functions that play with the post_type field already suck up some of the good *_post_type function names.

Can you give examples of these functions names you need?

I'm particularly interested in this topic because 1.) I so badly need it and 2.) I am working on a plugin to manage post types and I don't want to build an orphan.

FWIW I'll restate, if at all possible I think you should stick with the term "post type." You can refer to them as "Custom post types" which handles the distinction between core (post,page,revision,attachment) and user defined. But adding another name will cause far more confusion that it might resolve if experience in Drupal is any indication.

That said, if you must rename it I'd propose item type or record type, in that order of preference. Most computer users have some idea what those terms mean vs object which I believe mostly only programmers understand.

@scribu - You have to register a new post type first. See post-type.php

Yeah, the custom post types plugin I'm working on registers post types during the init hook for types defined by the user in the admin console.

I've actually run into a problem with it from the standpoint of persistence; if I persist to disk them reload them I have to decide which takes precedence; the deserialized version from the database or $wp_post_types?

@scribu - The plugin should stay a plugin, IMO. Just like there's a plugin for managing custom taxonomies from the admin - Simple Taxonomies.

Maybe, but my jury is out on that one still. However, what we definitely need in core is more infrastructure. For example (as I build the plugin I realize) we need a standard way to persist post types. I'll throw out this strawman: let's save wp_post_types to wp_options as 'post_types' using save_post_types() and load_post_types() functions, as simple as this:

function save_post_types() {
   update_option( 'post_types', $wp_post_types );
}
function load_post_types() {
   global $wp_post_types;
   $wp_post_types = update_option( 'post_types');
}

Then add a "$persist" parameter defaulted to true to register_post_types() so that save_post_types() runs at the end by default like so:

function register_post_type($post_type, $args = array(), $persist=true) {
   global $wp_post_types;

   if (!is_array($wp_post_types))
      $wp_post_types = array();

   $defaults = array('exclude_from_search' => true);
   $args = wp_parse_args($args, $defaults);

   $post_type = sanitize_user($post_type, true);
   $args['name'] = $post_type;
   $wp_post_types[$post_type] = (object) $args;

   if (save_post_types())
      save_post_types();
}

Next change create_initial_post_types() so that it loads at first then saves only once. This will allow core post types to be (re-)registered if need be. This of course needs to run prior to any plugin register_post_type()s can run (I assume that is already the case?)

In addition I added another global $wp_core_post_types so that plugins can know which post types are sacred to Wordpress core.

function create_initial_post_types() {
   global $wp_core_post_types;
   $wp_core_post_types = array('post','page','attachment','revision');
   
   load_post_types();
   register_post_type( 'post', array('exclude_from_search' => false), false );
   register_post_type( 'page', array('exclude_from_search' => false), false );
   register_post_type( 'attachment', array('exclude_from_search' => false), false );
   register_post_type( 'revision', array('exclude_from_search' => true), false );
   save_post_types();
}

We might also want to add a standard "property" to the post_type array like 'is_core' and/or 'user_defined.' Or maybe 'can_delete?' Not knowing exactly how post_types will be used by everyone I'm trying to figure out what standard property(s) would be useful so that one plugin's use of post_types doesn't step on anothers. Clearly I haven't figured this one out yet.

comment:71 in reply to: ↑ 69 ryan4 years ago

Replying to strider72:

Replying to ryan:

Renames register_taxonomy_for_post_type() to register_taxonomy_for_object_type()

Did you rename the existing function or simply create an additional function?

Renamed since that function is new with this patch. It is not already in WP.

comment:72 aaroncampbell4 years ago

Just to put this out there, the existing *_post_type functions are:

  • get_post_type
  • get_post_types
  • register_post_type
  • set_post_type

I'm all for parting from the post_type name, because people have a hard time seeing that as anything other than types of posts. They'd see that as an article vs a tip vs a review, but not as an attachment or a podcast or even a page. As for what else you choose, I think object_type is good, but if it's too "programmer friendly" and not user friendly, then I'm fine with item_type as suggested above.

comment:73 ryan4 years ago

The main argument for "object", I think, is that it is already used in the taxonomy and menu APIs to refer to posts table entities.

Jane addressed post type/post template earlier.

I personally don't really care. :-) I just want to avoid juggling names, especially given the interest there is in jumping on this as soon as it lands.

register_post_type(), get_post_types(), and get_post_type_object() would get the new naming, if we switch terminology. get_post_type() and set_post_type() would likely keep their names since they are set/gets for the post_type field.

comment:74 follow-up: scribu4 years ago

So we would have:

  • register_object_type()
  • get_object_types()
  • get_object_type_object() ?

Maybe we should call it get_object_type_properties() instead.

comment:75 mikeschinkel4 years ago

And for accessing the object's metadata, don't we also get?

get_object_type_object_type_object()

Sorry, I just couldn't resist. ;-p

Seriously, "object" is a great term for use inside the code but if you must, must, must rename it please use "item" or "record."

For that matter, since this really is a big deal why not put up a poll on Wordpress.org to see what the majority of people think? Maybe we'll learn that "post" is not so bad. Or maybe we'll learn it is horrible. But why not verify before making a decision based on all of our (flawed by nature) biases and assumptions?

@ryan: also can you please speak to the idea of having a standard way to persist custom post types?

That said, I'd like to propose an additional change to register_post_type() and that would be to include a filter. Such a filter would allow a plugin to annotate metadata to any of the core post types or even post types registered:

  function register_post_type($post_type, $args = array(), $persist=true) {
   global $wp_post_types;

   if (!is_array($wp_post_types))
      $wp_post_types = array();

   $defaults = array('exclude_from_search' => true);
   $args = wp_parse_args($args, $defaults);

   $post_type = sanitize_user($post_type, true);
   $args['name'] = $post_type;
   $args = apply_filter('register_post_type',$args);
   $wp_post_types[$post_type] = (object) $args;

   if (save_post_types())
      save_post_types();
}

For that matter it would also be good to have hooks for save_post_types() and load_post_types():

function save_post_types() {
   global $wp_post_types;
   $wp_post_types = apply_filter('save_post_types',$wp_post_types);
   update_option( 'post_types', $wp_post_types );
}
function load_post_types() {
   global $wp_post_types;
   $wp_post_types = apply_filter('load_post_types',get_option( 'post_types'));
}

comment:76 mikeschinkel4 years ago

@ryan: I just found/read @janeforshort's comments which I'll include here:

@janeforshort: Per Ryan's comment, some of the thinking behind using 'content types' rather than 'post types' as a label is because the end user generally thinks of post types in terms of having a different template for a specific type of post, like a review, recipe, blog post, aside, etc., and doesn't think about it in CMS terms (products, listings, etc).

I see her point for existing Wordpress sites but honestly think once custom post types because more exposed in Wordpress then that point become moot.

I'm pretty sure people don't think much about templates vs. posts, they think about reviews, recipes, blog posts, asides, products, listings, etc. Once they can go in an create a custom post type called "review", "recipe", "product" or "listing" rather than have to create a post template that makes a (blog) post behave like one of them then users will do that because doing so will provide them more appropriate functionality.

(BTW, I don't see how a review or a recipe is conceptually any different than a product or a listing. They all have custom attributes that identify them separately from a generic post.)

What's more there will mostly be a one-to-one correspondence between custom post types and custom post templates just as there already are different templates for each of posts, pages and attachments and for my plugin each custom post type gets its own custom post type template. So rather than argue for a new term I really think @janeforshort's point argues to keep the term "post type" if, as she says, people think in terms a "post type" meaning "a different template."; that's exactly the association we'll want them to have, i.e.

Using a custom post type equates to using a template for a custom type of content

comment:77 janeforshort4 years ago

Mike, I think you misunderstood what I was trying to say. What developers call post types is different from what users call post types, and your assertion that the two aren't really different isn't correct (at least based on the conversations about post types I've had with users and developers and the features they request around them). Having a separate post type vs adding some custom fields or a special display has impacts on site organization, search, taxonomies, etc. You also make a statement about existing vs future users, but documentation and how we describe functions to new users is an important factor to consider. Just try teaching a new user about Pages and you'll see what I mean ("Go to the page, no, the Page, not the screen," etc).

The end result of this discussion isn't something I'm overly passionate about, I just think it's important to think about how we use common words with multiple uses in describing functions, especially if it will make it harder to clarify them in the future. If I could get rid of the Pages label and call them static posts or something, I'd do it in a New York minute, but it's a little late in the game to suggest such a thing. This discussion is simply raising the issue so we can be sure we are using the least ambiguous and/or potentially confusing language possible. I could put up a poll on the dev blog if people really think it will help, but to be honest, I think custom post types would be so misunderstood by the common user without pages of explanation, and in contrast are already so accepted by the advanced developers, that it would be difficult to get a meaningful set of results.

comment:78 greenshady4 years ago

I have loads of users that know well what the term "post type" means. They know that "page" and "attachment" are certain types of posts. Maybe my theme/plugin users are just smarter than the average user; I don't know. I say we stick with what we already have -- "post type." My opinion is based on several conversations with average users, not other WP developers. I think changing the terminology now just confuses matters more.

Object type? Seriously? While I wouldn't mind that as a developer, it's not something that would get end users excited.

comment:79 follow-ups: mikeschinkel4 years ago

@janeforshort: Mike, I think you misunderstood what I was trying to say. What developers call post types is different from what users call post types, and your assertion that the two aren't really different isn't correct (at least based on the conversations about post types I've had with users and developers and the features they request around them).

Sorry, wasn't trying to say they were the same just making an argument that they may be similar enough that people could learn the difference. I think whatever terminology you use there will be user training involved and thus, weighing the potential confusion created by spawning a new term, I was arguing to maintain the term "post type."

@janeforshort: Just try teaching a new user about Pages and you'll see what I mean ("Go to the page, no, the Page, not the screen," etc).

Funny you should bring that up! Back in Feb 2009 I have a very successful(Footnote 1) "Launch your site Wordpress in 3 hours" event at my meetup group and we taught ~58 people how to use Wordpress in 3 hours. What's more I'm preparing a training course which I'll be delivering Jan 5-7 and I'll be explaining explain those things yet again. :)

So yes it can be a chore, but at least it's a chose with which I'm familiar. :) That said I think I've come up with some pretty good ways to explain it that most people I teach seem to understand right out of the gate.

BTW, we'll get to meet face-to-face sometime between Jan 8-10 while you are here in Atlanta for Wordcamp. :)

@janeforshort: The end result of this discussion isn't something I'm overly passionate about,

I guess you could label me relatively passionate about getting this one right (whatever "right" is. :)

@janeforshort: I just think it's important to think about how we use common words with multiple uses in describing functions, especially if it will make it harder to clarify them in the future.

Agreed.

@janeforshort: If I could get rid of the Pages label and call them static posts or something, I'd do it in a New York minute, but it's a little late in the game to suggest such a thing.

A "New York minute"; you sure about that one? (consider the origin of the phrase! ;) But seriously, explaining Pages and Posts isn't that hard once you find the things that resonate with people. It took me quite a while to find what works but finally here's how I explain it:

"Pages" are those static things that are always there like the "Products", "Services" and "About" pages on a website. "Posts" have a time/date component to them and are a lot like a news story. A "Post" by definition will have a date/time on which it's published and it "ages" from that day forward. Website owners continuously update "Pages" as their websites evolve but it's bad form to modify a "Post" unless to append an explicitly noted "Update" section or to explicitly link to newer related articles. After all, you wouldn't want to quote and link to an article on CNN.com and go back later to find that the story had changed, would you? The same should apply to your blog Posts. So that's the difference between Pages and Posts.

With that explanation I've literally never had someone tell me they continue to be confused. Try it maybe?


@janeforshort: This discussion is simply raising the issue so we can be sure we are using the least ambiguous and/or potentially confusing language possible. I could put up a poll on the dev blog if people really think it will help, but to be honest, I think custom post types would be so misunderstood by the common user without pages of explanation, and in contrast are already so accepted by the advanced developers, that it would be difficult to get a meaningful set of results.

Maybe, but what if the poll were worded like so?

We are considering adding more CMS-like functionality into Wordpress. By "CMS-like" we mean providing functionality site owners could use to build more advanced sites. Rather than have sites be just a collection of blog posts and static content pages instead we want to be able to have collections of things like "products", "real estate listings", "events", "recipes", "businesses", "cars", "software", "motherboards", "camera", "venues", and more. Problem is we are not sure what generic term we should call these things as compared to what we have already, i.e. "Posts" and "Pages" so that it will cause the least confusion among users.

So here are the terms we've thrown around, in alpha order ; we'd like you to vote for the term you think most clearly describes to you the kind of thing that could be used as a container for information about products, real estate listings, events, recipes, businesses, cars, software, motherboards, cameras, venues, etc. If you have ideas beyond the ones we've had, please let us know those too:

  • Content
  • Container
  • Content Items
  • Content Types
  • Custom Post Types
  • Entity Types
  • Generic Types
  • Items
  • Objects
  • Post Types
  • Records
  • Things
  • OTHER?

Note: If "Post Type" or "Custom Post Type" are not confusing to you we'd prefer to use them as those terms are currently already baked into the Wordpress program source code and changing them making actually cause confusion rather than help the situation.


Of course you could leave the note off if you don't want to bias the sample but I'd prefer it because not changing the term has the significant benefit of not creating two names for the same thing.

Anyway, that's my view. Unless you want to further discuss I'll go back to working on my post types plugin now. :)

-Mike Schinkel

Footnote 1: http://www.meetup.com/atlantawebmarketers/calendar/9711037/ (See the positive comments! :)

comment:80 in reply to: ↑ 79 janeforshort4 years ago

But seriously, explaining Pages and Posts isn't that hard once you find the things that resonate with people. It took me quite a while to find what works but finally here's how I explain it:

"Pages" are those static things that are always there like the "Products", "Services" and "About" pages on a website. "Posts" have a time/date component to them and are a lot like a news story. A "Post" by definition will have a date/time on which it's published and it "ages" from that day forward. Website owners continuously update "Pages" as their websites evolve but it's bad form to modify a "Post" unless to append an explicitly noted "Update" section or to explicitly link to newer related articles. After all, you wouldn't want to quote and link to an article on CNN.com and go back later to find that the story had changed, would you? The same should apply to your blog Posts. So that's the difference between Pages and Posts.

With that explanation I've literally never had someone tell me they continue to be confused. Try it maybe?

Wow, that sounded condescending, though I'm extending the benefit of the doubt and hoping you didn't mean it to come off that way. I didn't say it was hard to describe the difference between posts and pages. That's easy. What I was saying is that because we use the word Page to describe what is essentially a static post, and the word "page" is used in other web terminology (a web page, the admin page, etc), it frequently happens that users get confused when they use the word "page" to mean something other than a WP Page, or the person helping them does, or some combination thereof. It's the main reason I always use the word "screen" when referring to what most end-users call a "page" when giving someone instructions on how to do something in WP. If we have to do a ton of explaining to describe the concept, then that generally means it's not named as well as it could be.

comment:81 mikeschinkel4 years ago

@janeforshort: Wow, that sounded condescending,

Oh by no means, I was just sharing what worked for me. Was trying to be helpful, not condescending.

@janeforshort: What I was saying is that because we use the word Page to describe what is essentially a static post, and the word "page" is used in other web terminology (a web page, the admin page, etc), it frequently happens that users get confused when they use the word "page" to mean something other than a WP Page, or the person helping them does, or some combination thereof ... If we have to do a ton of explaining to describe the concept, then that generally means it's not named as well as it could be.

Ah, good point. I was not thinking of it from that perspective. Sorry again if it came across condescending, wasn't meaning to be. FWIW, I agree that good naming is super important.

So would be it fair to say, from your experience, that the term "Page" generates the biggest problems whereas "Post" is easier for most people to grasp?

comment:82 in reply to: ↑ 79 aaroncampbell4 years ago

Replying to mikeschinkel:

Of course you could leave the note off if you don't want to bias the sample but I'd prefer it because not changing the term has the significant benefit of not creating two names for the same thing.

I'm not saying we should do a poll, but if we do I'm definitely against having a note like this. It's clearly trying to influence people to Mike's point of view, which pretty much negates the purpose of a poll (unless you have notes like that from different people for every option, in which case it's more like an election than a poll...which would be messy to say the least).

comment:83 follow-up: mikeschinkel4 years ago

As I continue to work with the post type plugin I realize there's a need for a hook 'register_post_types' to be called from within create_initial_post_types() after the standard post types are registered.

do_action('register_post_types');

Adding this hook can allow those who needs to register a post type to do it at the right time instead of via 'init.' This will then allow a plug to assume within the 'init' hook that all post types that need to have been registered have been. IOW, this hook would solve the chicken or egg problem I'm recognizing.

comment:84 mikeschinkel4 years ago

@aaroncampbell - I'm not saying we should do a poll, but if we do I'm definitely against having a note like this. It's clearly trying to influence people to Mike's point of view, which pretty much negates the purpose of a poll.

Excellent point.

I wouldn't normally have proposed it as such except I think the real question is "Is the term 'Post Type' too confusing?" with a potential follow up being "If it's too confusing which of these should we use instead?" In hindsight, and after replying to you I would have proposed those two questions in that order instead of the one question with the note which admittedly now looks like a poor choice of wording to me too.

Said another way, I believe we might be getting worked up about something that won't really be a problem if we just leave it be.

comment:85 in reply to: ↑ 83 ; follow-up: scribu4 years ago

Replying to mikeschinkel:

As I continue to work with the post type plugin I realize there's a need for a hook 'register_post_types' to be called from within create_initial_post_types() after the standard post types are registered.

do_action('register_post_types');

Adding this hook can allow those who needs to register a post type to do it at the right time instead of via 'init.' This will then allow a plug to assume within the 'init' hook that all post types that need to have been registered have been. IOW, this hook would solve the chicken or egg problem I'm recognizing.

Wouldn't using hook priorities be enough?

Priority 0: core post types
Priority 10: additional post types
Priority 100: plugin that assumes all post types are registered

comment:86 sirzooro4 years ago

The same problem is for custom taxonomies. I suggest more general approach - add post_init action just after init (at the end of wp-settings.php).

comment:87 in reply to: ↑ 85 mikeschinkel4 years ago

Replying to scribu:

Wouldn't using hook priorities be enough?

Probably...honestly I had forgotten about the priority.

On the "con" side of just using priorities it will be simpler to just have a named hook; less to understand conceptually. OTOH, now that you bring it up I could go either way as long as how to process post types at init priority 100 is well documented somewhere.

comment:88 in reply to: ↑ 74 ryan4 years ago

Replying to scribu:

  • get_object_type_object() ?

Maybe we should call it get_object_type_properties() instead.

The only reason _object is appended is because get_post_type() was already taken. The name would probably just be get_object_type().

comment:89 follow-ups: ryan4 years ago

I'm going to take a cue from my sample plugin and use "thingy" everywhere. get_thingy_type(). Who's with me? ;-)

comment:90 in reply to: ↑ 89 filosofo4 years ago

Replying to ryan:

I'm going to take a cue from my sample plugin and use "thingy" everywhere. get_thingy_type(). Who's with me? ;-)

"type" is too confusing (why would you want the thingy to be typing?). Instead, it should be get_thingy_doohickey().

comment:91 follow-up: ryan4 years ago

Heh.

Somewhat more seriously, I actually like "thing" better than "object". A "thing" API would be refreshing. :-) My more cynical side, however, wants to call it as it is and use "contrivance".

comment:92 follow-ups: jeremyclarke4 years ago

I think the argument that it should be object because of the use of object_id in the term_relationships table is pretty solid. When I first saw that in the db I thought it was a good move, and that it was just a shame that the wp_posts table couldn't be switched to wp_objects, and the post_type field changed to object_type. While I'd hate for WP to become Drupal, I don't see any reason why the database would hurt by being abstracted in that way (beyond the obvious backwards-compatibility nightmare). Considering saved content items as 'objects' is very functional if our goal is to have it make sense that on a fundamental level 'posts', 'pages', 'links', and 'revisions' are all the same kind of information, just with a different 'type'.

That said, the use of 'object' is only important if we want to maintain the current, specific meaning of post, as a time-sensitive "story" with an author, categorization and a url based on the primary permalinks settings. This IMHO is a very important question and the vital one for assessing Mike's question about the status quo.

Using 'post_*' as the general catch-all term for stuff saved to the db has a LOT of benefits if we are willing to do it.

For one thing it makes a ton of sense semantically: On some level all the core content types and most potential 3rd party ones (tickets, players, stores) are things that get posted to the site and are thus posts. 'Post' defines the action by which the content is saved rather than the content itself, as well as aligning directly with _POST in http which happens to be how WP gets that shit done.

Another huge benefit, albeit one tinged with problems, is that using 'post_*' will mostly fit in with the current code. Unlike 'object_*' which makes sense but leaves the wp_posts table and various fields misnamed. 'post_*' is back-compatible with almost everything out there. For the most part this is accidental, based on the (understandable) shortsightedness of the past where the specific content type of 'post' was given undue prominence and other types were effectively shoehorned into the existing database. That doesn't mean it can't be a benefit. If we are willing to shift our paradigm slightly to have 'post' mean all content types then we will reap the rewards of our past laziness in that the new content typing system can be semantically meaningful and internally consistent, while also avoiding huge deprecation conversions.

The problem, of course, is the naming conflict created with the old 'posts' when 'post' is used for all content. What are these 'posts' in the new system?

A 'post' (in the old sense) is a post (new sense) with a post_type of 'post', which on some level equates with being a post with post_type DEFAULT. This is awkward but we can easily imagine the historical explanation: Until very recently WP was a blogging tool, and it definitely was only a blogging tool when the db was first designed. In that frame of mind there was only one content type 'BLOG POST', since the software was the 'blog' the content were 'posts', and they had 'blog post' properties like time-sensitivity, categories and an author.

As WP matured other content types were added, specifically 'pages', along with the post_type field to define them. IMHO the logical thing to do at this point would be to say that both types were posts, as implied by the DB structure and because they are both content that gets POSTed. At that point we could have specifically defined all existing 'posts' as post_type = blog. In effect that is what they are, posts logged in time, blogged. This would have left everything beautiful and today we wouldn't be debating at all. There are reasons that this would be a bad idea of course, not the least of which is that WP, even with just the 'blog'/'post' content type, can be used for just about anything if you think creatively and know how to hack a theme. "Blog" has social connotations that go beyond its technical definition and as such WP has done well to focus on posts rather than blog posts as their core content type.

Thinking of the generic content in WP as posts instead of blog articles has a way of helping developers and especially users get over their worries that WP is "just a blog" so they can start building their awesome website. Going back at this point and changing either the UI or the DB for posts to have post_type=blog is almost defintiely a terrible idea, but I think accepting the fact that what we call posts are actuall blog-content is vital to understanding how 'posts' is a useful generic description of all content in the wp_posts table. Consider that article is another useful description of the default content in WP. If we had been using post_type=article for them since pages were added then the 'posts' metaphor would be perfectly suited to adding more content types.

When post_type=post we can consider the content to be 'default' post type, though keeping the db the same is definitely a good idea. IMHO for 95% of projects the blog/article/default post_type and creative theming is all anyone needs, so treating it as default makes sense. A post type of post basically means 'a post with all the features', which is true except for a few page-specific features like custom templates. For people who want content with different settings or fields (i.e. different metaboxes in the editing UI) then adding new 'post types' is a meaningful and understandable concept

I really like the idea and simplicity of keeping 'post_type' as the name and committing to it conceptually going forward. If anything, I think that if we can really commit to 'post type' then changing the taxonomy api to use post_id instead of object_id might make sense as well, though its certainly not a prerequisite.

That said I'm still not sure that object wouldn't be a better name for general content to avoid confusion. Both ideas are fraught with peril, but something has to be chosen so we can work on making its implementation excellent.

comment:93 in reply to: ↑ 89 azaozz4 years ago

Replying to ryan:

I'm going to take a cue from my sample plugin and use "thingy" everywhere. get_thingy_type(). Who's with me? ;-)

+1. Hmm, so we will have "thingy", thingies", "thingomery"? :-)

Seriously though, don't forget we are talking about an API that is seen only by developers and each function has phpdoc description. It's nice to have descriptive names but it's imperative to have a well thought and well written API.

IMHO all of these would work well: "post" (current), "object" (a bit too generic), "content" (yes, content_type is also a HTTP header but that's completely different scope).

From a non-developer's point of view "content" seems to make the most sense. It is the content of the web site. From developer's point of view, it doesn't really matter that much as long as it works well and is documented.

comment:94 in reply to: ↑ 91 ; follow-up: Denis-de-Bernardy4 years ago

Replying to ryan:

Heh.

Somewhat more seriously, I actually like "thing" better than "object". A "thing" API would be refreshing. :-) My more cynical side, however, wants to call it as it is and use "contrivance".

I'd suggest calling it "mess" or "garbage", myself, rather than "thing", "thingy" or "object". ;-)

Seriously, though. It's like to be frank... whoever tries to store anything in that table but data that is very similar to a post is bound to get experience huge problems.

If that doesn't strike whoever, just give it a shot and try to store a product, with all of the necessary extra fields. Sounds simple? Great. Now create a dozen products, 10k users, and 15k orders spread on those various products. Try to make it scale. And good luck. (Tip: you're wasting your time.)

The point I'd like to make is, keep this as post_type, not object_type or inanity_type. That table is for posts, or things very similar to posts. The name should NOT suggest that it's for generic types of data.

comment:95 in reply to: ↑ 94 ; follow-up: filosofo4 years ago

Replying to Denis-de-Bernardy:

Seriously, though. It's like to be frank... whoever tries to store anything in that table but data that is very similar to a post is bound to get experience huge problems.

If that doesn't strike whoever, just give it a shot and try to store a product, with all of the necessary extra fields. Sounds simple? Great. Now create a dozen products, 10k users, and 15k orders spread on those various products. Try to make it scale. And good luck. (Tip: you're wasting your time.)

The point I'd like to make is, keep this as post_type, not object_type or inanity_type. That table is for posts, or things very similar to posts. The name should NOT suggest that it's for generic types of data.

Your example seems unnecessarily extreme. I've used custom post types already to make, for example, calendar events and restaurant listings without great difficulty. Events and restaurants are not posts.

However, I wonder (since you haven't elaborated) if the issues that make a "dozen products, 10k users, and 15k orders" problematic wouldn't also afflict a blog with multiple posts, 10k users, and 15k comments (or maybe instead 15k comment subscriptions or something). In other words, wouldn't the refactoring necessarily to make wp_posts work for generic objects also benefit its use for posts? (I'm curious about your answer even though it's obviously beyond the scope of this ticket).

comment:96 in reply to: ↑ 92 mikeschinkel4 years ago

Happy New Year all!

Replying to jeremyclarke:

@jeremyclarke your latest response was really excellent, filled with great insite. If I can paraphrase basically it sounds like you are saying that instead of questioning the name of the container (i.e. the "post type") we should instead question the name of one type of post, specifically the "post" post type. Brilliant.

This perspective may open up an whole new line of approach being that we discard the notion of "post" being sacred and instead think in generic terms of arbitrary post types and related capabilities. This could even demphasize "page" to address @janeforshort's previously stated concerns about that name.

Consider that Wordpress currently has four "core" post types: Posts, Pages, Attachments and Revisions. If we ignore "Revisions" for the moment as a special "meta" case then we find that each of these has an associated set of generally appropriate capabilities baked into the 2.9 core (ignoring the shared capabilities, and my list is nowhere near complete):

  • Posts
    • Excerpts
    • Tags & Categories
    • Send Trackbacks
  • Pages
    • Attributes (Parent Pages)
    • Templates
  • Attachment
    • Image Editing
    • Alternate Text
    • Caption
    • File URL

Now envision instead of having all that baked into Wordpress we evolve to being able to define a new post type and assign it any of post type capabilities, or even all of them if desired. Then the core post types would simply become four default post types provided by v3.0 but where any of them could have their capabilities added to or removed, or any post type could even be deleted by a site owner if desired.

Imagine how nice if would be for a online magazine website, for example, they could keep Pages and Attachments, remove Posts and add Articles, Interviews, and Reviews. A product oriented website may have just Pages, Posts and Attachments and add Products. A SAAS site may keep Pages and Attachments and add Services and add Support Requests.

To avoid confusing with "post" and "post type" we could even deprecate "post" and add "blog" as Jeremy suggested (though I think it might be better to call it "blogpost", but that's a nit.)

This approach could really make Wordpress a lot more open in terms of capabilities and provide a framework for plugin and theme developers to take Wordpress to the next level and I don't mean that to be hyperbole. What do you say?

-Mike Schinkel

P.S. The post types plugin I'm working on could be the basis for incorporating a UI to manage post types into the core, if it is so desired. I'm happy to release it as a plugin when I'm done or I'd even be happier to contribute the work to the core (assuming some code review for Wordpress coding standards from some core developers.)

comment:97 in reply to: ↑ 95 Denis-de-Bernardy4 years ago

Replying to filosofo:

However, I wonder (since you haven't elaborated) if the issues that make a "dozen products, 10k users, and 15k orders" problematic wouldn't also afflict a blog with multiple posts, 10k users, and 15k comments (or maybe instead 15k comment subscriptions or something). In other words, wouldn't the refactoring necessarily to make wp_posts work for generic objects also benefit its use for posts? (I'm curious about your answer even though it's obviously beyond the scope of this ticket).

Basically, if your goal is to merely list a few dozen restaurants in your community, then the posts table will work fine indeed.

If, however, the purpose is to allow users to search for a $15-25 restaurants in an arbitrary location, even moderate amounts of data will reveal that the postmeta table is not appropriate to store those details. (Among other things, you'll want the geodata in a column of its own right, complete with a GIST index.)

I think that we should make it very clear, if we change the terminology, that the posts table is only appropriate for other types of data if that table, rather than the postmeta table, is storing the key information.

comment:98 mikeschinkel4 years ago

@Denis-de-Bernardy: If, however, the purpose is to allow users to search for a $15-25 restaurants in an arbitrary location, even moderate amounts of data will reveal that the postmeta table is not appropriate to store those details. (Among other things, you'll want the geodata in a column of its own right, complete with a GIST index.)

I wasn't sure where you were going with that but now you've elaborated I agree completely. We discussed this issue on wp-hackers recently where we discussed storing custom fields in a custom table (like Pods and Drupal CCK) but how that Matt was completely against such an idea. I proposed there being the option for use custom fields for the 80 percentile case and a custom table for the 20 percentile case but the discussion died down after that.

Maybe such an approach could make its way into a canonical plugin?

comment:99 ryan4 years ago

There are good arguments here for post, content, and object. It seems like all of them can be explained in a cohesive manner, which is the main thing.

comment:100 scribu4 years ago

Yes, except post_type has the major advantage that it doesn't require any code changes. So I still think we should let it be.

comment:101 ryan4 years ago

(In [12597]) More custom post type support. Props scribu. see #9674

comment:102 ryan4 years ago

Okay, by popular demand/pressure, I went ahead and committed so we can start iterating. Standard alpha stage disclaimers apply. It's incomplete and buggy and could change completely several times before final release.

comment:103 ryan4 years ago

Most of the stuff mentioned here still needs attention:

http://core.trac.wordpress.org/ticket/9674#comment:35

Bring on the patches.

comment:104 follow-up: demetris4 years ago

  • Cc dkikizas@… added

Just a quick note about post types and gettexted strings:

Things like Edit %s will not work for all languages, and we will need to provide full phrases instead, that is: Edit Posts etc.

comment:105 in reply to: ↑ 104 greenshady4 years ago

Maybe the 'label' parameter should also allow for a singular and plural version. The UI should have things like "Add new Thingy" and "Edit Thingies".

comment:106 Utkarsh4 years ago

  • Cc admin@… added

comment:107 youngmicroserf4 years ago

Hi. I've just installed the latest update and registered a post type "thingy", as per comment #63, but all I'm seeing is a new top level entry for "thingy", the actual edit screen is identical to the standard post screen, there is no visible way to manipulate content types, custom fields, etc - I'm wondering if this is expected behaviour and actual management functionality (custom post type UI) is to be added by plugins, such as the one proposed by MikeSchinkel above, or if I am missing something.

comment:108 follow-up: scribu4 years ago

Post type management is currently plugin territory.

comment:109 prettyboymp4 years ago

If a new post_type doesn't support some of the default meta_boxes that a page does, it shouldn't have to go through removing them. Shouldn't the following metaboxes be added outside of edit-form-advanced.php specifically for post_type of 'post' and then the plugin should add these if the post_type the plugin is adding support it?

post_excerpt_meta_box
post_trackback_meta_box
post_custom_meta_box
post_comment_meta_box
post_slug_meta_box

comment:110 azaozz4 years ago

I think we need another (blessed) ticket for custom post types UI depending on what priorities are set at the upcoming dev chat on January 7. To properly address this we will need to abstract and merge edit-form-advanced.php, edit-page-form.php, post.php, page.php, post-new.php, page-new.php, etc.

comment:112 in reply to: ↑ 108 ; follow-up: youngmicroserf4 years ago

Replying to scribu:

Post type management is currently plugin territory.

Thanks Scribu - apart from Mike's private development above - are you aware which plugins are currently doing this? Could be used as a starting point? I suppose Mike is right to suggest (I think he's done that on the 3.0 ideas thread) that Post type/Custom Field UI should be developed in the core/close to the core.

comment:113 in reply to: ↑ 112 prettyboymp4 years ago

Replying to youngmicroserf:

A good starting point would be just replacing all the default add_meta_box calls in edit-form-advanced.php with a do_action('add_metaboxes', $post) and moving those into something like the following:

function add_core_post_metaboxes($post)
{
  add_meta_box('categorydiv', __('Categories'), 'post_categories_meta_box', 'post', 'side', 'core');
	if ( current_theme_supports( 'post-thumbnails', 'post' ) )
		add_meta_box('postimagediv', __('Post Thumbnail'), 'post_thumbnail_meta_box', 'post', 'side', 'low');
	add_meta_box('postexcerpt', __('Excerpt'), 'post_excerpt_meta_box', 'post', 'normal', 'core');
	add_meta_box('trackbacksdiv', __('Send Trackbacks'), 'post_trackback_meta_box', 'post', 'normal', 'core');
	add_meta_box('postcustom', __('Custom Fields'), 'post_custom_meta_box', 'post', 'normal', 'core');
	add_meta_box('commentstatusdiv', __('Discussion'), 'post_comment_status_meta_box', 'post', 'normal', 'core');
	
	if ( 'publish' == $post->post_status || 'private' == $post->post_status )
		add_meta_box('commentsdiv', __('Comments'), 'post_comment_meta_box', 'post', 'normal', 'core');
	
	if ( !( 'pending' == $post->post_status && !current_user_can( 'publish_posts' ) ) )
		add_meta_box('slugdiv', __('Post Slug'), 'post_slug_meta_box', 'post', 'normal', 'core');
	
	$authors = get_editable_user_ids( $current_user->id ); // TODO: ROLE SYSTEM
	if ( $post->post_author && !in_array($post->post_author, $authors) )
		$authors[] = $post->post_author;
	if ( $authors && count( $authors ) > 1 )
		add_meta_box('authordiv', __('Post Author'), 'post_author_meta_box', 'post', 'normal', 'core');
	
	if ( 0 < $post_ID && wp_get_post_revisions( $post_ID ) )
		add_meta_box('revisionsdiv', __('Post Revisions'), 'post_revisions_meta_box', 'post', 'normal', 'core');
} 
add_action('add_meta_boxes', 'register_core_post_metaboxes', 1, 1);

comment:114 ryan4 years ago

We could also do something like add_post_type_support( 'post_comment_meta_box' ) and post_type_supports( 'post_comment_meta_box' ).

comment:115 ryan4 years ago

I think every custom post type should have post_comment_meta_box, post_author_meta_box, and post_revisions_meta_box. post_tags_meta_box and post_categories_meta_box are already aware of whether the post type supports them so they can stay. Everything else would have to be registered with add_post_type_support(). Plugins also have the option of calling remove_meta_box() if they want to get rid of a box.

comment:116 follow-up: Utkarsh4 years ago

Just wanted to ask, is there any specific reason why the functions are named register_post_type() and register_taxonomy_for_object_type()? first it's post, then object?

comment:117 in reply to: ↑ 116 ryan4 years ago

Replying to Utkarsh:

Just wanted to ask, is there any specific reason why the functions are named register_post_type() and register_taxonomy_for_object_type()? first it's post, then object?

Legacy. The taxonomy API has used the term "object" for years.

ryan4 years ago

Post type capabilities (incomplete and untested)

ryan4 years ago

Post type capabilities (tested)

ryan4 years ago

Test plugin, drop in mu-plugins dir

comment:118 mattrude4 years ago

  • Cc m@… added

comment:119 dd324 years ago

attachment 9674.12.diff added Post type capabilities (tested)

I'd like to see register_post_type() being able to specifically register those items.

Ie. register_post_type('thingie', array( 'supports' => array('revisions', ....) );

comment:120 dd324 years ago

See also: #11703 - Allow for register_post_type() to enable/disable revisioning of new post_Types

comment:121 mikeschinkel4 years ago

@dd32 I'd like to see register_post_type() being able to specifically register those items

+1

@dd32 Allow for register_post_type() to enable/disable revisioning of new post_Types

+1

Also, in working on a UI that allows for users to add their own post types and editing metadata for all post types I'm recognizing some needs. We ideally need register_post_type() be something done on activation rather than init and registered post types persisted to a wp_option. The reason for this is to allow plugins to manage and save the information in the post_types via an admin UI and to have those saved post types loaded by WordPress. Yes you can mix and match the two but it creates chicken-and-egg type issues that would be much more easily handled by doing it once.

My plug is already saving to a 'post_types' wp_option but some other plugin could do it in an incompatible way and I really think this is foundational architecture that needs to be shared. If persisted by register_post_type() then plugins wouldn't need to persist themselves and thus wouldn't do it incompatibly.

We may also need an optional 3rd parameter of 'locked' or 'editable' for the core attribute of a post_type's name (i.e. 'page', 'post', 'attachment', 'revision') so that admin UIs for user added post types can know which post types can updated/deleted and which cannot.

comment:122 prettyboymp4 years ago

To get clarification, there have been suggestions for:

  1. add_post_type_support( 'post_comment_meta_box' ) and post_type_supports( 'post_comment_meta_box' )
  1. register_post_type('thingie', array( 'supports' => array('revisions', ....) );

If we do either/both of these, we will have to somehow map an identifier back to the actual metabox handling. Should it continue to do this in a "hardcoded" way like the post-thumbnails currently is, and if so, what should the keys be? IE, how 'post-thumbnails' is mapped to 'post_thumbnail_meta_box':

if ( current_theme_supports( 'post-thumbnails', $post_type ) )
	add_meta_box('postimagediv', __('Post Thumbnail'), 'post_thumbnail_meta_box', $post_type, 'side', 'low');

Also, should the core metaboxes really integrate differently than the metaboxes that plugins provide?

The problem I forsee is the lack of ability for end users to combine a plugin that adds a custom post_type with a plugin that adds a meta handler. For instance, a user has a website and finds a plugin that adds an events post_type to their site. They later decide to add a geo-coordinates plugin that allows them to a post, but they want this also to apply to their events post_type. How can we make this happen without requiring the end user to edit code?

comment:123 mikeschinkel4 years ago

@prettyboymp: Should it continue to do this in a "hardcoded" way like the post-thumbnails currently is ... Also, should the core metaboxes really integrate differently than the metaboxes that plugins provide?

Good catch. I'd really like to see handled it generically so that, if desired, a plugin could remove metabox functionality from the core post types given that's something that client would likely see.

@prettyboymp: For instance, a user has a website and finds a plugin that adds an events post_type to their site. They later decide to add a geo-coordinates plugin that allows them to a post, but they want this also to apply to their events post_type.

Great use case. That's a good example of why we need to have a standard way to persist post type data in WordPress and also to have WordPress core handle the persistence. By handling it with core functions WordPress can expose the needed functionality to allow plugins to integrate post type extensions that are compatible with one another.

comment:124 aaroncampbell4 years ago

@prettyboymp: That's a great use case, but why couldn't the events plugin just hook into init (at priority 100), grab all the content-types, and then loop through them and show the meta box in all of them. Right now my Google Maps plugin just ads to posts and pages, but once this is all in place, I'll be doing as I just suggested...possibly even adding an options page that offers checkboxes for all the content types and lets the user decide where to show the maps meta box.

comment:125 follow-up: mikeschinkel4 years ago

@aaroncampbell - Not sure if you are addressing persistence or not but how does a plugin provide those checkboxes to endusers with a standard way to persist said options, at least in a manner compatible with other plugins? IOW it seems that we need metadata for post types and a standard way to store that meta data. Inclusion of metaboxes actually seems like a special case of metadata which we should standardize?

comment:126 ryan4 years ago

I'm fine with having a supports arg for register_post_type(). I think add_post_type_support() is still useful so that capabilities can be added after the fact of registration and post_type_supports() is a very readable short hand that fits in with current_theme_supports() and current_user_can().

I foresee edit-pages.php and edit-form-adavanced.php being merge and the meta box additions being done in a more abstracted way. This patch is just another step along the way.

In an early version of the patch I used the metabox name instead of the more generic feature names. For example 'post_thumbnail_meta_box' rather than 'post-thumbnails'. I changed it with the idea that the more generic cap could be used when checking for other post-thumbnails related things. Turn them all of if the feature is not supported.

comment:127 ryan4 years ago

Persisting post type data and making it editable will just lead us into the mess that is the current roles implementation, especially since post types, like roles, have translated strings that all too often break serialize(). The WP model for custom taxonomies and other things is that plugins register on every page load and the data is stored only in memory and only for the duration of that page load. Once the plugin is deactivated the data disappears.

comment:128 in reply to: ↑ 125 aaroncampbell4 years ago

Replying to mikeschinkel:
@mikeschinkel: I'm addressing persistence by saying that I don't think it's needed. If all content types are registered at init, then by the time I get to my options page for my plugin, I can simply access them and use them. If I need a complete list at init, then I simply set the priority level to something high (like 100) so that I can be sure that all other init functions have already run. Even without persistence, I have access to all content types pretty early in the WordPress loading process. Like Ryan said, persistence could potentially cause all sorts of problems. So many plugin authors would forget to unregister the content type when the plugin is deactivated or uninstalled, then the user has a content type they can't actually use.

comment:129 follow-up: mikeschinkel4 years ago

@aaroncampbell I'm addressing persistence by saying that I don't think it's needed.

From your perspective of a metabox plugin they are not needed but from my perspective of a plugin that lets users add post types and annotate with the data they want persistence is a must. Yes my plugin can add it's own persistence but then my plugin is incompatible with someone else's plugin that also persists their enhancements.

@aaroncampbell Like Ryan said, persistence could potentially cause all sorts of problems.

Besides translated strings breaking serialize() (which can be resolved by using an non-serialized persistence structure) what other sorts of problems?

@aaroncampbell So many plugin authors would forget to unregister the content type when the plugin is deactivated or uninstalled, then the user has a content type they can't actually use.

And in the real world usage that causes problems why?

(I agree it's not ideal, but does it really matter?)

comment:130 in reply to: ↑ 129 Denis-de-Bernardy4 years ago

Replying to mikeschinkel:

And in the real world usage that causes problems why?
(I agree it's not ideal, but does it really matter?)

not really -- we could always strip the junk ex-post.

Besides translated strings breaking serialize() (which can be resolved by using an non-serialized persistence structure) what other sorts of problems?

that is actually pretty major in itself. when it occurs, it causes PHP warnings and loss of data.

comment:131 ryan4 years ago

Also, if a certain post type becomes popular and other plugins offer a meta box that they think works well with that post type, they can register for that post type.

We should add hooks to make a post type manager plugin possible, but such a UI is not going to happen in 3.0 and probably never. Even the best capability management UIs are impenetrable and unfriendly.

comment:132 follow-up: mikeschinkel4 years ago

@Denis-de-Bernardy that is actually pretty major in itself. when it occurs, it causes PHP warnings and loss of data.

Agreed it's major, which is why I proposed an alternate that wouldn't have that problem.

@ryan We should add hooks to make a post type manager plugin possible, but such a UI is not going to happen in 3.0 and probably never. Even the best capability management UIs are impenetrable and unfriendly.

Agreed, I'm currently okay with UI as plugin, but I'm asking to do our best to ensure interoperability between different such plugins. If it's not persisted in core, plugins will.

comment:133 in reply to: ↑ 132 ryan4 years ago

Replying to mikeschinkel:

@ryan We should add hooks to make a post type manager plugin possible, but such a UI is not going to happen in 3.0 and probably never. Even the best capability management UIs are impenetrable and unfriendly.

Agreed, I'm currently okay with UI as plugin, but I'm asking to do our best to ensure interoperability between different such plugins. If it's not persisted in core, plugins will.

Agreed.

comment:134 demetris4 years ago

  • Cc dkikizas@… removed

comment:135 prettyboymp4 years ago

Another issue with persistence is that it only relates to plugins that allow the user to dynamically create their own post_types. Plugins that add static post_types won't need it. This also means that all these plugins that allowed dynamic creation of post_types would be tied to a specific storage structure, not something I would want.

comment:136 ryan4 years ago

I'd like to commit the latest patch, and then maybe DD32 would like to patch in the supports arg for register and also the revisions capability. After that I would like to merge edit-page-form.php and edit-form-advanced.php. After that we can see about cleaning up how the default meta boxes are added. Sound good?

comment:137 mikeschinkel4 years ago

@prettyboymp — Another issue with persistence is that it only relates to plugins that allow the user to dynamically create their own post_types.

True...

@prettyboymp — Plugins that add static post_types won't need it.

And true but plugins that allow the user to dynamically create their own post_types will need to annotate information about those static post types that have been added by other plugins.

@prettyboymp — This also means that all these plugins that allowed dynamic creation of post_types would be tied to a specific storage structure, not something I would want.

I don't understand the specifics of your concern nor why a specific storage structure is a bad thing necessarily. Posts have a specific storage structure, is that bad? I just don't see what the issue is; educate me please.

comment:138 dd324 years ago

I'd like to commit the latest patch, and then maybe DD32 would like to patch in the supports arg for register and also the revisions capability

Go right ahead. If you want to commit what you've got, i'll work in any metabox items & update revisioning to handle it.

dd324 years ago

comment:139 follow-up: dd324 years ago

attachment 9674.13.diff added

  • Fixes the Tags menu not being current (&amp; vs &)
  • Adds $post_type to the various filters on that page

Some questions now lingers about the taxonomy pages

  • The "Posts" column shows the Count of the tag usage
    • It is a Global usage, If 1 post and 1 thinggi uses it, it'll show '2'
    • It links to the post listing for items using that taxonomy
  • Should the user be able to filter to only show terms that are linked to the current post_type?
    • Is anything special going to happen by $post_type being specified, If so, What?

My thought is:

  • There should be a column-per-post_type linked to the taxonomy
  • It should link to each post_type's page with the count of that post_type in the term
  • This would require a Taxonomy Meta storage instead of the current single 'count'..

comment:140 in reply to: ↑ 139 nacin4 years ago

Replying to dd32:

  • This would require a Taxonomy Meta storage instead of the current single 'count'..

Cross-referencing #10142 here. Is it time to hold that discussion?

comment:141 fwiffo4 years ago

I'm fairly new to WordPress development, so forgive me if this is a stupid question... Why not use SQL's count() function to count up the number of objects (thingies?) attached to a term when needed? Is it a performance issue? Keeping a "count" column requires bookkeeping, and it can become inconsistent, and it either limits you to a single idea of "count" or requires some complexity in allowing for different kinds of counts.

comment:142 dd324 years ago

Is it a performance issue?

Pretty much, Imagine running a COUNT() query over the relationship tables joined with the posts table up to <number of terms in taxonomy> just to display an admin page.

Keeping count is bookwork, but thats not too hard to do, and its updated every time a post is made, thats about it.

comment:143 ryan4 years ago

(In [12682]) Post type caps. see #9674

comment:144 ryan4 years ago

(In [12683]) Add post_type inputs. Fix submenu highlighting. Props dd32. see #9674

comment:145 ShaneF4 years ago

  • Cc ShaneF added

comment:146 sirzooro4 years ago

We should also start thinking about capabilities here. Now we have following capabilities available for posts:

  • read_private_posts
  • edit_posts
  • edit_others_posts
  • edit_published_posts
  • edit_private_posts
  • publish_posts
  • delete_posts
  • delete_others_posts
  • delete_published_posts
  • delete_private_posts

We also have few meta capabilities:

  • read_post
  • edit_post
  • delete_post

I think we should have something similar for custom post types. At least we should provide general capabilities for working with custom post types (e.g. edit_custom_posts, delete_custom_posts, and meta caps like read_custom_post). Caps specific for each post type (like edit_$post_type) can be left for plugins - we need to provide appropriate API only.

ryan4 years ago

Merge edit-page-form.php into edit-form-advanced.php

comment:147 ryan4 years ago

Patch merges the edit forms.

comment:148 ryan4 years ago

(In [12695]) Merge edit-page-form.php into edit-form-advanced.php. see #9674

comment:149 ryan4 years ago

(In [12702]) Merge page-new.php into post-new.php. Start abstracting column headers and prefs. see #9674

comment:150 follow-ups: ryan4 years ago

The goal is to merge edit-pages.php into edit.php and wp-admin/page.php into wp-admin/post.php. Translated strings need special care. Subbing translated words into translated string is not translator friendly. "Add New %s", for example. Post types will probably have to register "Add New Thingy", "Edit Thingy", and such. We can't do that for every string though. I think we'll have to keep the page strings for pages and then use the post string for everything else.

comment:151 ryan4 years ago

Done tinkering until tomorrow. If anyone else wants to have a go, jump in.

comment:152 in reply to: ↑ 150 Denis-de-Bernardy4 years ago

Replying to ryan:

The goal is to merge edit-pages.php into edit.php and wp-admin/page.php into wp-admin/post.php. Translated strings need special care. Subbing translated words into translated string is not translator friendly. "Add New %s", for example. Post types will probably have to register "Add New Thingy", "Edit Thingy", and such. We can't do that for every string though. I think we'll have to keep the page strings for pages and then use the post string for everything else.

for the other strings, how about using a more generic term, such as Entry, Node, Data...

comment:153 in reply to: ↑ 92 strider724 years ago

Replying to jeremyclarke:

A 'post' (in the old sense) is a post (new sense) with a post_type of 'post', which on some level equates with being a post with post_type DEFAULT.

To quote The Man in Black: "Truly you have a dizzying intellect." ;-) (I'm reminded also of "known knowns, known unknowns, and unknown unknowns....")

That idea as expounded by Jeremy says to me that it is important to use some completely different term, and "post" will be one type of it, "page" another, and so forth.

Having ready through all of the above, I think the best suggestion (surprisingly unnoted) is "record". It's comprehensible, pretty generic, and best of all, not yet generally used in the WordPress universe.

comment:154 sirzooro4 years ago

We also need new filter to add new entries to the $messages array.

comment:155 ryan4 years ago

(In [12706]) Make wp_edit_posts_query() more post_type aware. Use array calling style. see #9674

comment:156 ryan4 years ago

(In [12707]) Allow per_page settings for custom post type edit screens. see #9674

comment:157 ryan4 years ago

[12708] merges page.php into post.php.

comment:158 ryan4 years ago

The strings in post.php now use "item" instead of "post". These strings are shown only if there are capability problems, so they'll rarely be seen. A more generic term seems okay here, IMO.

comment:159 in reply to: ↑ 150 prettyboymp4 years ago

Replying to ryan:

The goal is to merge edit-pages.php into edit.php and wp-admin/page.php into wp-admin/post.php. Translated strings need special care. Subbing translated words into translated string is not translator friendly. "Add New %s", for example. Post types will probably have to register "Add New Thingy", "Edit Thingy", and such. We can't do that for every string though. I think we'll have to keep the page strings for pages and then use the post string for everything else.

Is there a reason we can use translatable strings like ('Edit %s') where %s is replaced by the post_type label. I'm know very little about languages, but are there any languages where the verb changes based on the characteristics of the noun being acted on?

As a side note, we should probably add label_plural to the register_post_type() args.

comment:160 Denis-de-Bernardy4 years ago

re the recent merging of pages, we need to make sure that the admin hooks still work (i.e. load-page.php, load-page-new.php, etc.), and that new post types get equivalent stuff. or then something that can be used to load type-specific code.

comment:161 demetris4 years ago

Replying to prettyboymp:

Is there a reason we can use translatable strings like __('Edit %s') where %s is replaced by the post_type label. I'm know very little about languages, but are there any languages where the verb changes based on the characteristics of the noun being acted on?

As a side note, we should probably add label_plural to the register_post_type() args.

Here is a small example from three languages I can read, explaining why we should not use strings like Edit %

English string: Delete Image

German string: Bild löschen

Greek string: Διαγραφή εικόνας

In the German phrase the noun is first, and then comes the verb. Also, German is a declinative language, and here the noun is in the accusative case (whose form for this noun is the same as the nominative).

Then, the Greek phrase uses two nouns, which is the standard for this type of UI phrase. The first noun means “deletion”, and the second “image”. The translation problem here is not because of the order of the two words, but because the second noun is in the genitive case. (Greek is a declinative language too.)

And these are just three languages. You can imagine what happens when we start taking more languages into account. :-D

comment:162 ryan4 years ago

prettyboymp, we need to fix "Edit %s" and others like it. Subbing string into strings will cause problems for some languages. We'll need to add several more labels to registration. Agreed on label_plural.

Denis-de-Bernardy, agreed.

comment:163 ryan4 years ago

So, we'll need things like edit_label, edit_label_plural, add_label, etc.

comment:164 markmcwilliams4 years ago

With the recent merge of page-new.php into post-new.php when looking at the menu in the backend, I'm not sure when trying to create a new page that the Add New should link to page-new.php - Do correct me if it is! - The same goes for when trying to edit a page, it still links to page.php which I thought had been merged with post.php =/

comment:165 scribu4 years ago

svn up to see the changes.

Related: #11879

comment:166 ryan4 years ago

(In [12710]) Always use post.php for form action. see #9674

ryan4 years ago

register_post_status() and friends

comment:167 ryan4 years ago

Patch introduces register_post_status() and uses it in edit.php. Note that I had to use get_post_stati() instead of get_post_statuses() sine the latter was already taken.

comment:168 ryan4 years ago

(In [12719]) register_post_type(). see #9674

ryan4 years ago

Merge edit-pages.php into edit.php, introduce $current_screen, and more

comment:169 ryan4 years ago

Big patch that does the following:

  • Merged edit-pages.php into edit.php. edit.php can now handle both hierarchical and flat post types.
  • Introduce $current_screen global object. This collects pagenow, typenow, and some other things into into struct that can be passed around more easily.
  • Changes all of the funcs that took a screen name to also accept a screen object
  • Lots of cleanup as a result of passing the screen object around since there is no longer need to juggle several globals.
  • wp_edit_posts_query() now handles all post types
  • Column header functions are fully type aware and adjust the columns shown based on the post type's capabilties
  • autosave generate nonces is type aware
  • inline_edit_row() is type aware but needs some more work
  • Contextual help for core admin pages moved out of template.php and into the respective files.
  • Moved a few global defines from admin-header.php to admin.php so they are available earlier. This is mainly for add_contextual_help() which must be run before admin-header.php is included.
  • Made some gettext strings more generic to accommodate any type.
  • Type awareness in more places

There are still things to fix with quick edit and saving screen options. There are some small back compat breaks. Some names for usermeta keys changed, meaning screen preferences can be lost for a few pages. Maybe not a big deal, but working in some back compat would be nice. Some filter names changed when made type aware. Some back compat to support the old names is needed.

comment:170 ryan4 years ago

(In [12728]) Merge edit-pages.php into edit.php. see #9674

comment:171 ryan4 years ago

(In [12731]) Move current_screen setup before plugin page handling so it is defined for all cases. see #9674

comment:172 dd324 years ago

see also adding 'support' to the register_post_type() args, and implemented directly for revisions over in #11703. Just mentioning it here for anyone watching this ticket who'd like to comment.

comment:173 dd324 years ago

(In [12751]) Introduce Revisioning for custom Post Types, Introduce 'supports' argument to register_post_type() to wrap add_post_type_support(), Whitespace additions to create_initial_post_types(). See #9674. Fixes #11703

comment:174 follow-up: sirzooro4 years ago

I think it will be good to mark if given post type supports comments or not - this information could be used by theme to display or not comments and comment form.

comment:175 in reply to: ↑ 174 ; follow-up: ryan4 years ago

Replying to sirzooro:

I think it will be good to mark if given post type supports comments or not - this information could be used by theme to display or not comments and comment form.

if ( post_type_supports($type, 'comment's) )

If themes start using this more often, we might want to add the_post_type_supports($capability).

comment:176 in reply to: ↑ 175 mikeschinkel4 years ago

Replying to ryan:

If themes start using this more often, we might want to add the_post_type_supports($capability).

+1

I'd love to see more themes recognize that not all pages have comments (i.e. and not display "Comments for this post are closed" when comments are turned off for a page.)

comment:177 sirzooro4 years ago

I think we can implement this in new theme for 3.0 (#9015) - this way we can promote this approach.

comment:178 waltervos4 years ago

Regarding the above diff: The key 'public' in $defaults in register_post_type was set to false while documentation said it defaults to true. I changed the value to true.

comment:179 ryan4 years ago

(In [12797]) Introduce set_current_screen(). Set current screen for inline edit ajax requests so post rows can be properly displayed. see #9674

comment:180 ryan4 years ago

(In [12812]) Fix taxonomy check so categories show in post quick edit. see #9674

comment:181 follow-ups: evolts4 years ago

What about a per post_type permalink structure? Is this already in the code? Should be used a plugin?
Thanks.

eV

comment:182 in reply to: ↑ 181 greenshady4 years ago

Replying to evolts:

What about a per post_type permalink structure? Is this already in the code? Should be used a plugin?
Thanks.

Going off this, how are rewrite rules going to be handled? I've just started diving into the rewrite API, which is has sparse documentation, and have come close to ripping my hair out a few times.

I love how this is handled with custom taxonomies via a rewrite argument in register_taxonomy().

I don't know if there are plans for adding to this or if we're just leaving it up to plugin authors. But, if it isn't easier to use, few users will ever take advantage of custom post types.

comment:183 in reply to: ↑ 181 prettyboymp4 years ago

Replying to evolts:

What about a per post_type permalink structure? Is this already in the code? Should be used a plugin?

I think to leave things a flexible as possible, setting the permalink structure and adding rewrite rules should probably stay in the domain of the plugin's responsibility.

I haven't had a chance to test this in HEAD yet, but an issue I have run into, is that sites without mod_rewrite can't get access custom post_types in the front end. The normal ?p=# sets the post_type query_var to 'post' by default. If the permalink structure is empty, the post_type variable should probably default to the 'any' handling. I'll test and patch if I can get to it before anyone else.

comment:184 in reply to: ↑ 181 mikeschinkel4 years ago

Replying to evolts:

What about a per post_type permalink structure? Is this already in the code? Should be used a plugin?

A big +1

comment:185 follow-up: mikeschinkel4 years ago

Oops, let me clarify. I think a URL structure for each post type absolutely needs to be baked into the core. It's too fundamental to allow multiple plugins to do it in multiple competing and incompatible ways. Since a URL is a *unique* identifier, allowing 2 or more plugins to define URLs for a post type (and hence break that uniqueness) makes no sense.

waltervos4 years ago

Replaces my previous post.diff. This diff makes default => public in register_post_status and register_post_type comply with the documentation by making it default to true.

comment:186 in reply to: ↑ 185 ; follow-up: prettyboymp4 years ago

Replying to mikeschinkel:

Oops, let me clarify. I think a URL structure for each post type absolutely needs to be baked into the core. It's too fundamental to allow multiple plugins to do it in multiple competing and incompatible ways. Since a URL is a *unique* identifier, allowing 2 or more plugins to define URLs for a post type (and hence break that uniqueness) makes no sense.

Multiple plugins shouldn't define the url structure for a single post type. A plugin should only create its own post_types and manage only the url structures for those post_types. I don't know of a reason a plugin should mess with post_types it didn't create.

Though I do agree that the process of creating the url structures for the custom post_types should probably be simplified.

prettyboymp4 years ago

allows installs without permastructure set to use ?p=post_id to display custom post_types

comment:187 in reply to: ↑ 186 mikeschinkel4 years ago

Replying to prettyboymp:

Multiple plugins shouldn't define the url structure for a single post type. A plugin should only create its own post_types and manage only the url structures for those post_types. I don't know of a reason a plugin should mess with post_types it didn't create.

It's foolish to require such a fundamental aspect to have to be duplicated by each plugin, and it doesn't keep the plugins from accidentally creating incompatible routes. If it were handled by core that duplication that every custom post type plugin would need to implement and those potential incompatibilities would be (effectively) eliminated.

Not having URL routing for custom post types in the core will result in a worse chaos in the admin vs. less. Please favor the users on this one. You wanting the plugin to define the URL routes is akin to letting ever can on the road control when the traffic light is green.

-Mike

comment:188 greenshady4 years ago

I agree with Mike on permalinks here. Plus, code reuse is a cornerstone of good programming practice. It just makes sense.

Plugin authors should be focusing on building plugin features, not coding something that could much more easily be done in core.

comment:189 ryan4 years ago

(In [12898]) Update phpdoc to note that the default for public is false. see #9674

comment:190 ryan4 years ago

The default for public has to be false for back compat reasons. Updated the phpdoc.

We should do the same thing with permalinks that we do with taxonomies. Patches welcome. :-)

comment:191 follow-up: ptahdunbar4 years ago

  • Cc ptahdunbar added

+1 with mike. Why wouldn't you want to setup the permalink when you register a new post type? Adding this into core allows you to query and display your custom content instantly without additional setup.

P.S. On another note, I've got a related ticket for updating single.php to handle custom post types #12105 :)

comment:192 in reply to: ↑ 191 ; follow-up: strider724 years ago

Replying to ptahdunbar:

+1 with mike. Why wouldn't you want to setup the permalink when you register a new post type? Adding this into core allows you to query and display your custom content instantly without additional setup.

There are two sides of this argument:

On the one hand -- keep it easy. On the other hand, don't tie plugin authors down to your own assumptions.

So my thought is, implement a default permalink structure, but if a plugin author wants it to be something else, that should be do-able (e.g. replace the default entirely with something custom, via a hook: 'custom_[type]_permalink' or somesuch.)

The danger though:
Replying to prettyboymp

Multiple plugins shouldn't define the url structure for a single post type. A plugin should only create its own post_types and manage only the url structures for those post_types. I don't know of a reason a plugin should mess with post_types it didn't create.

That's not the problem. Two plugins could create permalink structures that conflict with each other. They wouldn't have to be for the same post type necessarily.

comment:193 in reply to: ↑ 192 mikeschinkel4 years ago

Replying to strider72:

So my thought is, implement a default permalink structure, but if a plugin author wants it to be something else, that should be do-able (e.g. replace the default entirely with something custom, via a hook: 'custom_[type]_permalink' or somesuch.)

Definitely, a plugin should be able to override but as it seems you agree a default structure managed by core minimizes potential for conflict.

The danger though:
Replying to prettyboymp

Multiple plugins shouldn't define the url structure for a single post type. A plugin should only create its own post_types and manage only the url structures for those post_types. I don't know of a reason a plugin should mess with post_types it didn't create.

That's not the problem. Two plugins could create permalink structures that conflict with each other. They wouldn't have to be for the same post type necessarily.

Exactly.

comment:194 follow-up: technosailor4 years ago

This seems bizarre and buggy. Can anyone duplicate per this screencast? http://screencast.com/t/YWQyNTA0M

In summary, it appears when there is a custom content type that supports custom fields, that the custom fields are pre-populated (somehow!) with values from the previously published post of it's type. After viewing the screencast, that should make more sense.

Might just be me but not sure why... this is a basically clean version of WP bleeding.

prettyboymp4 years ago

allows post_type to be set as public query var by limiting it to post_types with 'publicly_queryable' value set to true

comment:195 prettyboymp4 years ago

Example uses of attachment:ticket:9674:attachment.9674.17.diff

register_post_type('foo', array('publicly_queryable' => true));
register_post_type('bar', array('publicly_queryable' => false));

Going to http://example.com/?post_type=foo should show the latest 'foo' type posts'
Going to http://example.com/?post_type=bar should show the normal homepage as 'bar' isn't a publicly queryable post_type.

comment:196 in reply to: ↑ 194 aaroncampbell4 years ago

Replying to technosailor:

This has happened to me with regular post meta before...if the post meta exists in the database with a post id of 0. The real question is: Did this happen because of a mistake you made, or is there a condition in the custom post code that can cause this to happen?

comment:197 technosailor4 years ago

aaroncampbell: that was it. Due to a custom import. My bad.

comment:198 technosailor4 years ago

Attached is a patch that fixes a problem with capability checking. When you register a new content type, you can set a new capability with the capabilities argument. Let's call it foo. The register_post_type() function checks against read_foo, edit_foo, delete_foo, so plugins should provide new caps for each of these three as needed for individual roles.

The problem comes because of the verbage of the longstanding *_posts and *_pages caps. While the capabilities provided for posts and pages are plural, we can't change the post_types themselves (post, page). As a workaround, it seems that it is assumed post types are pluralized and an s is appended to the end of capabilities in wp-admin/post-new.php.

The attached patch 9674_pluralcaps.diff makes this neutral allowing for foo or foos. This whole section of code is messier than I feel like it should be. There has to be a way to clean it all up and abstract things a bit more. Nonetheless, patch...

comment:199 ryan4 years ago

[12923] for the first round of permalink support.

comment:200 ryan4 years ago

[12927] abstracts capabilities a bit more and hopefully addresses the issues technosailor brought up.

prettyboymp4 years ago

modifies handling for single template to first check for %post_type%.php template

comment:201 greenshady4 years ago

modifies handling for single template to first check for %post_type%.php template

Related: #12105

ryan4 years ago

Allow registering a meta box callback for setting up meta boxes when creating the edit form for the post type.

technosailor4 years ago

Support default registration of post_tag and category taxonomies for custom content type

comment:202 ryan4 years ago

(In [12938]) Add taxonomies arg to register_post_type() for registering built-in taxonomies for the post type. Props technosailor. see #9674

prettyboymp4 years ago

Include $leavename variable in 'post_type_link' filter

comment:203 ryan4 years ago

(In [12960]) Update real parent file back compat for pages menus. see #9674

comment:204 ryan4 years ago

(In [12960]) Update real parent file back compat for pages menus. see #9674

comment:205 kyounger4 years ago

  • Cc kyounger added

comment:206 ryan4 years ago

(In [12971]) Pass to post_type_link filter. Props prettyboymp. see #9674

comment:207 ryan4 years ago

(In [12993]) Add a separate show_ui flag for post types. see #9674

comment:208 ryan4 years ago

(In [12994]) Add more visibility args to post status registration. see #9674

comment:209 ryan4 years ago

(In [12995]) Use canonical status list. see #9674

ptahdunbar4 years ago

register_post_type() should have a description arg which could be displayed in the UI or used with plugins.

comment:210 ryan4 years ago

(In [13044]) Add description field for post types. Props ptahdunbar. see #9674

comment:211 ryan4 years ago

(In [13045]) Fix screen layout options for custom post types. see #9674

comment:212 ryan4 years ago

(In [13046]) Use show_ui instead of _show. see #9674

comment:213 ryan4 years ago

(In [13049]) Retore p_status. see #9674

comment:214 ryan4 years ago

(In [13050]) Remove leading slash so that it doesn't get doubled when front is added. see #9674

comment:215 ryan4 years ago

(In [13051]) Pass the default post to default_content, default_title, and default_excerpt filters. Allows filtering by post_type and other attributes. see #9674

comment:216 ryan4 years ago

(In [13052]) Consult exclude_from_search when retrieving post_status = any. see #9674

comment:217 jfarthing844 years ago

  • Cc jeff@… added

comment:218 jfarthing844 years ago

Not sure if this is exactly the correct place to post this, but it is highly related. Unless I'm missing something, there should be a way to specify when registering a custom taxonomy whether it should be treated similar to a tag or a category within a custom post screen. Meaning, I may have a taxonomy that I want to be selectable via checkboxes like a category, as opposed to an auto-completing textbox like a tag.

comment:219 jfarthing844 years ago

Should have taken another minute to look. I see that if a taxonomy is hierarchical, it uses the category meta box. Interesting take on it, assuming that a taxonomy should be "selectable" just because it is hierarchical.

comment:220 dd324 years ago

Not sure if this is exactly the correct place to post this

Proably better as a seperate ticket.

All hierarchical taxonommies recieve a category-style box on the post_Type's that it applies to, This is a new feature in 3.0. I'll be adding a public switch to the taxonomy registration to hide/show the menu/metabox however.

comment:221 mikeschinkel4 years ago

While we are bringing up issues, one architectural issue in core WordPress is slugs must be unique in the wp_posts table. This already causes me trouble but I think will cause a lot more people trouble when many different post types are introduced.

I can easily see the need to have identical trailing path segments in different URL paths. This is probably another ticket but this ticket can drive demand for a resolution so I thought it would be good to discuss it here.

comment:222 scribu4 years ago

Related: #12214.

comment:223 ryan4 years ago

(In [13172]) Flag post statuses as public, private, protected, or internal. Add flags for showing the type in the admin all query and the admin status list. see #9674

comment:224 jfarthing844 years ago

I have a few suggestions pertaining to some things I have noticed while testing custom post types.

One important thing is that not all custom post types will require a category, yet the wp_insert_post (and numerous other "wrap" functions) force the default category to be selected. This should be avoided somehow.

Also, I believe that every link to something post related within the administration should append the post type. In particular, the media links and all of the javascript for autosave and inline editing and such. This way, we could possibly perform different ajax and media actions depending upon post type.

Another thing, when the admin menu is generated for content whose "show_ui" property is true, it all defaults to the same menu ID ("manage-posts"). First of all, ID's are supposed to be unique. Also, this removes the ability to use custom icons for those menus, as they automatically inherit the post icon.

I believe that's all, for now...

comment:225 jfarthing844 years ago

In addition to my first point, possibly we could add a method to the register_taxonomy function that can "require" it to be selected. Or perhaps this flag should be within the post type object regarding the taxonomy within the context of that post type.

comment:226 jfarthing844 years ago

I found another "issue". There should be a flag within register_taxonomy() to keep it from automatically adding meta boxes to related post pages, if so desired. It can be tedious to use remove_meta_box() for each custom taxonomy that you wish to display another way.

comment:227 follow-up: ryan4 years ago

[13184] Don't require a default category for post types other than 'post'.

comment:228 dd324 years ago

There should be a flag within register_taxonomy() to keep it from automatically adding meta boxes to related post pages

There'll be one added before 3.0 release i can assure you.. :) - I've been doing a lot of Taxonomy UI related stuff in #11838, I've been waiting to see where the posts flags ended up, they seem to be pretty solid now, i'll be implementing it firtually the same to allow for developer flexibility and not having to deal with 2 completely seperate and different-acting API's.

comment:229 jfarthing844 years ago

Another quick point relating to the new "Auto Draft" system that I hate already. If this is going to be used (which I hate because it can cause auto-increment loss), they should at least not be counted for the edit screen. It looks odd to see it say you have 10 posts but only display 2 (the other 8 auto drafts).

comment:230 ryan4 years ago

(In [13198]) Don't include internal post types in the total. see #9674

comment:231 ryan4 years ago

(In [13199]) Don't use array_fill_keys() as it is PHP5 only. see #9674

comment:232 ryan4 years ago

(In [13200]) Deny commenting on any post with a non-public status. see #9674

comment:233 voyagerfan57614 years ago

  • Cc WordPress@… added

jfarthing844 years ago

comment:234 jfarthing844 years ago

All administration areas that need to check whether or not they should handle a post type should check against the 'public' argument rather than the 'show_ui' argument. The 'show_ui' argument is only related to the context of WordPress creating a default UI for it.

However, if a plugin wishes to create it's own UI but use the built-in WP pages for submission, it get's rejected because 'show_ui' is false. I believe this is the purpose for the 'public' variable and the difference between the two.

I notice specifically two areas where this should be changed: 'wp-admin/edit-tags.php' and 'wp-admin/includes/template.php'.

I have attached a patch.

comment:235 dd324 years ago

(In [13215]) Use the public query param instead of show_ui to determine if the Post Type is displayable. Props jfarthing84. See #9674

comment:236 dd324 years ago

(In [13215]) Use the public query param instead of show_ui to determine if the Post Type is displayable. Props jfarthing84. See #9674

I only commited the taxonomy related occurence, I'm not 100% sure on the use of it in the screen options, So i've left that for someone else who understands why its used in that location in the way it is.

comment:237 jfarthing844 years ago

In the screen options, it just set's up the columns for the screen. This is a transparent change, and is only noticed when actually using a UI, whether created by WP or a plugin.

Here is an explanation. If a post UI is created by WP because of the 'show_ui' argument, this function automatically assigns that page to have two columns (as a post page should). However, if you set 'show_ui' to false but create your own UI, the UI will only be 1 column and you'll wonder where all of your "right" context meta boxes are, such as the most important one, "Submit".

There is a filter available, as I'm sure you see, but that is just one extra step that shouldn't have to be taken when it can be accomplished correctly by using the 'public' argument as explained. Because if I create my own UI, I will set 'show_ui' as false, but keep 'public' as true. Again, that should be the difference between the two.

comment:238 in reply to: ↑ 227 jfarthing844 years ago

Replying to ryan:

[13184] Don't require a default category for post types other than 'post'.

You forgot to get this out of wp_insert_attachment():

	// Make sure we set a valid category
	if ( !isset($post_category) || 0 == count($post_category) || !is_array($post_category)) {
		$post_category = array(get_option('default_category'));
	}

comment:239 jfarthing844 years ago

All developers, please view my other topic #12306 dealing with custom post types and attachments.

jfarthing844 years ago

Can we please get this or something similar commited?

comment:240 jfarthing844 years ago

Inline edit post always submits a post_type of 'post' even when editing a custom post type. This is due to the following in 'inline-edit-post.js':

t.type = $('table.widefat').hasClass('page') ? 'page' : 'post';

This method should be changed to just check the new javascript variable 'typenow', which should already be set with the correct post type.

jfarthing844 years ago

Actually, just change the variable to 'typenow' in the POST data.

comment:241 ryan4 years ago

(In [13292]) Handle custom post types in inline edit js. Props jfarthing84. see #9674

jfarthing844 years ago

Another instance where checking against 'show_ui' is being used and should be changed to check for public in admin-ajax.php for inline-save (which breaks inline saving for custom created UI's not using 'show_ui' argument

jfarthing844 years ago

Fix trash/untrash/delete links for custom post types.

comment:242 jfarthing844 years ago

Can we please get my last two fixes committed?

comment:243 jane4 years ago

@jfarthing84: There are several hundred tickets against the 3.0 milestone right now, in this last week before freeze. Leaving notes here asking someone to commit your code isn't the way to go about it. The patch itself acts as that request. If there's no traction on something you posted, chances are that it needs more testing, and/or the commit guys are just plain busy with other tickets. Custom post types is a blessed feature for 3.0, so everything on this ticket will definitely be reviewed before freeze. Adding a nag message to the ticket after only one day isn't super helpful. If you want more eyes on your patch, hop into the #wordpress-dev channel on irc.freenode.net and ask people to take a look.

comment:244 ryan4 years ago

I'll get to them. I'm jumping between several different features so sometimes it takes a day or two to clear the patches for one.

comment:245 ryan4 years ago

(In [13359]) Fix trash/untrash/delete links for custom post types. Props jfarthing84. see #9674

comment:246 ryan4 years ago

(In [13360]) Allow inline saves for non-public custom post types. Props jfarthing84. see #9674

comment:247 holizz4 years ago

  • Cc tom@… added

comment:248 follow-up: jfarthing844 years ago

@jane: Sorry, I am just working on a big project (with a deadline) that is being coded for 3.0 and those two previous tickets were a hindrance to it. In no way was I trying to belittle the scope of the 3.0 project. I will be a little less "naggy" from now on.

comment:249 in reply to: ↑ 248 nacin4 years ago

Replying to jfarthing84:

I am just working on a big project (with a deadline) that is being coded for 3.0 and those two previous tickets were a hindrance to it.

Dogfooding on a (client's) production site is rarely a good idea, though you can easily apply your own patches and resolve the conflicts later if you're going to do so, as you know what you're getting yourself into.

comment:250 jfarthing844 years ago

Yea, the client himself requested it, so it's all good. You guys pretty much keep the trunk always stable anyways. Plus, it's not live right now.

comment:251 technosailor4 years ago

We should make the generated UI hookable so plugin devs can add additional menus to the generated UI.

comment:252 follow-up: jfarthing844 years ago

All of the post screens are composed of meta boxes. Therefore, it is "hookable" via add_meta_box/remove_meta_box.

comment:253 in reply to: ↑ 252 nacin4 years ago

Replying to technosailor:

We should make the generated UI hookable so plugin devs can add additional menus to the generated UI.

Replying to jfarthing84:

All of the post screens are composed of meta boxes. Therefore, it is "hookable" via add_meta_box/remove_meta_box.

He's referring to subpages, not meta boxes.

comment:254 jfarthing844 years ago

Well, in that case, use add_submenu('edit.php?post_type=my_type', ...) or manipulate the global $submenu.

prettyboymp4 years ago

only show tags in inline-edit for post_types that support them

comment:255 follow-up: ryan4 years ago

Would be nice: Supporting the full post permalink structure beneath the post type (/thingy/2010/02/slug/, etc.). We'd probably need a set of rewrite rules per type, which could get excessive. Plugins should be able to choose between the full permalink structure support and the abbreviated one that we currently have (/thingy/slug/). Non-public post types probably wouldn't want it.

comment:256 in reply to: ↑ 255 prettyboymp4 years ago

Replying to ryan:

Would be nice: Supporting the full post permalink structure beneath the post type (/thingy/2010/02/slug/, etc.). We'd probably need a set of rewrite rules per type, which could get excessive. Plugins should be able to choose between the full permalink structure support and the abbreviated one that we currently have (/thingy/slug/).

As long as we can turn those off completely as well. I have a plugin that allows the user to create their own permastructure similar to that of normal posts and wouldn't want WP adding its own per post_type on top of that.

prettyboymp4 years ago

checked against wrong taxonomy, fixed check against post_tag

comment:257 ryan4 years ago

(In [13389]) only show tags in inline-edit for post_types that support them. Props prettyboymp. see #9674

prettyboymp4 years ago

adds support for custom taxonomies to inline-edit

comment:258 prettyboymp4 years ago

I need some help from someone with more css skills than I have to adjust some things with the patch I just submitted that add support for custom taxonomies to inline-editing, attachment:ticket:9674:attachment.inline-edit-custom-taxonomies.diff

One style issue is the width's of the inline-edit-col's. They're specifically set for post and page post_types, but that is dependent on whether the middle column (which holds hierarchical taxonomies) is there. Not sure if this should be a more fluid layout or if someone with more CSS experience knows of a better solution.

The other style issue is the way that the cat-checklist div acts when it has the class cat-hover added. For me, in FF, its causing the different hierarchical taxonomy boxes to overlap. Its still functional though.

comment:259 follow-up: dd324 years ago

{{{ $menu[$_wp_last_object_menu] = array(esc_attr($ptype_obj->label), $ptype_obj->edit_type_cap, "edit.php?post_type=$ptype", , 'menu-top', 'menu-posts', 'div');}}

All the custom post_types are being created with the 'menu-posts' ID. This is resulting in multiple elements with the same ID.

The Posts Icon is currently based off the ID, Thats all i can see that is tied to it upon a quick glance.

Any reasons not to change the icon to a class and apply 'menu-$ptype' as the ID?

comment:260 scribu4 years ago

Related: #12408

comment:261 JohnONolan4 years ago

  • Priority changed from normal to low
  • Severity changed from normal to minor
  • Type changed from task (blessed) to defect (bug)
  • Version changed from 2.9 to 3.0

Currently re-arranging of widgets and meta-boxes on the write/edit pages of custom post types do not save in position - and always revert back to default positions after a pageload.

comment:262 JohnONolan4 years ago

  • Priority changed from low to normal
  • Severity changed from minor to normal
  • Type changed from defect (bug) to task (blessed)
  • Version changed from 3.0 to 2.9

Many apologies - I did not mean to assign all those changes to the whole thread, just to my comment! Should be reverted now.

comment:264 in reply to: ↑ 259 ptahdunbar4 years ago

Replying to dd32:

{{{ $menu[$_wp_last_object_menu] = array(esc_attr($ptype_obj->label), $ptype_obj->edit_type_cap, "edit.php?post_type=$ptype", , 'menu-top', 'menu-posts', 'div');}}

All the custom post_types are being created with the 'menu-posts' ID. This is resulting in multiple elements with the same ID.

The Posts Icon is currently based off the ID, Thats all i can see that is tied to it upon a quick glance.

Any reasons not to change the icon to a class and apply 'menu-$ptype' as the ID?

Patch #12434

comment:265 silkjaer4 years ago

I have been working with implementing post types in a new project, everything is running smooth! So a big kudos!

One thing i seem to be missing is figuring out how to use post types in my themes. I can do a lot of custom queries, adapting the default queries to also include the new post types etc, but I was wondering whether it is possible to do a listing of a specific post type, ala. the ordinary index.php.

If i want to see all posts in a specific category, i can go to example.com/category-name, is there a way to do this for post-types too? E.g. defining a slug when registering a new post type.

comment:266 ryan4 years ago

(In [13535]) Custom taxonomy support for inline edit. Props prettyboymp. see #9674

comment:267 ryan4 years ago

We should have add_new_label, edit_label, etc. "New %s" is not the most translation friendly.

comment:268 scribu4 years ago

Related to screen options: #12439

comment:269 ryan4 years ago

(In [13537]) Die if invalid post type is passed. see #9674

comment:270 follow-up: ocean904 years ago

I use following:

register_taxonomy( 'production', 'movies',
		array(
                         'hierarchical' => false,
			             'label' => __('Production'),
			             'query_var' => 'production',
			             'rewrite' => array('slug' => 'production' )
		)

The problem: http://grab.by/2KYb

On edit-tags I can add the Production, but on post-new I must add a tag for Production. I hope the image explain it.

comment:271 in reply to: ↑ 270 ocean904 years ago

Replying to ocean90:

On edit-tags I can add the Production, but on post-new I must add a tag for Production. I hope the image explain it.

Fixed in [13538]. See #11838.

comment:272 follow-up: ceenz4 years ago

is current_user_can( 'edit_page', $post_ID ) now a duplication of
current_user_can( 'edit_post', $post_ID ) now with all post types being treated the same way?

comment:273 in reply to: ↑ 272 ; follow-up: ryan4 years ago

Replying to ceenz:

is current_user_can( 'edit_page', $post_ID ) now a duplication of
current_user_can( 'edit_post', $post_ID ) now with all post types being treated the same way?

No, each post type can have its own caps. edit_page is distinct from edit_post.

comment:274 in reply to: ↑ 273 ceenz4 years ago

Replying to ryan:

Replying to ceenz:

is current_user_can( 'edit_page', $post_ID ) now a duplication of
current_user_can( 'edit_post', $post_ID ) now with all post types being treated the same way?

No, each post type can have its own caps. edit_page is distinct from edit_post.

I bring this up to highlight the current limitation of Roles and Capabilities in WP.
In the above example while pages and posts appear distinct they are just different content types. current_user_can( 'edit_post', $post_ID ) is just looking at the $post_ID an whether or not the current user has the right to edit that individual content instance.

current_user_can( 'edit_posts' ) on the other hand is looking at whether or not the user has the privilege to edit content of the type 'post', as does 'edit_pages' etc.

I believe that the current designation of user capabilities need to be changed so that all available 'content types' can be assigned as different capabilities and roles.

I suggest that checking user capabilities such as 'edit_posts', and 'edit_pages' be replaced with a singular function call such current_user_can( 'edit_type', $content_type_ID ).

This can be repeated with other current user capabilities such as:
edit_published_pages
edit_published_posts

EG: change to current_user_can( 'edit_published_type', $content_type_ID )

delete_pages
delete_posts

EG: change to current_user_can( 'delete_type', $content_type_ID )

publish_pages
publish_posts

EG: change to current_user_can( 'publish_type', $content_type_ID )

These changes would also mean that when a custom content type is created / managed / deleted (etc) the user permissions for that type would also have to be set / managed / deleted (etc).

comment:275 follow-up: scribu4 years ago

ceenz, you should open a separate ticket for further discussion.

As you can see, this ticket page is _really_ crowded.

We should probably close this ticket by now anyway.

comment:276 in reply to: ↑ 275 ceenz4 years ago

Replying to scribu:

ceenz, you should open a separate ticket for further discussion.

As you can see, this ticket page is _really_ crowded.

We should probably close this ticket by now anyway.

See #12498

comment:277 mikeschinkel4 years ago

First chance in a while I've had to really look at this lately. The additions for custom post types in 3.0 are brilliant; they transform WordPress; kudos!

I have a few questions/concerns (some which may already have been addressed):

  • If a post type supports 'page-attributes' shouldn't it use a page template instead of a post template?
  • Shouldn't 'page-attributes' be more granular, i.e. 'parent-page', 'template', and 'menu-order?'
  • Is there a way when registering the post type to change the slugs for a custom post type, i.e. if a parent page and slug for a custom post type of "car" are "Car" and "car" then "/car/mustang" is inconsistent and a site owner might want it to be "/cars/mustang."
  • Shouldn't a post be able to define a page as it's parent?
  • A nit on the (page) Attributes metabox; shouldn't the descriptions be collapsable to allow users to recover vertical screen space?

There's also a bug I found: When a custom type supports 'page-attributes' WordPress doesn't seem respect the selected page template and instead loads single.php.

mikeschinkel4 years ago

Update to /wp-includes/post.php to add a filter called 'initial_post_types'

comment:278 mikeschinkel4 years ago

I'd like to propose that create_initial_post_types() in wp-includes/post.php have a filter called 'initial_post_types' (or something else) that will allow a hook to remove default post types and/or modify the attributes of post types before they are registered. I've included a patch to illustrate. The same could be done with the post statues but doing so is a bit more complicated so I didn't implement that in case the core devs hate the idea.

comment:279 follow-up: dd324 years ago

I'd like to propose that create_initial_post_types()

That should be posted in a new ticket if you feel strongly enough about it.

You can replace post_type's be adding it with new vars.

comment:280 in reply to: ↑ 279 mikeschinkel4 years ago

Replying to dd32:

I'd like to propose that create_initial_post_types()

That should be posted in a new ticket if you feel strongly enough about it.

Okay.

You can replace post_type's be adding it with new vars.

I don't understand.

comment:281 follow-up: dd324 years ago

You can replace post_type's be adding it with new vars.

I don't understand.

if you call register_post_type('post', array('new' => 'args')); it'll completely override WordPress's internal 'post' post_type.

comment:282 in reply to: ↑ 281 mikeschinkel4 years ago

Replying to dd32:

You can replace post_type's be adding it with new vars.

I don't understand.

if you call register_post_type('post', array('new' => 'args')); it'll completely override WordPress's internal 'post' post_type.

Thanks for explaining. So how do you remove a post type?

comment:284 in reply to: ↑ 31 sirzooro4 years ago

There is one important piece missing, as Denis-de-Bernardy pointed earlier:

Following up on the previous remark...

some kind of is_custom() function would be useful, and a means to bypass the WP query entirely in the workflow immediately after the query is parsed. else WP_Query may get loaded with junk.

init_query_flags() for instance, probably also needs some reference to is_custom = false. after parse_query is done, $wp_query filters itself through do_action_ref_array(), and if it ends up with is_custom set to true at that stage, the actual WP query gets skipped entirely -- WP should then make the assumption that it has been set up already.

I don't think we actually need anything in the template loader, since there is a hook in there already. But there definitely needs something over in the wp_query query class to go something like: please bail the WP query.

I would like to see function with following declaration, in order to be able to check if current page belongs to given post type and/or give list of custom posts to test against:
function is_custom( $post_type = '', $post_id = '' )

comment:285 ryan4 years ago

Closing this huge ticket. Open new tickets.

comment:286 ryan4 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:287 wlindley3 years ago

  • Cc wlindley added
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 2.9 to 3.1.3

As of version 3.1.3, the post.diff patch has not taken effect; although line 628 says:

 * public - Whether posts of this status should be shown in the front end
of the site. Defaults to true.

lines 661-662 do not agree:

	if ( null === $args->public  )
		$args->public = false;

Note that a default of false is assumed by the register_post_status() calls on lines 88 through 142 in post.php. Either the documentation, or the behavior plus those calls, needs to change.

comment:288 scribu3 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed
  • Version changed from 3.1.3 to 2.9

Please don't reopen old tickets that are marked as fixed in a previous milestone.

Open a new ticket instead.

comment:289 scribu3 years ago

But before you do that, please try the 3.2 RC and take a look at #17040.

Last edited 3 years ago by scribu (previous) (diff)
Note: See TracTickets for help on using tickets.