This will likely be a moderate refactor.

As mentioned in this GitHub comment, we want to support posting drafts with wf-cli, so we don't want this behavior.

Just a heads up @robjloranger: noticed a bug in WriteFreely when testing this, and fixed it in #144. Basically the full collection URL wasn't getting sent back, so after publishing I'd see /matt/new-post instead of https://team.write.as/matt/new-post

Awesome 👍

Yep, if there's already a default set when running auth it won't be overwritten. And there will be a message displayed either way. The idea with setting it that first time is to make that process more seamless, and save people some typing.

Cool, and maybe not overwrite the default if there is one. Users would likely expect when editing the config file it should retain their defaults.

Ah, gotcha. I'll add that in then.

Weird I email responded but it didn't come through.

Right now there's no config.ini file being created in my ~/.writefreely... But it's entirely possible I messed something up. I'm looking into it now

I should add that the config.ini should have a default section. i.e.

Everything still seems to be working as I remember. Can you tell me more about what isn't working like you expect?

I can double check, but I believe it was working last I tried.

@robjloranger How does this work right now? After playing around with wf-cli this is definitely the default behavior I'd like to see, but I'm not seeing it work that way.

Just checking this off the list

taken from Z2, and trimmed/paraphrased:

ok, super strange but it does work now without the collection being sent.

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

OK, let's revert that commit and I will test more to see what the real problem is.

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

Sorry I missed that part. I admit I was eager to do some work yesterday.

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?

fixed upstream issue, v2.0.1

Will be both, I'm thinking of loading the config at the start of each command and pass it down through calls. Some command paths may call LoadConfig 2 or 3 times which is a waste.

In progress as there is no writefreely CLI yet on that branch

in go-writeas PostParams tells JSON to ignore the Collection field

In T586#10141, @robjloranger wrote:

I've got a weird issue, maybe it is by design.

I can not create a new anonymous post against my single user instance using wf. Which would be writeas in the other. The default Post command.

I've got a weird issue, maybe it is by design.

I reverted the change for now, maybe we can revisit in the future but it might be a limitation of the library.

weird, it doesn't work without the flags all being listed as global. Which feels wrong as we never access global flags directly and the cli library docs do not mention anything about that working this way.

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.

second iteration for structure and hierarchy

Another question, do we want to have write.as as the default? as above. Or as a host like others, so we would require writefreely CLI users to either specify a host or set a default. I'm leaning towards this myself.

I've been thinking about this one this morning.

This task will include the full new directory structure.