WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#5010 closed defect (bug) (fixed)

Bug in Updating attachment of a post = losing post_parent

Reported by: michelwp Owned by:
Milestone: 2.3 Priority: high
Severity: major Version: 2.2.3
Component: Administration Keywords: attachment post_parent has-patch
Focuses: Cc:

Description

When updating (ie title or description) of an attachment "attached" to a post, the "link" to the parent post is set to 0 and the attachment disappear for the author of the parent post...
webmaster workaround : phpmyadmin
seem present since 221
Best regards
Michel

Attachments (1)

save_post_parent_id.diff (1.4 KB) - added by filosofo 10 years ago.

Download all attachments as: .zip

Change History (17)

#1 @michelwp
10 years ago

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 !

#2 @foolswisdom
10 years ago

  • Milestone changed from 2.2.3 to 2.3

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

#3 @michelwp
10 years ago

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...

#4 @filosofo
10 years ago

  • Cc filosofo added
  • Keywords has-patch added

I've attached a patch to fix this bug.

#5 @ryan
10 years ago

  • Priority changed from normal to high

#6 @ryan
10 years ago

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?

#7 @michelwp
10 years ago

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....

#8 @ryan
10 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

#9 @Curioso
10 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#10 @Curioso
10 years ago

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.

#11 @Curioso
10 years ago

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

#12 @filosofo
10 years ago

  • Summary changed from Bug in Updating attachment of a post = loosing post_parent to Bug in Updating attachment of a post = losing post_parent

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

#13 follow-up: @Curioso
10 years ago

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.

#14 in reply to: ↑ 13 @filosofo
10 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

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!

#15 @Nazgul
10 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

#16 @Nazgul
10 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Reclosing to the previous fixed state.

Note: See TracTickets for help on using tickets.