The 2.0 release felt incomplete without this, so I re-added it, just in simpler form.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 26 2019
Jun 21 2019
Jun 20 2019
Jun 19 2019
Jun 18 2019
Jun 17 2019
Addressed those issues in most recent commits.
Just opened a pull request (GH#123) for this. I still need to verify that data isn't leaking on some ActivityPub endpoints (namely nodeinfo and webfinger), but the core of everything is there and ready to try out.
Jun 16 2019
Jun 15 2019
Jun 14 2019
Nice, this looks great!
Jun 13 2019
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
@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?
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?
Jun 11 2019
Jun 10 2019
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.