[wp-trac] [WordPress Trac] #13038: Add action hooks to QuickPress dashboard widget

WordPress Trac wp-trac at lists.automattic.com
Sun Apr 18 17:54:01 UTC 2010


#13038: Add action hooks to QuickPress dashboard widget
----------------------------+-----------------------------------------------
 Reporter:  t31os_          |       Owner:           
     Type:  enhancement     |      Status:  new      
 Priority:  normal          |   Milestone:  3.0      
Component:  Administration  |     Version:  3.0      
 Severity:  normal          |    Keywords:  has-patch
----------------------------+-----------------------------------------------

Comment(by t31os_):

 I did have something broader in mind, to accomodate removing and adding
 fields, whilst maintaining tab indexes to, but what you've attached looks
 fine for a quick addition into 3.0 (although maybe trim the names a
 little? can't help but feel they're a bit long).

 Personally i'd see all elements, save title and content, be hookable. I
 have some code for proof of concept, but i'll hold off on that in favour
 of getting these extra hooks(or similar) into core.

 I'll attach a patch later simply to illustrate the concept of using arrays
 for indexing and filtering form fields(i have a working sample already -
 supports tab indexes, and re-ordering the existing and/or newly added
 fields via filter).

 One filter, supports disabling existing and adding new, form fields.
 Increases the amount of code(i'm sure my code could be improved, always
 room for improvement), however managing a few arrays as far as i know
 isn't the most intensive of operations, and when you're dealing with
 around 1-10 items, why would it be..

 '''NOTE:''' I noticed a patch(didn't bookmark ticket for reference)
 recently hard-coded the post_type into the form. I don't see the need to
 hardcode in "post", get_default_post_to_edit() already sets this to
 post($post->post_type), so you can reference the available object for the
 post_type. I'm not sure why this was hard-coded anyway, shouldn't
 QuickPress be flexible and support posts, pages, books or whatever custom
 post types a user has registered, if he/she so desires? Why force
 QuickPress to be only posts, and it's associated taxonomies, it need not
 do.. (it could be optional).

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/13038#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list