in custom_pagers.php : 233

// $Id: custom_pagers.module,v 1.6 2008/06/17 21:20:32 eaton Exp $
    elseif (module_exists('views') && $view = views_get_view($pager->view)) {
      // Get arguments for the view.
      if (isset($pager->args)) {
        $args = explode("\n", $pager->args);
        if (module_exists('token')) {
          $args = token_replace($args, 'node', $node);
        }
        $view->set_arguments($args);
      }

      // Make sure the query is not cached
      $view->is_cacheable = FALSE;
      $view->execute();

is this enough to handle with Items to display?
I have a View and STRAIGHTFORWARD SET 50 items! pager appear only on first 10 (ten) nodes. why?
i found only such code Views

// $Id: view.inc,v 1.115 2008/07/02 19:21:47 merlinofchaos Exp $
  // pager variables
  var $pager = array(
    'use_pager' => FALSE,
    'items_per_page' => 10,
    'element' => 0,
    'offset' => 0,
    'current_page' => 0,
  );

So question is - when it was beauty and strong?

Comments

merlinofchaos’s picture

Project: Views (for Drupal 7) » Custom Pagers
Version: 6.x-2.0-rc1 » 6.x-1.x-dev
Component: Views Data » Miscellaneous

This looks like your real question is about custom pagers.

Andrey Zakharov’s picture

Title: views and custom_pagers works strange » views and custom_pagers works strange (view->execute)
Project: Custom Pagers » Views (for Drupal 7)
Version: 6.x-1.x-dev » 6.x-2.0-rc1
Component: Miscellaneous » Code

is view::execute respect Items to display property of default Display????
view.inc : 676

// $Id: view.inc,v 1.115 2008/07/02 19:21:47 merlinofchaos Exp $
        $offset = $this->pager['current_page'] * $this->pager['items_per_page'] + $this->pager['offset'];
        $result = db_query_range($query, $args, $offset, $this->pager['items_per_page']);

merlinofchaos’s picture

Status: Active » Closed (fixed)

You know, if Views didn't respect these fields from the displays, there'd be thousands of bug reports.

The fields are copied from the display into the $view as part of execute_display, which is not run here.

dergachev’s picture

merlinofchaos’s picture

It appears my clarification was to terse to be understood by people not plugged into the code. =)

The normal routine for displaying a view involves calling $view->execute_display() or $view->preview().

If one of these two functions is *not* called, then pager data from the display does not get copied to the view, and it remains at whatever the view's default settings were at. Therefore, it is imperative that you run the pre_execute phase manually.

Please examine view::execute_display() and/or view::preview() in view.inc to see what this does.

sinasalek’s picture

Version: 6.x-2.0-rc1 » 6.x-2.12
Status: Closed (fixed) » Active

No matter how many different way i tried (including the suggestion mentioned here), views still ignore the overidded pager values :(
When i var_export views before executing it, i can clearly see that the new paging values are applied. however after they don't have any affection on the result!
I don't really know what else i can do. What's wrong with this code?

$view = views_get_view($view_name);
$view->set_display($display_id);
 // Put all arguments and then execute.
$view->set_arguments($args, FALSE);
$view->set_offset($offset);
$view->set_exposed_input($exfilters);
if (!empty($limit)) {
    $view->set_use_pager(TRUE);
    $view->set_items_per_page($limit);
    $view->set_current_page($page);
}
else {
   // Disable the user pager.
   $view->set_use_pager(FALSE);
}
$view->display_handler->set_option('current_page', $page);
$view->display_handler->set_option('use_pager', 1);
$view->display_handler->set_option('items_per_page', $limit);
$view->display[$display_id]->handler->options['items_per_page'] = $limit;
$view->display[$display_id]->handler->options['display_options']['use_pager'] = TRUE;
$view->pager['items_per_page']=1;
$view->execute_display($display_id);
sinasalek’s picture

Status: Active » Fixed

Turned out to be a caching issue! Fixed using the following code

$view->display_handler->set_option('cache',array(
		'type' => 'none',
	));

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.