Make WordPress Core

Opened 5 years ago

Last modified 2 years ago

#14966 accepted feature request

QuickPress should be a function with alot of hooks

Reported by: jorbin Owned by: jorbin
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: General Keywords: needs-patch 3.2-early
Focuses: Cc:


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

Attachments (6)

quickpress.patch (20.5 KB) - added by jorbin 5 years ago.
First Pass
quickpress.2.patch (20.6 KB) - added by jorbin 5 years ago.
Pass 2
quickpress.part1.patch (11.5 KB) - added by jorbin 5 years ago.
Moves some functions from the admin to the universal api
14966.diff (13.3 KB) - added by nacin 5 years ago.
Suggested second pass.
14966.2.diff (20.5 KB) - added by jorbin 5 years ago.
15922.diff (14.2 KB) - added by jorbin 5 years ago.

Download all attachments as: .zip

Change History (28)

@jorbin5 years ago

First Pass

comment:1 @jorbin5 years ago

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.

comment:2 @nacin5 years ago

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.

comment:3 @jorbin5 years ago

  • Status changed from new to accepted

@jorbin5 years ago

Pass 2

@jorbin5 years ago

Moves some functions from the admin to the universal api

comment:4 @nacin5 years ago

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

comment:5 @nacin5 years ago

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

comment:6 @nacin5 years ago

  • Summary changed from Quickpress should be a function with alot of hooks to QuickPress should be a function with alot of hooks


comment:7 @nacin5 years ago

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

comment:8 @automattor5 years ago

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

@nacin5 years ago

Suggested second pass.

comment:9 @azaozz5 years ago

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.

comment:10 @jorbin5 years ago

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

@jorbin5 years ago

comment:11 @westi5 years ago

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

comment:12 @nacin5 years ago

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.


@jorbin5 years ago

comment:13 @jorbin5 years ago

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

comment:14 @jane5 years ago

  • Keywords has-patch needs-improvement added

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.

comment:15 @nacin5 years ago

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

comment:16 @nacin5 years ago

  • Keywords needs-patch 3.2-early added; has-patch needs-improvement removed
  • Milestone changed from 3.1 to Future Release

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.

comment:17 @nacin5 years ago

  • Type changed from task (blessed) to feature request

comment:18 @johnjamesjacoby5 years ago

  • Cc Johnjamesjacoby@… added

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

comment:19 @hakre5 years ago

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

comment:20 @mau3 years ago

  • Cc ngomau@… added

comment:21 @Mick P.3 years ago

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.

comment:22 @sillybean2 years ago

  • Cc steph@… added
Note: See TracTickets for help on using tickets.