Added pagination to children and default order by menu_order

[rsm0128]

• Added pagination for the children property. (Fix #20 )
• Default order is menu_order for children (Fix #22 )
• Added /posts/ endpoint (Fix #21 ) - /posts/?post_parent_uri=/work/&order=menu_order&per_page=15 is available now.

To determine how many pages of data are available, the API returns two header fields with every paginated response:

X-WP-Total: the total number of records in the collection
X-WP-TotalPages: the total number of pages encompassing all available records

By inspecting these header fields you can determine how much more data is available within the API.

[drewbaker]

Does list:[] syntax come from the default API?

[drewbaker]

OK looking into this, we should follow the syntax and structure explained here: https://developer.wordpress.org/rest-api/using-the-rest-api/pagination/

So children would be an [] and the meta data you have would actually become HTTP headers. Similar to this:

[drewbaker]

@rsm0128 I'm inclined to say that we should make the params just per_page and per_page, not prepend with children_ because is there ever a case where we want both children_per_page and per_page? If we can keep it simple with the default params that's always better.

I do see a scenario where we'd want children and each child has it's first child page with it.

For example, often we need a list of names, linking to first child of each name. Like this:

Cars:
> BMW
>> M3 <-- We want this
>> M6
> Audi
>> A3 <-- We want this
>> A4

And the grid would show all car company logos, but link to the first car of each.

So perhaps that is a scenario for children_per_page=1 and per_page=100?

In that case, we'd want to prepend the children related headers too, to this:

X-WP-ChildrenTotal
X-WP-ChildrenTotalPages

What you think?

[rsm0128]

@drewbaker I removed the children_ prefix from the pagination params and added first grand childs by default. Please let me know your opinion.

[drewbaker]

I think we’d want to be able to opt into the first grandchild feature. Because I think this will be an expensive query to do so shouldn’t do it always.

Perhaps we make a param “depth” that works with the children param?

so I could do ?fields=children&depth=2 and it will get children and grand children? Depth=1 is the default.

Or do we just make it children=2 and not need depth as a separate param? I like the simplicity of that.

[rsm0128]

@drewbaker both of children=2 and fields=children&depth=2 works now.