Expose: Items per page and Offset

any way of doing this? would also like to see this feature.

Unfortunately this is not currently possible. This may be at some future point but it won't be soon.

Any news on this? Or does anyone know how to achieve it with a workaround (like letting the view fetch data for the maximum value but showing only a specified amount)?

subscribing.

me too waiting..

Tagging

subscribe too. waiting for this

Would be very nice. Subscribing.

Hi. I want to help with this issue.

I'm thinking in two different approaches to do this.

One way is modifying each of displays plugins that views provide and expose this value into a form. This options need to get the values from url. We can use $_GET, however, this is not a good way to implement this.

Another way is implement Items per page as a handler. Right now, views provides five kinds of handlers: filters, sorts, fields, arguments and relationships. Of course this new handler doesn't fit into this handlers. For this reason, it should be interesting provide a new "generic" handler. Since #458140: Allow any handler to use exposed form was commited, handlers can be exposed if can_expose() returns TRUE.

I think this can be done easily with:

function build() {
  // ....

  $this->_build('generic');

  // ....
}

However, this approach is more complex to build, and I'm not sure if it is really necessary.

Anyway. What is the better approach? Is there another way to do this?

Sorry for my English.

I don't believe this needs to be a handler. I think the display (and potentially the style) simply need to be able to be involved in the exposed form.

I've run across the russian module that seems to do exactly that. Did not test it though (I can live without functionality, and I don't like dropdowns)
I could not find it in official repository for some reason, so here is the link to the russian page.
http://www.drupal.ru/node/31064

Here is the patch.

I'm not sure if $_GET is the only way to get the values for items per page.

Previous patch doesn't work if there isn't exposed filters enabled. Sorry.

New patch.

+1

Will try reviewing the patch when I get a minute =)

Just for general idea: Make everything exposeable. Wouldn't it possible to use options_form and expose it. Sure this needs a lot of work, i guess. But i think its better then making more an more manual settings.

It would then be cool, if you could choose which items are exposeable for the whole display.

dereine: Well, for these reason I asked to Earl if this feature should be implemented as a generic handler. Because handlers already has an API to expose handlers, we only need to implement a new kind of handlers.

But Earl said:

I don't believe this needs to be a handler. I think the display (and potentially the style) simply need to be able to be involved in the exposed form.

So, this patch doesn't implement this feature as a handler.

Also, I don't know how many other options can be exposed. Let say, filters, sorts, items per page, Is there another thing that can be exposed?

I thought you could bring the exposed stuff to class views_handler, so every subclass gets the feature too.

Also, I don't know how many other options can be exposed. Let say, filters, sorts, items per page, Is there another thing that can be exposed?

Some settings of a display:
Display Style, Row Style, Offset

subscribing

