Bug in Updating attachment of a post = losing post_parent

Confirm the bug introduced by the new constant EXTR_SKIP function line 1223 of post.php
if replacing by previous version as

// Export array as variables
	extract($object);/*, EXTR_SKIP);*/

the attachment updating conserve the post_parent.. and the attachment remain in UI for the author.
I don't no why, but it is !

michelwp, with 2.3 in release candidate, can you confirm the bug is present there?

After installing 2.3 RC1, and testing after uploading images attached to one post :
Symptoms of the bug are the same : the author see images linked to his post disapperance !
A quick look on code (post.php) confirm the same probable origine lines 1275- 1286 i.e. variable passed in function...

Good road for solutions...

I've attached a patch to fix this bug.

I'm not sure why wp_insert_attachment() has a $post_parent argument. I don't see it used anywhere. If it's there I figure it should override the parent in the object so how about we rename the arg to $parent and then insert it into the object as post_parent if it is not zero?

I agree : EXTR_SKIP introduced with 2.2 reveal that the third arg $post_parent is set by default to 0.... and the post_parent transmitted by the object cannot be created...
I don't know why both object and this arg are in the function ?
And if calling functions use this both args..
(for temporary patch I use it (3° arg) from the calling function with an internal name as $parent...)
The patch of filosofo don't keep the problem of this third arg....

(In [6155]) Don't reset parent when updating attachment. Props filosofo and michelwp. fixes #5010

When you are in a write new post window, post_id is set to temp_ID, which is a large negative number. This ends up as the post_parent of atachments that are updated in the browse-all tab, so these attachments get a parent set to this large negative number, which confuses WordPress.

Also if you are in the edit post window and update an attachment in the browse-all tab, it is moved to the post that you are editing and is lost in the post where it was originally attached.

A working solution is to include array('post_id' => ) as 5th entry in $wp_upload_tabsbrowse-all? in upload.php. This resets the post_id argument, and upload.js already tests on this.

There was an empty string after the =>, WikiFormatting probably ate it....

Curioso, this has been fixed for a while. What version of WordPress are you testing against?

I am testing against WP 2.3.1, but I did not see any changes in this area in the current trunk.

The bug I see is not the same as the one originally mentioned, but closely related, because in the browse-all tab attachments are shown with various post_parents, and I think they should not be reset to the post_parent of the current post when updating.

Replying to Curioso:

The bug I see is not the same as the one originally mentioned, but closely related, because in the browse-all tab attachments are shown with various post_parents, and I think they should not be reset to the post_parent of the current post when updating.

If it's not the same bug, then please open a new ticket.

When you do, please give the steps for reproducing the bug in either the latest stable release (currently 2.3.2) and/or trunk.

Thanks for your help!

Reclosing to the previous fixed state.