WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 7 days ago

#14640 closed enhancement (wontfix)

Feature Requst: Add Action Hook "post_submitbox_end"

Reported by: ancawonka Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0.1
Component: Editor Keywords: has-patch
Focuses: Cc:

Description

I'd like to add a button UNDER the Publish button on an edit post page. There is an action for adding a button (or other elements) BEFORE the Publish button (post_submitbox_start), but I'd like one at the end. I know that I can address this w/ CSS if necessary, but it would be nice to be able to position my button in the HTML as well.

Attachments (1)

post_submitbox_end.patch (867 bytes) - added by mvd7793 6 years ago.
Adds a new action hook

Download all attachments as: .zip

Change History (9)

#1 @dd32
8 years ago

  • Keywords needs-patch added; publish action post edit page removed
  • Milestone changed from Awaiting Review to Future Release

@mvd7793
6 years ago

Adds a new action hook

#2 @mvd7793
6 years ago

  • Keywords has-patch added; needs-patch removed

#3 @mvd7793
6 years ago

  • Cc mvd7793 added

#4 @ericlewis
5 years ago

The use case makes sense.

However, if you want fine-tuned control over the Publish meta box, you can remove the entire post_submit_meta_box via remove_meta_box and add your own, fully customized version. So in that respect, you already have the ability to accomplish what you want without adding another action.

In another light: If we add this action, why would we say no to someone asking for an action before the #publishing-action div? An action right after the delete link? There's a hook for post_submitbox_misc_actions, so why don't we add a pre_submitbox_misc_actions? Should we imagine the entire admin interface as one huge template that a developer should have the opportunity to interact with at any point in the templating process?

#5 follow-up: @drozdz
4 years ago

@ericlewis:
In another light: if we say no to this action, why do we add any action at all? You always can unregister something and do it with your own custom code...

Submitbox is a complex meta box, so I really don't see a reason to implement it all by myself (and dealing with compatibility risks) just to add my custom button in there. Especially if there is already post_submitbox_start hook - so, IMHO, post_submitbox_end would be just a sign of consistency.

#6 in reply to: ↑ 5 @DrewAPicture
4 years ago

Replying to drozdz:

@ericlewis:
In another light: if we say no to this action, why do we add any action at all? You always can unregister something and do it with your own custom code...

Submitbox is a complex meta box, so I really don't see a reason to implement it all by myself (and dealing with compatibility risks) just to add my custom button in there. Especially if there is already post_submitbox_start hook - so, IMHO, post_submitbox_end would be just a sign of consistency.

I think the main issue at hand is that there are broad plans to re-frame this workflow in the future and every hook we add means yet one more thing we have to support for backward compatibility. Every time a hook is added anywhere in core, we have to weigh not what it might be used for now, but how it might be used in the future and how that will affect our ability to support that usage.

Adding a hook is easy, supporting it from now until the end of time is another thing entirely :-)

#7 @ancawonka
4 years ago

Hello time warp! I made this initial feature request a loooong time ago, and have learned a lot about WordPress since then.

I ended up implementing my new button as a separate metabox, which worked okay for the scenario, and I've since then done projects where I replaced the entire metabox. That was definitely a pain, and a couple of sites still have ugly stuff where WordPress upgrades changed the submit box and I had to quickly apply those changes.

I think we should be putting hooks in places where there are sets of buttons (or action links), and use priority to determine if new actions go before or after that set. I know that adding hooks adds maintenance overhead, so it's important to be judicious.

#8 @desrosj
7 days ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Hi @ancawonka!

My apologies that this ticket fell dormant for so long. Since this ticket was last updated, a lot has changed! The new block editor has been shipped in WordPress Core. With this comes a ground up redesign of how content is published.

Moving forward, only bug fix changes will be made to the Classic Editor interface. Because this is an enhancement request, I am going to close this out. This is not a vote against this idea, it just needs to be explored within the context of the block editor and will most likely require a pull request against the Gutenberg GitHub repository.

Note: See TracTickets for help on using tickets.