Sounds good. I'll go ahead and revert it.

No worries. Yeah, the library should be taking the parameter and using it to change the endpoint, as is done here in post.go

So, the PostParams.Collection field was left out of the JSON because it shouldn't ever get sent along with the payload. Instead it's used to set the API endpoint in go-writeas, e.g. /api/collections/{Collection}/posts. Is there another reason it's needed in the JSON?

sync might be a little ambiguous, especially with our upcoming T584 changes. Maybe something like claim or own instead?

I agree, storing posts.json comes with challenges. But, a few things:

I'd say yes, we should support being authenticated for multiple users on one host. So .writefreely/host/username.ini or .writefreely/host/username/config.ini. As for the location to store posts, see T584#10089.

This is dependent on backend changes (T637: Support more attributes when creating a collection).

I threw together an offline importer for this: rWFM / https://github.com/writeas/wf-migrate -- for reference in building this into the web application.

I'd say the default behavior should be #1, to generate a unique slug for the imported collection.

As for terminology, I would say we should have "synced" vs "unsynced" for our release, just so we don't confuse people. Maybe the title then is "Status" instead of "Location"

Here's a library I built to start this rolling: https://github.com/writeas/zip-import

TODO: is this WF only? Or both CLIs?

TODO: is this WF-only? Or both CLIs?

In T594#9289, @robjloranger wrote:

this will be set on the writefreely cli, the writeas cli will retain the original .writeas directory

Created WriteFreely CLI, so it's easier to track features that should be in only one client (or both). In this case, this is a WF CLI feature only.

Created WriteFreely CLI, so it's easier to track features that should be in only one client (or both). In this case, this is a WF CLI feature only.

Assuming the #117 fix works in your testing, after reviewing everything I do think this is the right solution.

Just to mention, here's some prior art on publishing text files via the API: https://github.com/writeas/writeas-api/tree/master/examples/go-text-importer

This might be good to do in the near future -- certainly before v1.0 -- because of how much easier it'd make the setup process.