[wp-trac] [WordPress Trac] #60375: Site Transfer Protocol

[WordPress Trac]

#60375: Site Transfer Protocol
-------------------------+------------------------------
 Reporter:  zieladam     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Import       |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by zieladam):

 > The more I consider it the more I see these as the same thing, whereby
 the ZIP format is the means through which we normalize the transfer. I
 could be totally overlooking obvious things here though, so I would like
 to know where this idea makes no sense.

 I think you're right here. To me, Host <-> to ZIP is a version of the Host
 <-> Host scenario where one of the Hosts passively accepts the stream and
 never asks to pause, rewind, resume, compute delta etc.

 > The challenges I'm capable of seeing at the moment are all more related
 to whether we ship wp-content assets the same way we ship database and
 config values. It's all about bulk data and less about the destination of
 the transfer.

 I consider both bulk data. Database dumps may be as large as 300GB.
 Harmonizing the transfer infrastructure for both seems like more reliably
 and less code.

 > Of course there'd be duplication of content in the WXR vs. the tables,
 but I see the database as the authoritative source for non-asset content
 while the WXR could be a reasonable signaling protocol to guide the
 import.

 We should bet a clearer idea of what's worth including in WXR and
 duplicating from the database once we start shaping the code. I remain
 open minded.

 > Even if we have post content in the WXR it will lack the meta
 information unless we also export it there as well, which I guess we could
 do, and even remove those rows from the sqlite database 🤷‍♂️

 I'm hesitant about this. We'd have to preserve IDs so it would be just
 moving the data for the sake of moving it.

 It should be fine to ship a WXR file that has no content at all, only the
 guiding metadata. I even wonder whether Blueprints could be expressed as
 WXR, in which case the exported WXR file would be a Blueprint.

 > yeah we'll need another layer of error handling, but we should be able
 to restart the ZIP mid-sequence on the source site.

 Agreed! Here's a fancy idea – we could support partial uploads. Instead of
 uploading the entire 1GB ZIP all at once, it would become a series of
 requests, each transmitting a part of that ZIP. This way no crash would
 invalidate all the work. Even if the internet goes down, you'd just
 "upload" the ZIP file again and only the unprocessed bytes would be
 uploaded – and stream-processed during the upload.

 > is to create a relatively small manifest on the source site to start the
 process. this could do a number of things:

 It could be bundled in WXR perhaps.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60375#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform