WordPress.org

Make WordPress Core

Opened 3 months ago

Last modified 2 months ago

#49096 new enhancement

Allow updating attachments with new files

Reported by: joehoyle Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: REST API Keywords:
Focuses: rest-api Cc:

Description

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.

Change History (9)

#2 @kadamwhite
3 months ago

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.

#3 @joemcgill
3 months ago

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.

#4 @joehoyle
3 months ago

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.

#5 @joemcgill
3 months ago

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.

#6 follow-up: @joehoyle
3 months ago

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

#7 in reply to: ↑ 6 @azaozz
3 months ago

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.

#8 @joemcgill
2 months ago

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?

This ticket was mentioned in Slack in #core-restapi by joemcgill. View the logs.


2 months ago

Note: See TracTickets for help on using tickets.