getPostTypes() limited to 10

[jjlmoya]

Describe the bug

I am developing Gutenberg Plugins I found a problem. if there are more than 10 post types, it only shows me the first 10.

It's not related with "show_in_rest"

Probably it's related with: _context.abrupt but i'm not sure

To reproduce
Use this
edit: withSelect((select) => { const {getPostTypes} = select('core'); return { types: getPostTypes() }; }

Expected behavior
Return all post types

[swissspidy]

Here's the code in question: https://github.com/WordPress/gutenberg/blob/a8bc55089eaa5df32b5ed9c36b038ccb066d4062/packages/core-data/src/entities.js

Looks like there's no pagination for these API requests.

[jjlmoya]

There's no pagination but still return 10 results.
If i use a similar/same code:

apiFetch({path: '/wp/v2/types?context=edit'}).then(function (data) { console.log(data); });

return all the results

I can't upload a fix because I don't know how to work with function* and yield. If anyone take care of it I appreciate it :)

Or if anyone know any workaround using getEntityRecord I appreciate it. It is a big block for my development :(

[lmartins]

Did anyone found a workaround to this?

[bobbingwide]

Did anyone found a workaround to this?

I came across this problem as well today. My pragmatic workaround for my development environment was to patch WordPress core.
I changed the get_collection_params method in wp-includes/class-wp-rest-post-types-controller.php to set per_page to -1

public function get_collection_params() {
		return array(
			'context' => $this->get_context_param( array( 'default' => 'view' ) ),
			'per_page' => -1,
		);
	}

This allowed me to continue. I imagine it's easy enough to fix the client end to do this for both getPostTypes and taxonomies.

[bobbingwide]

I imagine it's easy enough to fix the client end to do this for both getPostTypes

For Gutenberg source I changed packages/core-data/src/entities.js
In loadPostTypeEntities I added the per_page: -1 parameter.

const postTypes = yield apiFetch( { path: '/wp/v2/types?context=edit' , per_page: -1 } );

[bobbingwide]

It now appears that all I needed to do was to add the per_page: 1 parameter to my call to getPostTypes.

const postTypes = select( 'core').getPostTypes( { per_page: -1 });

Hopefully, someone will have a look at these 3 comments and let us know what the right solution is.

[jeremyfelt]

Chiming in on the unexpectedness of this. 😄

• WP PHP's get_post_types() returns all results from globally available data.
• The post types endpoint at wp/v2/types returns all results via get_post_types() and supports no per_page parameter.
• wp.data.select( 'core' ).getPostTypes() returns 10 results by default, even though the API request it makes returns all of them. It uses pieces of JS that generally do expect paginated results from core endpoints. (I think?)

When I originally used it, I assumed getPostTypes() would return all data and was confused when only 10 results were provided. I found (thanks to this ticket) that passing a per_page argument of -1 would return all results.

When per_page is set to -1, it adds per_page=100 to the wp/v2/types endpoint request, which causes no difference in results returned from the API, but does make all of the results available to getPostTypes().

It seems like certain entities should be aware that results are not paginated. I've also found a couple areas of core code that already use -1 for per_page. It seems plausible this could be done for the post type query as well? Though that might be pushing off a better solution for non-paginated results a bit more.

[ntsekouras]

I'm closing this as you can do it like @bobbingwide describes here: #15413 (comment)

[TimothyBJacobs]

I think Gutenberg trying to paginate endpoints that don't have any pagination applied is highly unintuitive and incorrect behavior. At best passing -1 is a workaround.

Even if GB does pass a perPage of 10, I'm not sure where it is truncating the response to that limit. Maybe an issue here

gutenberg/packages/core-data/src/queried-data/reducer.js

Line 34 in 346be7c

export function getMergedItemIds( itemIds, nextItemIds, page, perPage ) {

?

[bobbingwide]

Fortunately I don't yet have 101 post types so I can still use the workaround.

This is one of those things where Gutenberg could happily return the complete list of post types and taxonomies on editor load without adding much overhead. It could even return the post types that aren't show_in_rest but which are valid post types to query and can be displayed by server side rendering.

[ramonjd]

I came across this issue today.

The default pagination value of 10 comes from getQueryParts() I think:

gutenberg/packages/core-data/src/queried-data/get-query-parts.js

Line 43 in a9fbf74

perPage: 10,

To change this value, maybe we could leverage the entity configs, e.g., supportsPagination or some other meta value and pass it down via the action object.