Make WordPress Core

Opened 15 years ago

Closed 2 years ago

#12940 closed enhancement (wontfix)

Add filter for contents of Quick Edit panel

Reported by: caesarsgrunt's profile caesarsgrunt Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Quick/Bulk Edit Keywords: has-patch
Focuses: Cc:

Description

Quick Edit / Reply for comments has a filter called wp_comment_reply which allows plugins to replace its contents.

However, there is no such filter for Quick Edit for posts.
With the new custom post type support, it can be very important for plugins to be able to replace the contents of the Quick Edit panel.
I would therefore like to create a similar filter for Quick Edit for posts.

Does anyone have any comments or suggestions?
And will it get into 3.0, or is it too late even though it's just a very minor change? I personally think it is very important that it gets into 3.0, since the utility of custom post types is severely limited in some cases by the lack of it.

Attachments (1)

12940.1.diff (1.0 KB) - added by caesarsgrunt 15 years ago.
Method 1

Download all attachments as: .zip

Change History (19)

#1 @caesarsgrunt
15 years ago

One point that needs consideration is whether to pass the existing contents of Quick Edit to the filter or not.
The existing filter for Comment Quick Edit doesn't pass the existing contents, but I'm not sure why not...

@caesarsgrunt
15 years ago

Method 1

#2 @caesarsgrunt
15 years ago

This patch uses the exact same method as the current filter for Comments Quick Edit does. I don't like it at all, but it's the same as the existing filter.

Next I'll do a patch which I like better - keeps the standard structure but allows you to replace the contents.

#3 @nacin
15 years ago

  • Milestone changed from 3.0 to Future Release

I'm not sure if we want to introduce this so late in the development cycle without making sure we're doing this the right way. Doing a full replacement of the quick edit panel like this seems to be one of those hooks we might have buyer's remorse with later on if we ever make quick edit changes. It makes me hesitate, at the very least.

Moving to future for now, pending the second patch in particular.

#4 @mufasa
15 years ago

  • Cc mufasa added
  • Milestone changed from Future Release to 3.1

Hey Guys. I agree that this is a very important feature and I am therefore going to be cheeky and raise it to WordPress 3.1, I am doing so on the basis that this is of utmost importance to serious Plugin developers wanting to use Custom Post types.

I understand the hesitation and logic for moving it to future, but after talking to Ryan Boren about this today I dont think its mission impossible. I am putting my hand up to watch this topic and put some resource into it - providing people like @nacin can guide us in the right direction. Its true we could live without it and create a nasty hack to achieve the same thing but that would be such a waste of time!

-Dan Milward
p.s. nice meeting you over the weekend Andrew!! I hope you can see where i'm coming from :)

#5 @nacin
14 years ago

  • Milestone changed from Awaiting Triage to Future Release

Probably doable thanks to #14579. Moving to future.

p.s. nice meeting you over the weekend Andrew!!

Dan, nice meeting you -- six months ago! :-)

#6 @stephenh1988
13 years ago

  • Cc stephen@… added

#7 @ardathksheyna
12 years ago

  • Cc ardathksheyna added

#8 @chriscct7
9 years ago

  • Keywords has-patch needs-refresh added

#9 @Mte90
9 years ago

  • Keywords close added; needs-refresh removed

As I can see on https://github.com/WordPress/WordPress/blob/9b7a7754133c50b82bd9d976fb5b24094f658aab/wp-admin/includes/template.php#L371 now exist a filter to edit the content with an hook.

The only difference of this patch is the different name of the filter.

#10 follow-up: @hellofromTonya
2 years ago

  • Keywords reporter-feedback added; close removed
  • Milestone set to 6.2

Following up on this ticket request.

My initial thoughts are:

  • Extenders can replace the comments inline Quick Edit and Bulk Edit UIs by using the 'wp_comment_reply' filter added in 2.7.0.
  • On the surface, the request to also allow replacing these UIs for posts seems reasonable and consistent.

That said, I am concerned that there's been no traction in over 12 years, especially from extenders pushing to move this forward. It's possible though this ticket fell through the cracks.

Rather than adding a filter that might not be used, I propose reassessing the need for the request:

  • Is there still a compelling use case for adding the proposed filter?
  • What are the concerns?

Moving this in 6.2 milestone to answer the above questions.

That said, if there's not compelling use case for it today or there's no follow-up or traction, then I propose closing this ticket rather than keeping it open indefinitely.

Also, removed the close keyword as the reasoning for adding it was the 'wp_comment_reply' filter which is for the comments UIs and not posts UIs.

#11 @Mte90
2 years ago

My doubts reading today that ticket is that the filter name is not so content aware.
I mean can make sense for Reply to comments panel but for quick edit no as the filter name is unclear.

Maybe adding a specular one just for the quick panel with the same behavior can avoid troubles?

This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.


2 years ago

#13 in reply to: ↑ 10 @azaozz
2 years ago

  • Keywords close added

Replying to hellofromTonya:

I am concerned that there's been no traction in over 12 years, especially from extenders pushing to move this forward.

Same here. 12 years without traction is a firm "wontfix" imho :)

The reason is probably that both Quick Edit and Bulk Edit are JS based. Having PHP filters for them is not that useful and may not work well (replacing the HTML as in the patch may even trigger JS errors). Anything that plugins may want to accomplish there can be done with JS and CSS.

Last edited 2 years ago by azaozz (previous) (diff)

#14 follow-up: @Mte90
2 years ago

I have some doubts about to achieve the same results in pure JS, I mean add a new field in that panel.
It should be by PHP the part to add it there and the rest by JS for interactions etc.

Maybe the best solution to avoid conflicts and simplify this integration is just a filter that let you append only new html in that panel. In this way we keep a compatibility with the other comment filter but without changing the content of the panel just adding new stuff.

#15 in reply to: ↑ 14 @azaozz
2 years ago

Replying to Mte90:

I have some doubts about...
It should be by PHP

You mean this won't work?

jQuery( '.inline-edit-col-right .inline-edit-col' ).append( jQuery( '<input type="text" value="Here we go!">' ) );

It is a lot better and cleaner to use JS for this type of things than to try to regex through the HTML in PHP :)

Last edited 2 years ago by azaozz (previous) (diff)

#16 @Mte90
2 years ago

It is not just appending a HTML field but also the values, as example for a select that contains data gathered by a SQL query.
This means a lot of hackish inside the WordPress backend as example.

This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.


2 years ago

#18 @desrosj
2 years ago

  • Keywords reporter-feedback close removed
  • Milestone 6.2 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I agree that a wontfix is fair here. Discussion can always continue on closed tickets, and if there's new justification in the future it can be reopened.

Note: See TracTickets for help on using tickets.