Changes between Initial Version and Version 1 of Ticket #21240, comment 24
- Timestamp:
- 09/07/12 21:36:55 (18 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #21240, comment 24
initial v1 1 1 I've looked at this a number of times but wasn't a diehard fan of the current approach. Couldn't figure out why exactly. Today in IRC I started to [https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2012-09-07&sort=asc#m452937 offer a review] of the patch. There are some smaller things pointed out there like column and taxonomy names conflicting, overly clever code, etc. 2 2 3 I don't think that tying this directly to register_post_type() is particularly useful. First, this kind of modification is just as likely to . Second, it'd probably make more sense for it to be controlled by register_taxonomy(), as that's what is being shown, and they are specifically being registered against a post type anyway. It also makes for really complicated code.3 I don't think that tying this directly to register_post_type() is particularly useful. First, this kind of modification is just as likely to be done by a plugin adding a taxonomy or otherwise, and not by the plugin registering the post type. Second, it'd probably make more sense for it to be controlled by register_taxonomy(), as that's what is being shown, and they are specifically being registered against a post type anyway. It also makes for really complicated code. 4 4 5 5 People are used to registering a custom column with one filter (which is very simple to do). Then, they are used to registering a callback against an action to handle output of the column's contents, row by row. Not much harder to do, but it's annoying when all you want is a taxonomy column. You have to replicate the 'tags' code from the list table. That's no fun, and that's really what (I think) this ticket is trying to get at.
