pager settings lost for all views when updating from 6.x-2.9 to 3.0-alpha3

Well it's an alpha :)

If you expect less bugs please try out the dev version. There are around 150 less bugs in the dev version, just a short assumption

can you show an example view?

Did you saved the view in the meantime?

In theory the loaded views should automatically be moved to the new settings.
In general you should move from 6.12 to 6.x-3.x-dev. So please try to redo the steps in your development enviroment.

|Yeah it's reproduceable with this view

$view = new view;
$view->name = 'car_icons';
$view->description = 'Icons for the home page, New, Future, Used secondary nav blocks';
$view->tag = '';
$view->base_table = 'node';
$view->core = 0;
$view->api_version = '2';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('fields', array(
  'title' => array(
    'label' => 'Title',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 0,
    'exclude' => 1,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'relationship' => 'none',
  ),
  'nid' => array(
    'label' => '',
    'alter' => array(
      'alter_text' => 1,
      'text' => '[title]',
      'make_link' => 1,
      'path' => 'reviewsbycategory/new/[nid]',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 0,
    'exclude' => 0,
    'id' => 'nid',
    'table' => 'node',
    'field' => 'nid',
    'relationship' => 'none',
  ),
));
$handler->override_option('filters', array(
  'type' => array(
    'operator' => 'in',
    'value' => array(
      'category' => 'category',
    ),
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'id' => 'type',
    'table' => 'node',
    'field' => 'type',
    'override' => array(
      'button' => 'Override',
    ),
    'relationship' => 'none',
  ),
  'status' => array(
    'operator' => '=',
    'value' => '1',
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'id' => 'status',
    'table' => 'node',
    'field' => 'status',
    'relationship' => 'none',
  ),
));
$handler->override_option('access', array(
  'type' => 'none',
));
$handler->override_option('cache', array(
  'type' => 'none',
));
$handler->override_option('footer_format', '1');
$handler->override_option('footer_empty', 0);
$handler->override_option('items_per_page', 0);
$handler = $view->new_display('block', 'Home page icons', 'block_1');
$handler->override_option('fields', array(
  'title' => array(
    'label' => 'Title',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 0,
      'path' => '',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 0,
    'exclude' => 1,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'override' => array(
      'button' => 'Use default',
    ),
    'relationship' => 'none',
  ),
));
$handler->override_option('items_per_page', 9);
$handler->override_option('block_description', '');
$handler->override_option('block_caching', -1);
$handler = $view->new_display('block', 'New Cars Sec-Nav', 'block_2');
$handler->override_option('fields', array(
  'title' => array(
    'label' => '',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 1,
      'path' => 'reviews/New Cars/[title]/all',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 0,
    'exclude' => 0,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'override' => array(
      'button' => 'Use default',
    ),
    'relationship' => 'none',
  ),
));
$handler->override_option('footer', '<?php
print l( \'All\',\'reviews/New Cars/All/all\');
?>');
$handler->override_option('footer_format', '3');
$handler->override_option('block_description', '');
$handler->override_option('block_caching', -1);
$handler = $view->new_display('block', 'Used Cars Sec-Nav', 'block_3');
$handler->override_option('fields', array(
  'title' => array(
    'label' => '',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 1,
      'path' => 'reviews/Used Cars/[title]/all',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 0,
    'exclude' => 0,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'relationship' => 'none',
    'override' => array(
      'button' => 'Use default',
    ),
  ),
));
$handler->override_option('footer', '<?php
print l( \'All\',\'reviews/Used Cars/All/all\');
?>');
$handler->override_option('footer_format', '3');
$handler->override_option('block_description', '');
$handler->override_option('block_caching', -1);
$handler = $view->new_display('block', 'Future Cars Sec-Nav', 'block_4');
$handler->override_option('fields', array(
  'title' => array(
    'label' => '',
    'alter' => array(
      'alter_text' => 0,
      'text' => '',
      'make_link' => 1,
      'path' => 'reviews/Future Cars/[title]/all',
      'link_class' => '',
      'alt' => '',
      'prefix' => '',
      'suffix' => '',
      'target' => '',
      'help' => '',
      'trim' => 0,
      'max_length' => '',
      'word_boundary' => 1,
      'ellipsis' => 1,
      'strip_tags' => 0,
      'html' => 0,
    ),
    'empty' => '',
    'hide_empty' => 0,
    'empty_zero' => 0,
    'link_to_node' => 0,
    'exclude' => 0,
    'id' => 'title',
    'table' => 'node',
    'field' => 'title',
    'relationship' => 'none',
    'override' => array(
      'button' => 'Use default',
    ),
  ),
));
$handler->override_option('footer', '<?php
print l( \'All\',\'reviews/Future Cars/All/all\');
?>');
$handler->override_option('footer_format', '3');
$handler->override_option('block_description', '');
$handler->override_option('block_caching', -1);

The patch fixes the "unlimited" part.

What was the result of your try-out?

Add a random tag

Here is a new patch. Some testing would be really helpful.

This time with improvement to readability and some more code comments.

Commited. Thanks chx for reviewing the patch and make suggestions.

I just downloaded the new version 6.x-3.x-dev, and it breaks all pagers, i can just save display all items in views use pager option even when i choose Display a specified number of items; so pager is broken.

This might fix it. Some testing would be cool.

#18 patch fixes it for me. Thanks!

I tested it and i confirm it works fine!

At least on D7.x sites, this is breaking things badly. Views depending on pagers to show large amounts of information (teaser listing of +400 nodes, will probably run out of memory).

The D7 solution is incomplete. After upgrading to latest D7.x-dev #17 started to happen. Confirming #18 fixes the new issue.

HTH
MyXelf

Confirm that #18 works for me, too ;-)

Here's a p0 version of dereine's patch from #18. This will apply cleanly with drush make (against the current views 7.x-3.x dev as well, which is also affected by this issue.)

Worth noting: While this does allow pagers to work again, it seems there's still an issue with panel_content view displays. My interim solution for that is to allow setting the use page, items per page, and offset options in the pane config. Then setting these in the panel pane configuration when adding the view to a panel.

Thus far it seems to work pretty solidly.

Changing status in the meanwhile

Ok. How do I install the patch?

Thanks,

Mike

Better then breaking this for many users, let's revert to the previous state of the logic and find a proper way to fix the behaviour which chx had.

Phew, I though I was going mad when editing a view reverted the page to "show all items" every time! #23 fixed it for me :)

After many tries with chx here is a solution for non-database views.

After many tries with chx here is a solution for non-database views.

Okay after quite some improvements to the comments i commited it to 7.x-3.x and 6.x-3.x

This still seems to be an issue. Using today's version of dev I get the following issue with all views that were previously working in alpha:

• Views now display all results rather than the number of results set in the view.
• Altering the pager settings changes the settings to "All Items" without allowing to change to anything else.
• This is definitely a confirmed issue in a "default" view that is stored in a file.

I've updated a test site from Views 6.x-2.x-dev to 6.x-3.0 and I can confirm this problems:

a) All the block displays with «Use pager: No» were changed to «Paged, 10 items». Other block displays weren't affected.

b) All the «Panel pane» displays with «Use pager: No» were changed to «Paged, 10 items». Unfortunately, all the panel panes in this site that weren't with «Use pager: No» were with 10 items and pager, so, I would have to set a new test site to see what would happen to other settings. But, we can assume they would probably be ok, like in a).

c) All the «Panel pane» displays are showing all the nodes, despite being setted to «Paged, 10 items». Some have the «Allow settings: None» option on the «Pane settings», and some have «Allow settings: Some» (with pager settings on the panel that are being ignored). This is causing memory time outs in some views (e. g.: Fatal error: Maximum execution time of 60 seconds exceeded in /home/example/public_html/example/includes/theme.inc on line 668 )

None of this problems seems to happen on page displays.

Marking critical as this would break some pages on people's sites (when max execution occurs) and it breaks the normal operation of the module.

This is really a hard issue as you can't know whether a view got converted or not.

I had exactly the same problem with all my views and displays, both in 6.x-3.0 and 7.x-3.1.
This implies a big amount of rework in upgrading (I have more than 100 views)
I think the decision about conversion could be:
- When Use pager option in Views2 is set to No, the option in Views3 should be "Display all items"
- When Use pager option in Views2 is set to Yes, the option in Views3 should be customized.
Good work!

The best way to get a good update is to export your views to code with a decent version of views2.
Believe it or not but this is a way better way to see from which version things come from.

The current logic can be found at views_plugin_display::init(94). We have already tryed hard to get a version which works for all cases(which it does obvious not).

My 6.x-2.16 block pager settings aren't considered by Views 3.x.

dawehner the problem does not appear to be in the conditional itself, (because !empty($items_per_page) && $items_per_page != 10 matches my case) then happens :

$this->set_option('items_per_page', NULL);
$this->set_option('pager', $pager);

where $pager =

array
  'type' => string 'some' (length=4)
  'options' => 
    array
      'offset' => int 0
      'items_per_page' => int 2

Unless the above structure is wrong, the issue probably happens later in the process.

Here is the array as posted when using options_submit, case 'pager_options':

array
  'type' => string 'full' (length=4)
  'options' => 
    array
      'items_per_page' => string '2' (length=1)
      'offset' => string '0' (length=1)
      'id' => string '0' (length=1)
      'total_pages' => string '' (length=0)
      'expose' => 
        array
          'items_per_page' => int 0
          'items_per_page_label' => string 'Éléments par page' (length=19)
          'items_per_page_options' => string '5, 10, 20, 40, 60' (length=17)
          'items_per_page_options_all' => int 0
          'items_per_page_options_all_label' => string '- All -' (length=7)
          'offset' => int 0
          'offset_label' => string 'Décalage' (length=9)

so either the array in the previous comment is too incomplete, either the type (full or some affects the items_per_page setting)

I tried to reproduce such a $pager array structure in init() but it didn't changed anything.
As my block settings are still greyed (marked non-overriden) it's somewhere around pager override settings that the fight should happen) :|

Happens that adding $this->override_option('pager', TRUE); at the end of the block is a good start: field not greyed anymore.
I also found then that the default values (options_form case 'pager':) are still not those expected because at that time $pager = $this->get_option('pager'); only returns TRUE instead of the array, but I don't know why.

I guess a call to views_get_plugin('pager', $pager["type"]) is missing somewhere in init() but don't know how and where ; Drupal code is far from being a pleasant abyss to dig into, ... maintainer ?

I spent hours on this, again, without success.
Do you know guys that GPL forbids obfuscated code ! You overcame by far the limit between complexity and obfuscation. No one would ever takeover maintainer-ship without being paid for (and even so ...) !
There are probably nice contributors out there, but there's also many more hostages (/me being one of them)

Obfuscated? Um. Okay.

I'm sorry you're having trouble understanding it, but that's completely unnecessary. I recommend you take a step back and perhaps invest your energy into something else. Fix your views manually and move on.

This is a really hard problem to solve as evidence by the history of the issue. There is no need to be so rude about it.

This issue is the exact reason we have been afraid to make the 3.0 line recommended.

right, no offense but unnecessary provocation. [ I'd benefit from a `have a drink` widget in the dashboard ]
I'll move on, as you advise, but FYI a common bug stack (actually not that huge) is the following :
* afaict no official language fallback mechanism in Drupal 6 which is (often) a must-have
thus:
* i18n patch : #634144: i18n views content negotiation + Mixed current language, depends on
* i18nviews, depends on
* views 3, depends on
* solving this bug

excuse my naivety (or presumption) about this issue, I didn't find another bug it would have to depend on and believed it was "self-contained".

good luck with it

Well, unless you have a LOT of views, fixing your pager settings is merely tedious but completely doable. Once your pager settings are fixed manually for all your views, you should have no issues.

Oh, one other way of solving this: I believe this only happens for views that are in the database. So you can work around htis by:

Use the bulk export module to export ALL your views to code.

Use drush to revert all your views to the code version.

Upgrade to Views 3.

Once in views 3, either re-export all your views or save your views and remove the export module. Your choice. I believe *that* preserves pager settings properly. (dawehner, can you please confirm or deny this for me?)

Exactly the converting of the views works without problems if you have your views defined in code not in the database.

You two are right but #1557680: More link options not imported :)

Subliminal : please fix it.

I just converted from most recent V2 to V3.0 and got hit with the pager bug. Fixing them after the conversion works, but it doesn't address the broken views in panel panes where the pager numbers are ignored and it displays all the rows. This seems more random, i.e. I don't see the pattern, some work and some don't.

The upgrade from V2 to D7 V3 also has the same problems and editing the views works and even if the bugs were fixed wouldn't fix all the views issues because many of the cck fields also got lost in the upgrade. We are still fighting our way through the 6->7 transition because of many conversion issues. Not enough time has been spent by developers on the upgrade path (yeah I know that is not sexy and I too would rather follow the bright shiny object that is the future).

@merlinofchaos

I believe this only happens for views that are in the database. So you can work around htis by:

Use the bulk export module to export ALL your views to code.

Use drush to revert all your views to the code version.

Upgrade to Views 3.

Once in views 3, either re-export all your views or save your views and remove the export module. Your choice. I believe *that* preserves pager settings properly.

Noting that this workaround no longer seems to work. I tried this procedure with Views Bulk Export and with Features, and had the pager problem in both. Here's the step-by-step I followed:

* Export all your views into bulk export or Features.
* Ensure Views considers them all "default". drush fr my_views_feature --force -y
* Upgrade Views. drush dl views-6.x-3.x-dev -y
-- Test the pager --
* try re-exporting your Views. drush fu my_views_feature -y
-- Test the pager --
* try just saving your views instead.
git checkout sites/all/modules/features/my_views_feature then edit/save each one manually.
-- Test the pager --

The pager settings were lost in all three tests. Is there a step I'm missing here? Is there a conversion tool like there was from Views 1 to 2? The views_update_60xx() hooks don't seem to have anything to do with this, so I didn't bother running the db update during this test.

I applied this patch after updating from 6.x-2.x-dev to 6.x-3.x-dev
Builds on #28, but addresses a few missing pieces.

After updating to 6.x-3.x, successfully updated to un-patched 7.x-3.x and maintained pager settings.

Explanation in comments inline.

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue