Support » Developing with WordPress » setting custom posts per page affects admin panel

  • Resolved visionm

    (@visionm)


    Hi. I am trying to set the query post per page to -1 for all queries but it is causing problems in the admin panel.

    currently my code is

    
    add_action( 'pre_get_posts', 'custom_query_vars' );
    function custom_query_vars( $query ) {
      if (  ! is_admin() && $query->is_main_query() ) {
    	$query->set( 'posts_per_page', -1 );
      }
    }
    

    but this is not correctly setting the posts per page in my query.

    When I remove the && $query->is_main_query() then the query displays all posts, as intended, but while editing pages the admin panel does not show reusable blocks and the query loop preview does not load anything.

    Any ideas about how I may be able to achieve setting the posts per page to -1 for all queries on the site without these undesirable effects?

    The page I need help with: [log in to see the link]

Viewing 3 replies - 1 through 3 (of 3 total)
  • Moderator bcworkz

    (@bcworkz)

    The block editor relies a lot on the REST API. I suspect that’s where you’re having difficulty with certain editor functions. You can check if the constant REST_REQUEST is defined to avoid altering the editor’s API requests.

    I don’t understand why setting the count to -1 would cause nothing to appear in some editor functions. Maybe the results overwhelm the related REACT code that processes API responses? IDK. If you continue having trouble, use the Query Monitor plugin to view the actual SQL used. That should help you learn why no results appear in some cases.

    Thread Starter visionm

    (@visionm)

    Thank you. This seems to be working

    add_action( 'pre_get_posts', 'custom_query_vars' );
    function custom_query_vars( $query ) {
      if ( !is_admin() ) {
    	  if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
    		  return;
    	  } else {
    		$query->set( 'posts_per_page', -1 );
    	  }
      }
    }

    My only question here is that if is_admin “determines whether the current request is for an administrative interface page” why is this not preventing “collisions” here causing problems in the gutenburg editor?

    • This reply was modified 1 week, 6 days ago by visionm.
    Moderator bcworkz

    (@bcworkz)

    G’berg relies a lot on the API. is_admin() basically looks for “/wp-admin/” in a request. API requests don’t have “/wp-admin/” in the URL. Not all API requests are for admin purposes, there’s not a good way to distinguish one from another. In any case, is_admin() relates only to the current request. API requests are completely independent. If you embedded content, you wouldn’t expect the remote site to influence your is_admin() call. API requests are no different.

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.