exposed pager "Remember the last selection" - making work in 6.x

Works great, code looks good. However, it should only be shown when either the offset or items per page are exposed.
Can you add a #dependency for that?

So that happens with the replacement patterns in handlers, so maybe we shouldn't worry about it here?

+++ b/plugins/views_plugin_pager_full.incundefined
@@ -112,6 +115,15 @@ class views_plugin_pager_full extends views_plugin_pager {
+      '#title' => t('Remember the last selection'),

.

+++ b/plugins/views_plugin_pager_full.incundefined
@@ -147,6 +159,16 @@ class views_plugin_pager_full extends views_plugin_pager {
+      '#title' => t('Remember the last selection'),

If not, now these strings need to be differentiated.

Can you reroll that as not two commits? That way you can get commit credit.

Looking good, some last minute nitpicks, and then I think its ready.

+++ b/plugins/views_plugin_pager_full.incundefined
@@ -83,6 +85,7 @@ class views_plugin_pager_full extends views_plugin_pager {
+

Extra line

+++ b/plugins/views_plugin_pager_full.incundefined
@@ -353,4 +379,64 @@ class views_plugin_pager_full extends views_plugin_pager {
+  function exposed_form_submit(&$form, &$form_state, &$exclude) {

Could use a docblock

+++ b/plugins/views_plugin_pager_full.incundefined
@@ -353,4 +379,64 @@ class views_plugin_pager_full extends views_plugin_pager {
+   * Check to see if input from the exposed pager should change
+   * the behavior of this pager.

Should start with a plural verb, like "Checks". Also, this needs to be a single line, under 80 chars.

+++ b/plugins/views_plugin_pager_full.incundefined
@@ -353,4 +379,64 @@ class views_plugin_pager_full extends views_plugin_pager {
+   * Saves input from the exposed pager to the session that will
+   * change the behavior of this pager.

This needs to be a single line, under 80 chars.

+++ b/plugins/views_plugin_pager_full.incundefined
@@ -353,4 +379,64 @@ class views_plugin_pager_full extends views_plugin_pager {
+   * Saves input from the exposed pager to the session that will
+   * change the behavior of this pager.

This needs to be a single line, under 80 chars.

The store_exposed_input and get_exposed_input look very very similar, except one has checks in $_SESSION and the other has method calls.

Furthermore, store_exposed_input is a method used by handlers, not other plugins, and this one is only called by exposed_form_submit. Why not combine them?

Also, the comment on get_exposed_input should probably be something more like Allows input from the exposed pager to change the behavior of the pager. The first line of method/function docs have to be under 80 characters.

Actually, I've gone ahead and rolled a patch. In the future, please don't use format-patch, it makes it very difficult for a human to parse.

This causes an anonymous session to be set by simply viewing the view display. Do we need to use anonymous sessions for this? This will likely cause breakage with things like varnish that will not work if there is an anonymous session. Could using a cooke instead avoid that? If we really do need the anonymous session, then it should at least only be set if the user has overridden the default value.

This will not work for anyone running a cluster of servers. We have two application servers The users are not forced to either server. One request could go to server a and the next one could go to server b. If they switched servers the $_SESSION variables would not be set. I think using $_COOKIE would avoid this problem.

Not work for me.

We had issues with varnish cache when the views exposed filters are set to remember selection.
Since that option is setting values in session, the varnish cache is not serving pages from cache after that page with exposed filter is visited.
I tried this patch, and it kind of works. The problem is, the cookie works fine when I am on that page. But if I navigate to other pages and come back to this page(with the exposed filters), the cookie value is empty and all my selections are lost.

New features should be backed up with a test.

Any way to get around the cookie issue with the views exposed filters? I'm trying to figure out why Varnish isn't working and thought this might possibly be it. Will setting a cookie resolve this issue?

Hi, I have made a simple module to get the pager remember user options.
Just save the items_per_page variable in $_SESSION and set items_per_page if the option was setted by user.

enjoy,
dropfen

Thanks for posting that module, dropfen - it works! Really helped me out of a bind I was in.

great, thank you for using ;)

Adding some comments to this issue.

@jucallme - Your patch works fine, assuming that all of the modules that inherit or try and read from the $_SESSION variable can edit their code to not read from $_SESSION. I just ran into this today with the date module which reads from $_SESSION for default values.

@mrfelton - is the goal to move everything in views out $_SESSION for exposed filters? If so, that to me is a different issue then the one at hand, which is that we can't remember the items per page filter. If you feel differently let me know.

I'm happy to work on an updated patch but want to know the direction here. Thanks.

@dropfen - Thanks for the module!

I've modified it slightly so that the page number of a view is remembered - stored in $_SESSION - and then reset when the view is reset.

@micnap nice,
maybe a settings option in views were cool to turn it on/off only on special views.

@dropfen - ideally, yes. But I'm just using the module until this issue has a solid solution.

This module works well and solves a problem for me. It would be good to see it rounded off.

Based on the modules that dropfen and micnap have provided, I've added the ability to remember the user's last selection and reset to the default if the reset button is clicked (thank you!). However, I'm seeing some odd behavior when the "All" option is selected for "Items per page".

When "All" is selected, the value is successfully saved and the drop down is pre-populated as expected, but there are no results. If you click the "Apply" button, I get the expected the results.

This is not happening when any of the numeric values are selected.

I'm trying to compare the queries being generated in the two cases, but I'm running into an "allowed memory size ... exhausted" error when trying to expose the from within one of the Views 3 hooks.

Ran into an issue with paging where if a person was on page x of the results and the exposed form was resubmitted and the results were less than x pages, you couldn't navigate to the other pages. I moved the resetting of the items in the $_SESSION object to the submit handler to correct this. It also corrects the issue from #35.

I'm using this version on 6.x-2.16. I had to remove $form_id from the "views_ripp_form_views_exposed_form_alter" line near the top:

Was:

 */
function views_ripp_form_views_exposed_form_alter(&$form, &$form_state, $form_id){
  global $_SESSION;

Now:

 */
function views_ripp_form_views_exposed_form_alter(&$form, &$form_state){
  global $_SESSION;

The version corrected to fix the "all" issue doesn't work on 6. I may look into what's causing the breakage, but I'm not really versed in the inner secrets of Drupal or php.

Just in case someone out there needs this in 6.x, like I do.

Thanks for the module!

@micnap Forgive my ignorance when it comes to sessions, but I've installed your module from #36 (in a D7 install) and it doesn't seem to work on https pages. Is this expected behavior? If so, does anybody have ideas for a workaround? Thanks.

Edit: Forgot to mention that on returning to the page, the pager is corectly populated with the "remembered" value, it just doesn't seem to be submitted.

Very interested in this. Would love to have pagers remember last selection. This doesnt seem to be resolved, doest anyone have a true working solution?

Do you solve this problem in D7?

[For people still working with D6]

There is a logical error in the patch (views-1482424-24.patch) in the function query() in views_plugin_pager_full.inc.

• The call $this->get_exposed_input(); gets data from the cookie.
• The reference to $_GET gets data from the URL.
• As it stands $this->get_exposed_input(); overwrites the data from the URL.

The solution is simply to move $this->get_exposed_input(); before the $_GET, so that the URL overwrites whatever is in the cookie.

Hi, solution in #36 works great for views WITHOUT Ajax enabled. Is there an equivalent solution for views with Ajax on?

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