Perfect 👍

sure, I'll add that in.

Nice, this looks great!

quick ascii cast demo, running on my local machine so the restart fails as it's not running.
https://asciinema.org/a/8IaQxRBjRA955cm8Jjy86XtPi

Yeah, a button like that would be the end-goal. And maybe pair that with T579: WriteFreely daemon to make it all seamless.

An authoritative source for checking the current version number: https://version.writefreely.org

I guess initially just a script would work. I haven't looked yet but the a go utillity would be nice, the admin could then just have a check for updates button which could then ask to download and confirm upgrade/restart.

@robjloranger What do you think would be the best way to do this to help with T600? A single Go-based utility? A simple bash script?

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.

removed parent as this should not be a hard requirement but a nice to have feature