- Adding support for calling a creator with a tag selected.
It is using a legacy endpoint but there is no other way currently
documented to get the users post filtered by a tag.
- Fixing the User Tags feature to be paginated
offset is not defined in the API but it is supported.
- Fixed the `/posts` endpoint not working:
1. Added check along with metadata to make sure there is a
creator/service information as that is a requirement
2. Fixed the parameter from tags -> tag.
3. Fixed the _paginate call to exit correctly when there is
a key required for the data (it was prematurely exiting)
- Adding a type of caching mechanism for the metadata/user information.
The current logic would work just fine if looking up for a
singular user, however for the multiple posts via normal
filtering would cause it to either:
This builds a local cache during the process so it should
only make a call for the user info once during the process.
- Updating to meet standards
Fixes
1. Reset formatting for unnecessary line changes
2. Removed Type Hinting
3.Replaced f-string with "".format
Updates
Renamed function creator_posts_tags -> creator_tagged_posts
for clarity of what it does (get posts tags vs get tagged posts)
- Fixing check for the length of response:
1. If it is list - just check len
2. If there is a key - check that the key length is less
than the batch.
- add test for '?tag=...' user URLs
plus some code simplifications
... when computing 'revision_hash'
regression caused by 3d68eda4
dict.copy() only creates a shallow copy
I know that and still managed to get I wrong ...
A SHA1 hexdigest of other relevant metadata fields like
title, content, file and attachment URLs.
This value does NOT reflect which revisions are listed on the website.
Neither does 'edited' or any other metadata field (combinations).
