QuickPress should be a function with alot of hooks

[jorbin]

As discussed in IRC, quickpress should be a function that is usable by:

1) Custom Post Types
2) Themes for front end posting ala p2

[jorbin]

First Pass

[jorbin]

First Pass posted. A number of functions had to be moved to wp-includes from wp-admin/includes for this to function properly. Thoughts appreciated.

[nacin]

Going over the patch with jorbin now. Looks good as a first pass. We're going to alter the hooks a bit and do some other cleanups, and I expect an initial commit shortly.

[jorbin]

Pass 2

[jorbin]

Moves some functions from the admin to the universal api

[nacin]

(In [15688]) Move some post and taxonomy functions from admin/includes to wp-includes in preparation for QuickPress template tag. Moves get_tags_to_edit, get_terms_to_edit, get_default_post_to_edit, media_buttons, _media_button, get_upload_iframe_src. Also introduce get_media_buttons as a wrapper for media_buttons. props jorbin, see #14966.

[nacin]

(In [15689]) Docs and breathing room for get_media_buttons() and friends. see #14966.

[nacin]

:-)

[nacin]

(In [15689]) Docs and breathing room for get_media_buttons() and friends. see #14966.

[automattor]

(In [15691]) wp_quickpress_form, first pass. props jorbin. see #14966.

[nacin]

Suggested second pass.

[azaozz]

Personally I think that moving more stuff to wp-includes is the wrong way to go. It will be loaded on every hit to the site despite that it will not be used for the great majority of hits when the user is not logged in.

Even now there are some functions that can only be used when the user is logged in. I would rather move all these to wp-admin/includes (or another file/location) and load them conditionally only when a logged in user accesses the front-end. We should be making the front-end lighter, not heavier.

[jorbin]

@nacin - I'm not sure that your pass makes it any more readable, in fact the opposite might be true. That being said, I think it's just going to require more documentation and your changes aren't bad.

@azaozz - That sounds reasonable and like a decent idea. I've built upon nacin's patch and have moved those functions to conditional includes of the appropriate wp-includes files.

[westi]

QuickPress includes should stay in the admin.
A second template tag should bring them in if it is going to be used.

[nacin]

Thinking about this more, we pulled in the stuff from the admin so we could generate auto-drafts. I don't like that more I think about it.

Let's kill media button handling and move that to a hook for the dashboard module in particular. If the form is passed a $post, then so be it, but that's up to the developer. Beyond that, we don't have much use for [15688] which I can revert. Though maybe there is a need for get_terms_to_edit() if indeed a $post is passed. (Should we support edits by default?)

My big questions now are how to implement field creation and what not. I think I maybe went a little too far with 14966.2.diff, but I do see a use case for hidden fields to be processed as an array -- doing it otherwise seems weird. Maybe submit buttons as well. I'd rather not see big chunks of HTML getting processed as arguments, because then it is much more difficult to pick and choose which you want, or to customize them, etc.

It makes sense to me that you'd want to say I want array( 'title', 'content' ) and taxonomies => array( 'post_tag', 'category' ), and it should build that for you into a form.

Also, tabindex. Media buttons right now force us to leave it in, but it's a PITA to keep with the sprintf() needing to occur, and really they shouldn't be forced on forms because most won't want it (and shouldn't use it). The tabindex being in there was actually what got me thinking about fields with attributes in arrays, because based on the raw HTML, there's no way to easily remove tabindex="%d" if you don't want it.

Thoughts?

[jorbin]

I've uploaded another pass. This cleans things up a bit, removing some parts of the form (that are specific for the dashboard quick press) and adding them back as hooks. It will most likely take at least one more pass to get this perfect (I still want to add categories to the default form).

[jane]

This needs to be finished off by November 1 to be included in 3.1 (freeze coming). Should probably post current state to id any outstanding issues now so there's time to amend as needed.

[nacin]

(In [16535]) Revert [15688], [15689], [15691]. Try again in 3.2. see #14966.

[nacin]

Ultimately, a group of contributors needs to run with something like this to truly make it properly flexible. This didn't see much traction beyond the fine work by jorbin.

Moving to 3.2-early. We should establish goals here. Quick hits for me:

• Easy way to manipulate fields without going too crazy.
• Easy taxonomy support. Non-hierarchical is a text field, and hierarchical is a single-select box.
• Ensure this can be leveraged in P2 and potentially Twenty Eleven.

[johnjamesjacoby]

I need to play with this to see about using it for BuddyPress and bbPress.

[hakre]

A scenario, this ticket here might be helpful for: #16488

[Mick P.]

Has QuickPress evolved since this was open?

Some simple settings would be a big help. Using the default category is pretty useless because that is where Spam is 99.9% likely to end up.

[jorbin]

No one else has run with this since my initial work 5+ years ago, so I'm going to close this as maybelater. With the work to Press This and wp_editor, I'm not sure this makes as much sense as it did back then.