Offset is not exported to code correctly, overrides default value

subscribing

It would be cool, if someone could export this kind of view, so its possible to see, whether the import or the export goes wrong.

OK, I've encountered the same problem, and I think I've found what is causing this.

If you have a view, where you have displays overriding the 'offset' value, these will not get picked up from the exported code, and this is because (as merlin suggested) 'offset' and 'items_per_page' share the same override flag.

So, what I did was added the line $handler->override_option('items_per_page', 10); just above the line $handler->override_option('offset', 0);, for each display which was overriding the offset value. Cleared the cache, and voila, correct values for all get pickedup. You HAVE to do this for every display that overrides the offset, otherwise none get picked up.

So what I suggest we do here, is well, include the line for 'items_per_page' AND the one for 'offset', if either are overriden, because they share the same override flag, and otherwise it looks like views doesn't pick the line up, even if it's for the default display.

I attach both the original export, and the fixed export that works, so u can use diff on it, but it will get you this:

332a333
> $handler->override_option('items_per_page', 10);
676a678
> $handler->override_option('items_per_page', 10);
729a732
> $handler->override_option('items_per_page', 10);
782a786
> $handler->override_option('items_per_page', 10);
835a840
> $handler->override_option('items_per_page', 10);
888a894
> $handler->override_option('items_per_page', 10);

subscribe

Subscribe, seeing the same issue with exporting Views in Features.

Here's a patch. Can someone review this?

Here's a better patch that saves things like 'path' correctly.

bump and version bump

I can confirm that the workaround in #3 is functional.

OK, finaly found some quite time to test out the patch brynbellomy =)

I've tested it on a fresh install of d6, 6.x-2.11 version of views, with generated content from devel, and the attached view, which is simple enough. Good for testing it if anyone wants to help out. I assume before this gets committed this would have to get rolled out for the latest 6.x dev version of views, and tested there.

The patch #8 does solve the problem, the exported attached view is the result of the export being done with the patch.

I also attach the exported view prior to applying the patch, in which the default offset got the value from the overriden display, in case this helps the reviewing process.

I would set it as RTBC but I think a code review would be nice. I've gone over the patch and it looks good, but I'm not that knowledagble in views ways to stand by it, so I hope someone from the core views dev team would take a peak.

Refactored the above patch into something that more closely reassembles what Views does today.

UPDATE: Ignore this patch - hadn't tested it enough.

Corrected version of above refactoring of the original patch.

Can I get some further testing of this patch? It's a little too much for me to just eyeball and feel comfortable with just now. Some solid use testing would make me feel better about it.

Assigning to bojanz for testing.

Patch in #13 fails for me with the following error (with patch file in Views' directory):

Checking patch view.inc...
error: view.inc: No such file or directory
Checking patch views_plugin_display.inc...
error: views_plugin_display.inc: No such file or directory

You should probably use patch -p0 to apply this patch.

The problem still happens in the latest stable version (6.x-2.14) with a fresh install of Drupal 6.22

Unfortunately the patch #660606-13: Offset is not exported to code correctly, overrides default value doesn't seem to fix the issue. To apply the patch this worked for me:

• Navigate to where you installed the views module (usually sites/all/modules/views)
• Applying the patch (as dereine suggested): patch -p0 < /path/to/patch/name_of.patch

Steps to reproduce the problem:

• Add a node view and some page and block views
• Add a page view and override the number of items and set offset to 1
• Add a page view and use the default options
• Add a block view and override the number of items to 5 but leave offset to 0
• Add a block view and use the default options
• Export the view
• Delete the view
• Import back the view

So what we had initially before the export:

• Default: items per page: 10, offset 0
• Page 1: items per page 10, offset 1 (override)
• Page 2: items per page 10, offset 0 (default)
• Block 1: items per page 5, offset 0 (override)
• Block 2: items per page 10, offset 0 (default)

After the export and import, the settings look like this:

• Default: items per page: 10, offset 1
• Page 1: items per page 10, offset 1 (override)
• Page 2: items per page 10, offset 1 (default)
• Block 1: items per page 5, offset 1 (override)
• Block 2: items per page 10, offset 1 (default)

Looks like after the import the default settings now inherited the offset and Block 2 also inherited the offset although it was overriding the default settings.

Found a quick work around.

In your exported code, you need to manually override the items_per_page also, and it will work.

So find your override for the offset, and add this above it. Even if the items_per_page is the same for each display.

+  $handler->override_option('items_per_page', 4);
  $handler->override_option('offset', 4);

Clearly these two are linked in some way.

@daggerhart if you have the way to reproduce this handy, would you mind testing the patch on #13 please?

@Manuel Garcia

The patch did not work for me. My testing environment has 2.16, so I applied the patch manually.
Create a new view w/ 2 block displays: first block shows 2 items no offset, second block shows 2 items with offset of 2.

Exported to code:

$view = new view;
$view->name = 'export_test';
$view->description = '';
$view->tag = '';
$view->base_table = 'node';
$view->core = 6;
$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('access', array(
  'type' => 'none',
));
$handler->override_option('cache', array(
  'type' => 'none',
));
$handler->override_option('items_per_page', 2);
$handler->override_option('row_plugin', 'node');
$handler->override_option('row_options', array(
  'relationship' => 'none',
  'build_mode' => 'teaser',
  'links' => 1,
  'comments' => 0,
));
$handler = $view->new_display('block', 'Block', 'block_1');
$handler->override_option('block_description', '');
$handler->override_option('block_caching', -1);
$handler = $view->new_display('block', 'Block', 'block_2');
$handler->override_option('offset', 2);
$handler->override_option('items_per_page', 2);
$handler->override_option('block_description', '');
$handler->override_option('block_caching', -1);

There is no items_per_page or offset for block_1. Import used block_2's settings as the default.

If I manually add the items_per_page and offset to block 1, it imports correctly.

$handler = $view->new_display('block', 'Block', 'block_1');
$handler->override_option('offset', 0);
$handler->override_option('items_per_page', 2);

Thanks for the review daggerhart !

Hi guys

I have applied the patch in #13 and it doesn't quite work.

I think it is setting the override options correctly in the overridden display, but not setting the offset of 0 (or whatever) in the default display.

The work around of adding
$handler->override_option('offset', 0);
$handler->override_option('items_per_page', 10);
to the default display works here too.

I will try and look at this and update the patch when I have time.

Here is an updated patch.

FYI, final QA testing for the drupal.org D7 upgrade begins next week, and we're going to need this fix as part of the Git Team's requirements.

Any movement on this one?

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