For a work around until this is implementated (this is a great feature )
View limit can be altered in (probably various places including) hook_views_pre_execute().
(http://foxis.intheclosets.com/text/changing-views-limit -- further explanation).

Now that the exposed form can be a plugin, let's integrate this with that.

Here is the patch working with pluggable exposed forms.

This patch introduces some foreach errors, we need to fix #633482: pre_execute is never called on exposed forms plugins before, to use this feature with Exposed Forms.

#633482: pre_execute is never called on exposed forms plugins Was commited. Here is the new patch.

Sorry previous patch displays all items if items per page in the exposed form is not defined. Here is a new patch.

subscribing

Received the below errors when patching:
//
**correction: mixed up the versions and patched v2. will be re-testing tonight with correct version

Patching version 6.x-3.x-dev was successful.

patching file views.module
Hunk #1 succeeded at 991 (offset -1 lines).
patching file plugins/views_plugin_display.inc
Hunk #2 succeeded at 131 (offset 7 lines).
Hunk #3 succeeded at 219 (offset 7 lines).
Hunk #4 succeeded at 292 (offset 7 lines).
Hunk #5 succeeded at 363 with fuzz 1 (offset -20 lines).
Hunk #6 succeeded at 808 (offset 7 lines).
Hunk #7 succeeded at 1044 (offset 7 lines).
Hunk #8 succeeded at 1651 (offset 9 lines).
Hunk #9 succeeded at 1748 (offset 9 lines).
patching file plugins/views_plugin_exposed_form.inc
Hunk #1 succeeded at 89 with fuzz 2 (offset 1 line).

However, received this fatal error once uploading patched module.
Fatal error: Call to undefined method view::render_exposed_form() in /home/example/public_html/drupal/sites/all/modules/views/plugins/views_plugin_display.inc on line 2179

Then applied patches provided at:
http://drupal.org/node/645150
http://drupal.org/node/639094

Worked great!

Checked 'Expose items per page' in views settings
Items per page: tested with different values and all good

Thanks for the great work!

**note: edited comment to remove personal username from fatal error message

@trupal218: Thanks for the test.

Since exposed plugin was committed to views 3, probably the best way to implement this feature is using exposed_form_alter() like #228510: Exposed Sorts does.

Here is a new patch. Also apply this patches:
#645150: Call to undefined method views_plugin_display_page::get_exposed_form_plugin()
#639094: Exposed Forms do not work?

This patch cannot be tested with #228510: Exposed Sorts because they are incompatibles. If this patch is commited before Exposed Sorts, we need to reroll the exposed sorts patch.

My testing results:

- all patching was successful
- checked 'Exposed items per page' in settings of Items per page
- tested with default 'Exposed items per page options:' and also changed numbers to 1, 2, 5 etc - worked perfectly!
- tested with use AJAX set to yes and no - worked great!
- testing was done on a vanilla drupal install as well as my test website

maybe several more people can test this patch and then status can be changed to RTBC?

Thanks for the great work dagmar!

Sadly pluggable pagers broke this patch.

items to display (or per page) is now totally owned by the pager. So this needs to move into the pager system, which should then have enough methods to be able to expose whatever it needs easily.

I must be reading #31 incorrectly. If not then the 'Items to display' link is just there to frustrate people.

If Items to display is now totally owned by the pager, what happens if you don't want a pager in a view?

I just use views from time to time, but do expect things to do what they say they are going to do.

If a view has:

$handler->override_option('items_per_page', 3);

How can it be spitting out more than 3 items?

There are 2 pagers that don't actually page. The "All items" pager which displays everything, and "Display some items" which displays a fixed number of items without paging.

The reason this is done is that some pagers might not show a fixed number of items per page, particularly if using some kind of grouping mechanism such as an alpha pager.

I will reroll this patch using pluggable pagers and exposed forms plugin.

Tagging, changing status.

To test this patch, you need to install this patch #652712: Pager settings are not stored too.

This patch allows users to set Items per page and Offset using an exposed form. It works with pluggable pagers and exposed forms.

I tryed out the patch it works fine. Here is a review of the code

+++ plugins/views_plugin_pager_full.inc	7 Dec 2009 21:13:37 -0000
@@ -19,7 +19,17 @@ class views_plugin_pager_full extends vi
+        'items_per_page_options' => array('default' => '10, 20, 30, 50, 100'),

I think 100 items are too much, i would like to have 5 or something like this as default.

+++ plugins/views_plugin_pager_full.inc	7 Dec 2009 21:13:37 -0000
@@ -19,7 +19,17 @@ class views_plugin_pager_full extends vi
+        

There are some minor whitespace problems.

+++ plugins/views_plugin_pager_full.inc	7 Dec 2009 21:13:37 -0000
@@ -47,6 +57,89 @@ class views_plugin_pager_full extends vi
+      form_set_error('pager_options][expose][items_per_page_options', t('Please insert a list of integer numeric values separated by colons: e.g: 10, 20, 50, 100'));

Cool. The validation worked here fine.

I'm on crack. Are you, too?

After this the patch would be fine for me. Awesome stuff, i guess there are some support issues which could be closed afterwards.

Thanks dereine, I removed white spaces, removed the 'export' => FALSE, (i don't know why it was here), and add 5 to items by default.

I would be nice if somebody can test how this work together with #268023: Limiting total number of items....

Hello dagmar,

Using views 6.x-3.x-dev, I tried to test this patch with others as you requested in #37

Installed 'Pager settings are not stored' patch @ http://drupal.org/node/652712#comment-2355652 [successful without errors]
Installed 'Limiting total number of items....' patch @ http://drupal.org/node/268023#comment-2368742 [successful without errors]

Then lastly, patched with #37 which resulted in below:

patching file plugins/views_plugin_display.inc
Hunk #1 succeeded at 118 (offset 9 lines).
patching file plugins/views_plugin_exposed_form.inc
patching file plugins/views_plugin_pager.inc
patching file plugins/views_plugin_pager_full.inc
Hunk #1 FAILED at 19.
Hunk #2 succeeded at 64 with fuzz 2 (offset 8 lines).
Hunk #3 succeeded at 190 (offset 16 lines).
1 out of 3 hunks FAILED -- saving rejects to file plugins/views_plugin_pager_full.inc.rej

The lines saved in the .rej is below:
***************
*** 19,25 ****
$options['items_per_page'] = array('default' => 10);
$options['offset'] = array('default' => 0);
$options['id'] = array('default' => 0);
-
return $options;
}

--- 19,34 ----
$options['items_per_page'] = array('default' => 10);
$options['offset'] = array('default' => 0);
$options['id'] = array('default' => 0);
+ $options['expose'] = array(
+ 'contains' => array(
+ 'items_per_page' => array('default' => FALSE, 'bool' => TRUE),
+ 'items_per_page_label' => array('default' => 'Items per page', 'translatable' => TRUE),
+ 'items_per_page_options' => array('default' => '5, 10, 20, 40, 60'),
+
+ 'offset' => array('default' => FALSE, 'bool' => TRUE),
+ 'offset_label' => array('default' => 'Offset', 'translatable' => TRUE),
+ ),
+ );
return $options;
}

