Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#22776 closed defect (bug) (fixed)

Ensure compat data is saved

Reported by: koopersmith's profile koopersmith Owned by: nacin's profile nacin
Milestone: 3.5 Priority: normal
Severity: normal Version: 3.5
Component: Media Keywords: has-patch
Focuses: Cc:

Description

Two things for compat:

1) Some plugins were expecting compat to be rendered and saved when an image is uploaded (for things like default values of form elements). As a result, when an image is first uploaded, should we fire saveCompat?

2) The compat view should have the same save-on-removal features the attachment details have. Patch attached for that.

Attachments (1)

22776.diff (794 bytes) - added by koopersmith 11 years ago.

Download all attachments as: .zip

Change History (9)

@koopersmith
11 years ago

#1 @koopersmith
11 years ago

Test this by opening up the edit gallery view, selecting an image, and inputting some data into a compat field. While the field is still active, click on another attachment. Did the data save?

#3 follow-up: @nacin
11 years ago

I don't know if we should do anything about this.

#4 in reply to: ↑ 3 @nacin
11 years ago

Replying to nacin:

I don't know if we should do anything about this.

I meant for part 1.

+1 for part 2.

#5 @nacin
11 years ago

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

In 23098:

Media: When the attachment details view changes to another view or attachment, save compat fields on destroy. (We already do this for non-compat fields.) props koopersmith. fixes #22776.

#6 follow-up: @nacin
11 years ago

Replying to nacin:

I don't know if we should do anything about this.

I meant for part 1. Part 2 is in.

#7 in reply to: ↑ 6 @nacin
11 years ago

Replying to nacin:

Replying to nacin:

I don't know if we should do anything about this.

I meant for part 1. Part 2 is in.

Oops, back button caused me to post that twice. Or I'm just tried. That.

#8 @koopersmith
11 years ago

Agreed. For part 1, it's bad any way you slice it — the bottom line is that we'd have fire an ajax request any time we encounter an attachment for either render and/or insert — and all this just to provide safety for not providing default values, which is a poor development practice in its own right (regardless of the version of WordPress that you run). We're going to let part 1 ride.

Note: See TracTickets for help on using tickets.