Allow updating attachments with new files

[joehoyle]

Currently the Media endpoint only allows setting the file on upload, it would be handy in some cases to allow replacing / updating the media file for an attachment.

For example, maybe I have an image editing app that uses the rest api, and when a user makes edits, I'd want to post the updated image back and update the attachment with it.

[SergeyBiryukov]

Related: #20602

[kadamwhite]

From @joemcgill in Slack:

There are some plugins that implement this, but it’s not something we have UI for in core, nor a simple API to implement at the moment.

All editing in core is currently handled on the server side and not something that we have any need to expose to third party editors, but I like the idea of being able to build decoupled image editors on top of the REST API, so it would be worth doing a quick feasibility PoC.

[joemcgill]

Unless we had some application that required this functionality in core, I would suggest that this is plugin material. The external editor use case is definitely and interesting one, but I could also see this opening up problems where files are updated on existing attachment posts that container totally different metadata which should really have been an entirely new object.

The closest example we currently have in core that I can think of this similarly to how custom theme images—like headers and site icons—are created now as new attachments instead of updating files for an existing attachment.

[joehoyle]

The closest example we currently have in core that I can think of this similarly to how custom theme images—like headers and site icons—are created now as new attachments instead of updating files for an existing attachment.

I think the closest example in core is the image editor, which mostly because it was built pre-rest-api doesn't have the image updating logic in an endpoint, but core does include this behaviour.

but I could also see this opening up problems where files are updated on existing attachment posts that container totally different metadata

That's a good point, I had considered maybe limiting the mime type for example to the original attachment, but yes, by opening up an endpoint we'd probably be allowing more difference than the in-line PHP editing that is done in core currently.

I think sooner or later, this will have to be included in the REST API. I think it's likely any future media editing even in the admin is likely to use the REST API, and we get a two for one by letting clients also use it. I don't know how the WordPress mobile app does this, but I assume it just doesn't let you edit images, which I think is probably not a great user experience.

Editing an image for your site icon has the user expectation that you wouldn't destroy / replace the original image, but the "direct" editing of an attachment comes with the expectation you are actually editing "the thing".

---

So, my "argument" :D is: this functionality already does exist in Core, it's just that Core doesn't need an endpoint to use it. By adding this to the REST API, we allow 3rd party image editing tools to be used with WordPress, and we also allow for future Core/Admin image editing to use the same endpoint.

[joemcgill]

I think the closest example in core is the image editor, which mostly because it was built pre-rest-api doesn't have the image updating logic in an endpoint, but core does include this behaviour.

That's a good point. However, there is one major difference in the way these systems work versus what you are describing. For these cases, all of the file editing logic happens on the server via the WP application and the editor sends the transformation "instructions", e.g., crop dimensions, rotations, etc, to an Admin-Ajax callback, which executes the instructions and updates the file.

There is no place where an external editor would update an attachment file itself and then upload a new file (that I'm aware of). I'd be more than happy to see us expose more transformation options vis the REST API as a first step towards a fully decoupled editing experience.

[joehoyle]

Yeah, I was thinking about a transformation API, but I think that would be very limiting and not that worth doing. By allowing a blob upload, REST API clients can do whatever transformation / filters they want - allowing crop etc as transforms would be mostly a dead end IMO. I think even today if you were to implement this in the admin, you'd actually want to post a blob back, and do all transformation in JavaScript, say on a <canvas>.

[azaozz]

Replying to joehoyle:

I think even today if you were to implement this in the admin, you'd actually want to post a blob back, and do all transformation in JavaScript, say on a <canvas>.

Also note this WICG proposal: ​https://discourse.wicg.io/t/proposal-native-media-optimization-and-basic-editing-support/4068/11. Eventually "native" image editing may be (is?) coming to the browsers, including setting of the EXIF data, etc. If/when this gets added to the browsers thinking the old-style image editor should finally be replaced with a client-side editor that, ideally, would be using the REST API.

[joemcgill]

Related, there is #44405, which is specifically suggesting that we expose transformation options via the API to enable things like the experimental image editing tools implemented by JetPack here: ​https://github.com/WordPress/gutenberg/issues/13748#issuecomment-574903126. It would be worthwhile to agree on the preferred approach to these problems.

Perhaps looking at some examples of how other services are handling these types of transformations would be instructive?

[azaozz]

For example, maybe I have an image editing app that uses the rest api, and when a user makes edits, I'd want to post the updated image back and update the attachment with it.

Been thinking about this for a while and don't think this is a good idea in general. Perhaps this may be handy in some edge cases, like editing a just uploaded image, but replacing one image file with another image file (with possibly different dimensions) has high probability to break prior posts.

When editing an image (file) best workflow is to always create a "new version" of the image, and not delete/replace the old, original version. Then, if deemed necessary, the UI may offer to the users to delete the old image. However the old/original image should not be deleted/replaced automatically. There are two reasons:

• The original image may have been used in a post.
• WP may be used as "media storage", deleting originally uploaded files should never happen without explicit user consent.

Agree with @joemcgill in comment:3 that the "replace attachment file" functionality is plugin material, and should be used with care. Core shouldn't do that. It would be a lot better workflow to create new attachments for edited images.

[TimothyBlynJacobs]

Closing per @azaozz latest comment and since we've taken that approach with the image editor endpoints introduced in 5.5.