[wp-trac] [WordPress Trac] #23148: Add hook in wp_ajax_save_attachment for additional attachment fields

[WordPress Trac]

#23148: Add hook in wp_ajax_save_attachment for additional attachment fields
-----------------------------------+-----------------------
 Reporter:  griffinjt              |       Owner:  audrasjb
     Type:  enhancement            |      Status:  reopened
 Priority:  normal                 |   Milestone:  6.2
Component:  Media                  |     Version:  3.5
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:
-----------------------------------+-----------------------

Comment (by azaozz):

 Replying to [comment:39 sc0ttkclark]:
 > @azaozz Without this action, we have no way to know that an attachment
 was added through the `wp_ajax_save_attachment()` call except to sniff
 what we can from request vars.

 That's not entirely true. There's the `DOING_AJAX` and even
 `wp_doing_ajax()`. Also all WP AJAX calls are done from hooks, see
 https://core.trac.wordpress.org/browser/tags/6.1/src/wp-admin/admin-
 ajax.php#L104 and https://core.trac.wordpress.org/browser/tags/6.1/src/wp-
 admin/admin-ajax.php#L164.

 It seems it is quite easy to determine when `wp_ajax_save_attachment()`
 was used without having an action. My favorite would be: `if (
 doing_action( `wp_ajax_save-attachment` ) ) ...

 > I continue to believe this action would offer an official way to hook
 into that flow.

 Yes, it will. The question is: who needs that action?

 > I know you know that no traction on Trac tickets does not always
 correlate to the usefulness of the ticket.

 Correct. On the other hand "no traction for 10 years" usually means that
 there are other ways to achieve the same result, or that the result is not
 needed any more.

 > In this case, I believe that is because this is in an area that's less
 often dealt with: Attachment fields. The cool story here is that there was
 a hook for this `attachment_fields_to_save` that helped but that's for the
 legacy media handling. The action implemented here allows for that and
 many other use-cases stemming from the AJAX save_attachment action.

 My biggest problems here are these two:
 - For a very very long time this was not needed. It doesn't seem needed
 now. Imho this looks like a ticket that was opened because of plugin
 development and the author wanted an "easy way" to do something specific.
 Then the author found an existing/different/better way to achieve the same
 result and the ticket became stale.
 - When adding a new hook WordPress takes on the responsibility to maintain
 it "forever". As this hook is not used in core, and there doesn't seem to
 be any pressing need for it right now, and there are no use cases or even
 any evidence that it may be useful (other than it may make it a little
 easier for few plugins in some cases), I don't think it is a good idea to
 add more "backwards compatibility requirements" to the core code.

 If you believe this will be used by 100-200 plugins, and it will make
 performing certain task so much easier, by all means lets add it. Would be
 great to have at least some indication of that. But if something is not
 used in core, and seems nobody needed it for 10 years, and WP will have to
 maintain it forever (even if only 2-3 plugins will ever use it), I'm not
 sure it is a good idea to add it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/23148#comment:40>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform