attachment_fields_to_edit: parameter missing indexes

[ZaneMatthew]

When using the hook "attachment_fields_to_save " the second parameter ($attachments) no longer has the same indexes at it does on WordPress' stable release.

You can reproduce with the following, make a plugin and drop this in then upload an attachment and click "save".

 function my_func( $post, $attachment ){
   print '<pre>'; 
   print_r( $attachment ); 
   print '</pre>'; 
   die();
} 
add_action('attachment_fields_to_save', 'my_func');

Stable WordPress produces this:

Array (
  [menu_order] => 0 
  [post_title] => 
  [image_alt] => 
  [post_excerpt] => 
  [post_content] => 
  [url] =>
)

[helenyhou]

What issues does this cause? post_title, image_alt, post_excerpt, and post_content are all handled differently now, so it makes sense that they no longer show in the array. Not sure about the rest.

[nacin]

attachment_fields_to_save is a fairly interesting hook. It gets a $post and returns a $post. It also gets a bunch of $attachment data that was posted with the form. The bug report is referring to that $attachment data.

Most plugins are going to hook into attachment_fields_to_save, grab their field's value from $attachment, and do one of two things: add it to $post, or more likely, insert post metadata. Not having post_content, post_title, etc., in $attachment shouldn't really matter for this.

That said, you may be using those other fields for context. It's a fairly rare use case, but it is certainly possible.

In the interest in offering full backwards compatibility in 3.5 in the waning days of the release cycle, I'm definitely inclined to send all non-compat fields (title, alt, caption/excerpt, etc.) to save-attachment-compat, even though they will be unused, for the purposes of context.

Zane, could you provide some code that you were using that breaks under RC2? Or was this just something you noticed?

[toscho]

Zane, your sample code cannot get the second parameter. You need:

add_action('attachment_fields_to_save', 'my_func', 10, 2 );

[ZaneMatthew]

Sorry for the confusion, the issue is actually with the hook "attachment_fields_to_edit", because this hook "attachment_fields_to_save", is not even fired or in use anymore (from what I can see). The hook "attachment_fields_to_save" was fired after you've uploaded an Attachment using the "Add New" Media form, a "Save All Changes" button was present, it has hence been removed.

That being said I've updated the Ticket title.

To address the issue of not passing in the number of parameters, you are correct that my snippet was wrong (it also throws a PHP Warning), regardless that does not fix the issue of the $attachments array no longer containing the correct indexes.

Note the contents of the $attachments Array is as followed (for Stable release):

Array
(

[menu_order] => 0
[post_title] => background
[image_alt] =>
[post_excerpt] =>
[post_content] =>
[url] => ​http://gpp.dev/wp-content/uploads/2012/12/background1.jpg

)

Granted I can adjust my code to be "combatible" if WordPress 3.5 will no longer contain this $attachments array.

Note you can just add the following code to your functions.php, or make a plugins.php, and proceed to edit an attachment, noting the differences between Stable and 3.5RC2

function my_func( $post, $attachment ){

print '<pre>';
print_r( $post );
print_r( $attachment );
print '</pre>';
die();

}
add_action( 'attachment_fields_to_edit', 'my_func', 10, 2 );

[nacin]

attachment_fields_to_edit takes a different set of arguments than what you're saying: $form_fields and $post. form_fields is a multidimensional associative array that describes each field. $post is a standard post object of the attachment.

attachment_fields_to_edit no longer contains the standard fields, including image-size, align, image_alt, post_title, post_excerpt, url, menu_order, post_content, and image_url, because these are now rendered using media views. So, these fields are simply not passed to the filter. You can however continue to add form_fields if you'd like.

attachment_fields_to_save does still run, via Ajax. Again, it no longer acts on any standard fields I mentioned above. It is simply there for existing hooks to modify any fields that a plugin added via attachment_fields_to_edit.

attachment_fields_to_save *does* take a $post and an $attachment array, as before.

I don't think there is anything you need to do to adjust your code — but I can't tell you that for certain if you don't supply your code.

[ZaneMatthew]

@nacin thanks for the clarification regarding the arguments, that solves the issue. I must have read other wise regarding those arguments, which lead to some confusion.