Hope this helps to troubleshoot any issues. Thanks

Thanks trupal218 :

Only for testing purposes I have merged.

#268023: Limiting total number of items....
#324092: Expose: Items per page and Offset
#652712: Pager settings are not stored

Into a single patch.

Since, #268023: Limiting total number of items...., and #652712: Pager settings are not stored are marked as RBTC I think if this patch works as expected is safe to commit this three in one patch instead apply they one by one.

Sorry for the late feedback, but I did test last week with the combined patch provided above.

- Patching went smoothly
- I was able to use exposed item filter, change number of items in the settings, and have users choose their preference perfectly
- I was able to use Offset as well as Exposed Offset option

One thing I noticed which I won't be using but I would like to share from my testing:

If Pager Options=>Offset is set to 1 (for example) and administrator decides to allow Expose Offset option, users will first see the views result with offset of 1 as default. Users will also see a blank Exposed Offset field to enter in their preferred Offset value.
- If user enters 1 into the Exposed Offset field, nothing changes in the views result as the default is already set to 1 (looks good)
- If user enters 2 into Exposed Offset field, the offset will change to 2 (looks good)
- [situation where i am not sure if this is by design] If user enters 0 into Exposed Offset field, the views result is still Offset 1 and not 0 (as per administrator setting) My thought is this is so users cannot override the administrators setting?

dagmar: thanks again for combining the patches for testing! I will be following this thread for any additional testing needed in the future

Since #268023: Limiting total number of items.... and #652712: Pager settings are not stored were committed, this patch is is practically a re-roll.

I did some research and found the a solution for #666874: Exposed sort order by field needs some work I'm including this solution on this patch to avoid continuous re-rolls.

@trupal218, from #40: thanks, now we can accept 0 as offset, (even more, now this patch check positive numbers for items per page and offsets)

Doesn't we have theming for exposed filters?

So we could move

+    '#prefix' => '<div class="views-exposed-widget">',
+    '#suffix' => '</div>',

into the theming layer, or not?

Yes it is a nice option. The unique problem will be that overridden exposed-form templates will have to be update, but this is not so bad.

This patch implements the divs in the theme layer. I also have included a check to allow only valid offsets.

Ok, new patch. Now pagers can alter the exposed form, giving more flexibility and allowing pagers plugins to provide more interesting features.

+++ plugins/views_plugin_pager_full.inc	29 Dec 2009 20:16:25 -0000
@@ -136,4 +239,53 @@ class views_plugin_pager_full extends vi
+        form_set_error('offset', t('Offset must be an integer greather or equal than 0'));

I'm not sure whether this is understandable for the normal user. I suggest: "Offset must be a number greater or equal than 0.

Additional i would have a look whether intval() or (int) is the way to use.

afaik the only difference is that intval() is a function call, whereas (int) is an operator.

subscribing...

No, (int) will not actually necessarily convert it unless it's exact. intval() is safer.

merlin: What do you mean by that? The values should always be the same. intval() is not safer. Regarding floating point precision, intval() suffers from the exact same problems as the rest of PHP. Famous example:

intval( ( (0.1+0.7)*10 ));

will give you 7.

I'm generally thinking string to int, not float to int.

I have modified the form error as dereine suggested in #45.

I have tested this patch and seems to be working fine, in my opinion is ready to be in :)

Year. Patch looks fine for me.
Testing works perfect

taging

Committed to 6.x-3.x -- needs porting to D7 since pluggable pagers not there yet.

remove tag.

depense on http://drupal.org/node/586668

ported the patch. and the patch works fine.

any chance of back-porting this patch for views 2?

It's impossible, but you can try it. I can say you will fail.

Is there some alternative ways for views2?
Page_Preference module? but it's not maintained.

ehm, i can't found option to expose items to display in last views dev version!

I can't seem to put a weight value on it in hook_form_alter()....?

$form['items_per_page']['#weight'] = 300;

It always ends up somewhere in the middle of the form.

Ideas? :-)

Im having the same issue as #62

Anybody can fix the misspelling as well?
'greater' rather than 'greather'?

./plugins/views_plugin_pager_full.inc:347:        form_set_error('offset', t('Offset must be an number greather or equal than 0.'));

Thanks.

Is it possible to show a dropdown to select the items per page in views 7.x-3.3? Or do I need the dev-version for this feature?

Found my own answer, in the pager settings you have a checkbox "expose items per page" => nice!

Once a patch is in, in general it's better to file a new bug report instead of re-open the existing one unless the original one doesn't do what it's suppose to tmk.

.

At the bottom of the Pager settings, there is an "Exposed options" area.