Inconsistent "total" field in paginated API responses based on page and limit

[githubnikola]

Expected Behavior

The total field in the response should consistently represent the total number of items available for a given content type, independent of the current page, limit, or items returned. This would provide a reliable metadata value for pagination logic.

Actual Behavior

When fetching entries for a specific content type, the total field changes depending on the current page and limit.

For example:

On ?page=1 with limit=6:

• Blog posts: The response contains 6 items with a total of 6.
• Events: The response contains 6 items with a total of 7.
• This works as expected.

On ?page=2 with limit=6:

• Blog posts: The response contains an empty array and a total of 0, even though there are still 6 blog posts in total. This is inconsistent and misleading because the total value should always represent the total number of blog posts.
• Events: The response contains 1 item and a total of 7, which is correct and consistent.

Possible Solution

Ensure the total field consistently represents the total count of entries for a given content type, regardless of the current page or limit.

Steps to Reproduce

Set up an API endpoint that returns paginated entries for blog posts and events.

1. Add 6 blog posts and 7 events to the system.
2. Request ?page=1 with a limit of 6:
3. Blog posts: Returns 6 entries and total: 6.
4. Events: Returns 6 entries and total: 7.
5. Request ?page=2 with the same limit:
6. Blog posts: Returns an empty array and total: 0.
7. Events: Returns 1 entry and total: 7.

Simpler setup
Set up an API endpoint that returns paginated entries

1. Add 1 entry
2. Request all entries with getEntries, limit=1, skip=0
3. One entry will be returned, total will be 1
4. Request all entries limit=1, skip=1
5. no items returned, total is 0

Context

The inconsistent behaviour of the total field complicates pagination logic, especially when listing multiple content types (e.g., blog posts and events) on a single page. It forces additional API calls or complex workarounds to calculate accurate totals for each content type. A reliable total field or an alternate metadata endpoint would simplify this significantly.