This will likely be a moderate refactor.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 27 2020
Sep 23 2019
Sep 20 2019
As mentioned in this GitHub comment, we want to support posting drafts with wf-cli, so we don't want this behavior.
Sep 12 2019
Sep 6 2019
Sep 4 2019
Aug 29 2019
Aug 1 2019
Jul 22 2019
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.
Jul 21 2019
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
Jun 21 2019
Jun 18 2019
taken from Z2, and trimmed/paraphrased:
Jun 13 2019
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
Jun 12 2019
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.
Jun 11 2019
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.
Jun 10 2019
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.
Jun 7 2019
This task will include the full new directory structure.