Limit number of requested items for collection queries

[Toddses]

No way to query for all terms. With get_terms() from WordPress you can pass the number arg as 0, or it defaults to 0, to get all the terms with the associated taxonomy. The terms controller uses per_page to fill out the number arg. The default for per_page is 10, and you can't pass 0 to this argument (or any negative numbers, because it sanitizes the value with absint). This effectively makes it impossible to query for all terms in a taxonomy.

[donaldallen]

How are you using filtering on this request?

I've tried:

wp-json/wp/v2/terms/community_area?filter[per_page]=100

And I'm still only getting back 10 results. Is per_page incorrect usage? I tried this as well:

wp-json/wp/v2/terms/community_area?filter[number]=100

[Toddses]

wp-json/wp/v2/terms/community_area?per_page=100

Don't need the filter on this one.

[donaldallen]

So even if I do that, I only get back 10 results. If I go into class-wp-rest-terms-controller.php and change:

$prepared_args['number']  = $request['per_page'];

to:

$prepared_args['number']  = 100;

That works. When I var_dump the $request, I'm not seeing per_page or anything else I pass through.

[Toddses]

Strange - I don't seem to be having this issue. I can pass per_page and get the expected results. What version of the API are you running? What args are you using to set up the custom taxonomy?

[donaldallen]

Args for my custom post type:

    $args = [
        'label'               => __('community', 'something'),
        'description'         => __('Community', 'something'),
        'labels'              => $labels,
        'supports'            => ['title', 'thumbnail', 'editor', 'excerpt'],
        'hierarchical'        => false,
        'public'              => true,
        'show_in_rest'        => true,
        'show_ui'             => true,
        'show_in_menu'        => true,
        'show_in_nav_menus'   => false,
        'show_in_admin_bar'   => false,
        'menu_position'       => 31,
        'menu_icon'           => 'dashicons-admin-multisite',
        'can_export'          => true,
        'has_archive'         => true,
        'exclude_from_search' => false,
        'publicly_queryable'  => true,
        'capability_type'     => 'page',
    ];

And the args for my taxonomy:

    $args = [
        'labels'                     => $labels,
        'hierarchical'               => true,
        'public'                     => true,
        'show_in_rest'               => true,
        'show_ui'                    => true,
        'show_admin_column'          => true,
        'show_in_nav_menus'          => true,
        'show_tagcloud'              => true,
        'query_var'                  => true,
        'rewrite' => [
            'hierarchical' => true,
        ]
   ];

Running 2.0-beta4.

[joehoyle]

This is working on the Demo site at: http://demo.wp-api.org/wp-json/wp/v2/terms/category?per_page=100

In regards to getting all terms at once (rather than paged) we are currently trying to make all the collections consistant, so /posts for example, doesn't allow fetching on unlimited data sets but instead implements paging. This is pretty typically of most REST apis, however I'm not staunchly against that. Will flag at the next meeting or feedback welcome from the @WP-API/amigos

[donaldallen]

Thanks @joehoyle. Any ideas why it wouldn't be working with my setup? Bare-bone WP install, with WP REST API 2.0-beta4. My custom post type and taxonomy args are above. No matter what I enter in per_page, I only get 10 results.

The taxonomy is shared by two custom post types. Not sure if that matters.

My URL looks similar to the one you shared: http://mysite.dev/wp-json/wp/v2/terms/community_area?per_page=100

[joehoyle]

I think you were probably close with var_dumping the request object where you were before. I'm not sure why it wouldn't pick up your query param there - unless there's some odd server config with forwarding those. Could you maybe also var_dump $_GET and $request where you were debugging before?

[donaldallen]

Weird, when I dump $_GET, it's empty. I wonder if it's related to any of my rewrites. Going to check it out.

[Toddses]

@joehoyle Well let me ask what's better for performance - querying for all terms and getting a large dataset, or hitting the server with a whole bunch of requests in a row? I don't mind adding the complexity of getting a paginated result set when I want everything, but if that negatively affects the performance we're going to see, obviously that's a different story.

[joehoyle]

@Toddses yes in that case getting more at once is better, however that also depends on preventing attacks where you'd have some throttling on requests etc, so in terms of defence I'd still prefer the fewer at a time approach. This breaks down given that we support per_page=9999999 now anyway, so this is just inconvenient right now with us not letting a 0 query through. I'm going to flag this for discussion so we can talk about what the general approach though be to paginated / unlimited queries.

[danielbachhuber]

In regards to getting all terms at once (rather than paged) we are currently trying to make all the collections consistant, so /posts for example, doesn't allow fetching on unlimited data sets but instead implements paging.

Requesting thousands of entities at once can let an unauthorized client easily overload a server. I think we need to limit by default. If you have access to the server, you could always change the limit.