.com VIP Image sideloading

[tomjn]

Distributor bundles extra fields when creating posts then uses that to side load images.

However on .com VIP this means broken images as the machines serving requests do not have write access. The result would be broken 404 images in distributor posts

We do have the core media endpoints that could be used, if distributor pre-populated the attachments prior to the request that would sidestep the issue and prevent the need for the extra rest data on push

In the meantime I'm working with our systems team to see if this can be remedied, though that will take some time and I won't have that information today

[tlovett1]

@tomjn I'll wait until we hear from your systems team before we do anything here.

[tomjn]

@tlovett1 An update that I'm still working with the systems team

If this is possible, URLs will need to be whitelisted, but since Distributor attempts to parse API headers to figure these out, this could lead to custom post types being unsupported or partially supported.

You may need a more hardcoded, or restricted way of doing this, especially if using distributor with a new custom post type will require systems level changes every time. It would be best for VIPs if they were prevented from custom post types that had non-whitelisted endpoints unless they explicitly enabled them in code, making sure they were aware a support request was necessary.

Alternatively, if this can be done entirely through the posts endpoint, that would simplify things significantly, and I'd only have to request a single URL be passed through

[tomjn]

@tlovett1 it isn't looking good, we can make it so that creating new posts runs in the needed context, making posts work, but that would completely break GET requests. Sideloading this way is looking increasingly unlikely to work, and I'll admit, the prospects of getting it working that way via REST endpoints be it the new post creation, or media, are looking grim at best.

There will need to be a different mechanism for transferring media across for .com VIP sites. My first thoughts are that the distributor media items are squirreled away and processed later on in a pull via a cron job.

As a sidenote, none of these are issues for VIP Go

[adamsilverstein]

@tomjn Does this issue refer to the use of download_url in utils.php (if not, what exact code is this referring to)? We should be able to replace this block with the VIP helper wpcom_vip_download_image, right?

[tomjn]

The problem isn't a matter of which function, it's a matter of where the code runs. In this context, there is no filesystem write access of any kind, so there is no way to make this work.

Speaking further with systems, I don't see this changing in the near or mid-term futures. It could be a very long time before the creation of attachments via REST API endpoints on .com VIP is a feasible thing. There's a very real chance we're looking at 6 months to a year+

[adamsilverstein]

Thanks for clarifying. I'm going to dig in to better understand where and how this code runs and likely move in the cron for the sideloading direction you suggested.

[adamsilverstein]

@tomjn -

Would sending media separately over the media endpoint work?

Can you confirm if the core Media endpoint would work correctly in VIP for creating media? https://developer.wordpress.org/rest-api/reference/media/#create-a-media-item

If not, will the .com REST API endpoint will work correctly? https://developer.wordpress.com/docs/api/1.1/post/sites/%24site/media/new/

If we sent the media first, we could send the returned object ids to associate media with the post.

[tomjn]

And some systems wrangling means this is no longer an issue :) Sideloading should be possible now

[adamsilverstein]

Woohoo, yea systems wrangling!