Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#13038 closed enhancement (duplicate)

Add action hooks to QuickPress dashboard widget

Reported by: t31os_ Owned by: westi
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Administration Keywords: has-patch
Focuses: Cc:


Could we please have one or several action hooks available inside the QuickPress widget to facilitate adding in additional form elements, like a category dropdown.

This is a very simple alternative to trying to over-ride the callback, of which is hard-coded into post.php.

There are of course a few problems to be overcome by adding one or several hooks into the widget, and that would be in maintaining the tab-index of the available form fields. There's also the consideration of whether this should just be a core element and optional.

Personally i think the action hooks would be appropriate, so those that want, let's say for now a category dropdown, could hook onto the action, plonk in a category drop down named post_category[] and have an alternative category applied on post submission.

NOTE: Category would have to be passed as an array due to an is_array() expectation on the receiving end of the data (in wp_insert_post or wp_write_post, can't remember off the top of my head - the latter i believe)

I've been testing some hooks to see how this would work out, and the hooks are certainly trivial to add in, it's just a case of working out whether the tab-indexes should be maintained and accounted for or whether this is best written in as a core element.

I'm opening the ticket with every intention of submitting a patch for approval but i'd like to get a little feedback from you guys regarding implementation and whether you feel this should already be core, or available as an action hook.

Was a little unsure about how to tag this ticket, so feel free to update component, milestone, etc.. as appropriate.

Feedback will be most appreciated, so i am to get a better idea of what to aim for in regards to providing a patch(have played with various test samples already).

Attachments (1)

14123.diff (1.3 KB) - added by jorbin 10 years ago.
Add four actions

Download all attachments as: .zip

Change History (19)

#1 @t31os_
10 years ago

  • Cc wp-t31os@… added

#2 @jane
10 years ago

Patches welcome. We've been meaning to do this since 2.7.

#3 @t31os_
10 years ago

Add hooks to the widget, or write specific extra fields(like category) into the widget?

Assuming for the moment you're referring to hooks in the widget, i'll have to think about how to tackle the tab-indexes, assuming the hook is to provide tax index support for fields being added via action hook.

Right now my thinking is that i need to split the form elements into an array, perform the hook after building the array, then loop over the array elements(it could have extra field added via hook at this point) and output whatever is there. That way the tax indexes can be created as the array is iterated over, skipping over any invalid items(if someone had hooked on but not supplied the correct type of data).

Using an array would also mean, if the person hooking onto that array wants to move the form elements around, they can pretty much put them in any order they want..


Media Buttons 

..simply by re-sorting the array items.

I'm open to any ideas anyone has for how to approach this, the above is just what springs to mind in terms of what the hook could provide.

#4 @t31os_
10 years ago

No edit feature, please do note a few typos in the above reply, and the opening ticket.

When i say tax index, i of course mean tab index.

10 years ago

Add four actions

#5 @jorbin
10 years ago

  • Cc aaron@… added
  • Keywords has-patch added
  • Milestone changed from Unassigned to 3.0

In order to get something at least simple in for 3.0, I added a patch that adds four actions to the quickpress form:

quickpress_form_before - Fires before the form starts

quickpress_form_before_fields - Fires after the form is open, but before any fields

quickpress_form_after_fields - Fires after the default fields, but before the submit buttons

quickpress_form_after - Fires after the form is closed

#6 @t31os_
10 years ago

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).

#7 @nacin
10 years ago

I'm wondering if it would be easier to allow the callback to be replaced instead of trying to re-invent the wheel.

I'm fine with adding the after_fields hook for 3.0, and taking this back up again early 3.1 when we can think about this from a broader perspective of an API that supports taxonomies and such. Even then, some things added then need to be handled on POST... It's just a lot to consider.

The post type was hardcoded to fix a notice somewhere.

#8 @jane
10 years ago

At this point, we should only be fixing bugs and finishing menus. If a hook is ready to go, it's fine to add, but we should not otherwise be touching QuickPress until 3.1. Feature freeze was over a month ago.

#9 @westi
10 years ago

  • Cc westi added
  • Milestone changed from 3.0 to 3.1
  • Owner set to westi
  • Status changed from new to assigned

Moving to 3.1

I don't want us to rush something in here.

We would do much better to step back and examine how we want the QuickPress feature to evolve especially around custom post-types.

If people have ideas then patches / ideas are very welcome but for the moment we need to focus on getting 3.0 finished.

I would rather not add hooks now which we then will need to support for backwards compat even if we completely rework QuickPress

#10 @t31os_
10 years ago

That's perfectly fine with me, but i'd still like to be able to air discussion on extending functionality, as i said above, the hooks suggested would be appropriate, not perfect but ideal for now.

Nacin, the callback is hard-coded into post.php, and there's no global or option where dashboard widget data is stored to reference against in order to change the function callback from what i could see(i had hoped there was), which is why i was instead in favour of making the widget itself hookable. In some ways it makes sense to, because other default dashboard widgets already offer hooks.

I'll attach a patch in due course, simply for illustration of what i was getting at with the arrays. As things stand, the hooks suggested will inevitably break(in a sense) tab indexes if new fields have been hooked in with tab indexes. Fields may tab out of order to, i think regardless of where the hooks are because the existing fields have hard coded tab indexes(so you're stuck adding your own after the existing top index(6 is it?)).

#11 @jorbin
10 years ago

In my opinion missing hooks are bugs, but I agree that if we are going to have one of the goals of 3.1 be to revise and improve the entire quickpress widget, we should wait until then to add hooks.

I think we should look to the comment_form function as inspiration since it has the fields filterable. Perhaps there is even areas to refractor and create some common form building functions.

#12 @jane
10 years ago

@t31os_: If you want to raise suggestions about future functionality, it would be better to do it at http://wordpress.org/extend/ideas; that way more people can weigh in on the possibilities. It's best if by the time it comes to trac the debate is more about implementation than what should be done at all.

#13 @t31os_
10 years ago

For reference:




Forum Threads



It wasn't my attention to draw out all discussion here, but i do find little tends to happen on the ideas section, it's under utilised. I've had quite a bit of feedback here in the space of 24 hours (yes sure, i appreciate this isn't necessarily the place for such discussion, apologies, just pointing out how quickly feedback has been made here in comparison).

I will however follow your advice and promote the idea ticket, perhaps with enough encouragement i can get the users that like the idea to help vote up the idea ticket so it gains so more traction.

#14 @t31os_
10 years ago

Rather then clog up this ticket with further typos and my blubbering i thought i'd take to writing a blog about my proof of concept for extending the functionality of the quickpress widget.


I could attach a patch/diff here, but i'm hesitant following Jane's last comment/suggestion, so i'll leave the above blog link simply as a reference for PoC of my array filtering idea for better control over the QuickPress widget.

It's my second run on the code(wiped my first run by using the built in WP update by mistake - when i should of been using SVN update so the changed files get excluded), but hopefully it should be sufficient in showing the basic idea behind what i was suggesting before.

#15 @nacin
10 years ago

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

(In [15370]) Fix typo in user-new. props Caspie, fixes #13038 for 3.0.

#16 @nacin
10 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Meant for #14038.

#17 @jorbin
10 years ago

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

Completely redoing QuickPress in #14966 has taken precedence. Closing as a duplicate.

#18 @nacin
10 years ago

  • Milestone Awaiting Triage deleted
Note: See TracTickets for help on using tickets.