Unable to get thread / post count and read / unread state for categories in API

[Jake B.]

Affected version

2.1.11

As the title says, not sure how exactly these values get calculated on the frontend of the node list, but it ends up coming from the $extra variable within the macro. However, the getNodeListExtras method on the entity returns an empty array within the API. Not sure what I can do to expose these values on the API side, but it is pretty important functionality that is missing

 

[Mike]

The API is reporting back the individual entities, which is actually how XF stores it. A category itself doesn't have any extras.

What you're referring to is something that we calculate when we have the whole node tree (or a complete sub-tree). See XF\Repository\Node::getNodeListExtras (and mergeNodeListExtras). This is dynamically based on what the user can actually view.

So it's very unlikely that we'd change what the API is returning, which relates to a specific node, as it would now require the entire subtree under it. We only do calculations like this when we're specifically in a context where it's needed (forum list-like instances).

 

[Jake B.]

Hm, okay. We'll need to figure out some sort of workaround on our end in that case to get it in the API results

 

[Mike]

Just to clarify, if your use case is to display a node list, then we could potentially include the merged data as a separate key returned by GET nodes/. Saying that, this does probably need a different approach than the existing getNodeListExtras stuff as we probably need to ensure it's not a massive data overload (which it would be if we included LastThread/LastPoster entities for example), so it's not entirely trivial.

 

[Jake B.]

That's what I was thinking of as well for the main node list, but we've also got endpoints that let you specify a parent ID and get the children of that node up to a certain depth so there could still potentially be issues there where a great-grandchild node hasn't been loaded. I think we've ended up getting a workaround for it caching the number of threads / posts for each permission combination, just have to do some testing on how heavy that ends up being