Content API V2: Don't return authors and tags without posts

[kirrg001]

(refs #9866)

This is a change for API v2 only.
The Content API should not return authors or tags with no posts.

Use Case

You have an administrator which organises the blog, but does not write posts.

Things to take care of

• sitemaps service should not return these urls for v2
• sitemaps service should return these urls for v0.1

Requirements/Underlying problem

GQL does not support filtering and couting e.g. filter=count.posts:>0. We first need to finish NQL and replace GQL with NQL in Ghost.

The sitemap service depends on the url service. And the url service is independent of API versions. The url service fetches data in bootstrap straight from the model layer. That means urls are being created independently from the API result/behaviour. e.g. v0.1 should show author urls with posts count 0 and v2 should not show them.

IMO we need to refactor the url service to request the configured (by the theme) API version. And if the theme changes the api version, we need to purge the url service and rebuild the cache. The challenge here is that we need to execute raw knex queries, because bookshelf is too slow e.g. api.v2.posts.all()

This needs some more thoughts and architecture ideas.

Hacky solution

It's possible to hack this feature into V2 without resolving the requirements, but it's really ugly and hard to maintain. See PR: #10123

TODO

• don't return authors with no posts
• don't return tags with no posts
• sitemap should also not list authors without posts
• sitemap should also not list tags without posts
• fix critical bug: controller have custom names (Refactored routing config for multiple api versions #10333) @kirrg001

[ErisDS]

We discussed an alternative solution to this in slack: model splitting.

Pre API versioning, Ghost used a single 1:1:1 table:model:api for each of Posts, Tags and Users.
We no longer have a single API, and there is no reason why a table must only have one model. Bookshelf will allow us to have multiple models, have models that extend one another, have models that share functionality through plugins, and have different APIs depend on different models, but refer to the same tables.

We can represent Published posts, Public Tags (includes internal tags!) and Authors as separate models, which automatically have filters built into them, implemented very similarly to a soft delete plugin.

This will allow us to more easily have frontend business logic defaults for ordering, filtering, limits etc for the Content API, and a different set of more generic defaults for the Admin API.

[naz]

As d3f3b3d has landed in master there are 2 main problems that need to be addressed before the release described in detail here. In short:

• sitemaps problem has it's root in url service not being able to distinguish that related resources were changed. We need a way to pass information to Resources.js to event's like _onResourceUpdated telling about relational data being changed e.g.: tag was removed (@gargol)
• routing needs 2 configurations similarly to resource configurations introduced in d3f3b3d (@kirrg001 )

[naz]

All checkboxes ticked, time to close this issue 🎉