Currently the pager plugin uses $_GET for exposed pager, in fact the exposed_form $form_state should be used here.

CommentFileSizeAuthor
#4 1404550.patch15.39 KBdawehner
#3 exposed.txt3.76 KBdawehner
#2 1404550.patch1.83 KBdawehner

Comments

merlinofchaos’s picture

merlinofchaos commented

The pager isn't always part of the exposed form so that's not entirely true.

dawehner’s picture

dawehner
Primary language German
commented
StatusFileSize
new 1404550.patch1.83 KB

The best thing about this fix, views already provides a better way: "exposed_form_submit".

    if (isset($form_state['pager_plugin'])) {
      $form_state['pager_plugin']->exposed_form_submit($form, $form_state, $exclude);
      $exclude[] = 'pager_plugin';
    }

What i don't understand: why is the pager plugin stored as part of the form_state.

This patch currently sets $this->options but it get's overridden later.

dawehner’s picture

dawehner
Primary language German
commented
StatusFileSize
new exposed.txt3.76 KB

Here is a view to allow fast reproducing.

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Needs review
StatusFileSize
new 1404550.patch15.39 KB

This patch works, though the test does not yet.

Writing tests often means to fix the test not the code, even this seems to be bad behavior.

Blooniverse’s picture

Blooniverse commented

... this is not a direct reply to any of the comments above or the original posting. This is a general thought, which to me -- as a 'non Viewer' and without the time to look more thoroughly into the whole thing -- seems to be associated with this issue. You can obviously proof me wrong, should I err.

  • 1stly, I didn't believe my tired eyes when I realized that a pager (mini and full) of a View doesn't work intuitively in combination with an exposed filter (date field). The pager always starts its counting at the first query record/row instead of the accurate time a particular date of the exposed filter was chosen. That is, so far, for me understandable because it seems almost impossible to have a pager such intelligent to recognize 'the current state of affairs'. Nonetheless, this behavior seems to be non-intuitive.
  • 2ndly, Gosh, I am really tired, need a few days off! Okay, however, 2ndly ... when I combine a pager 'paged by date' (including a corresponding contextual filter/argument, the mentioned date field) with an exposed filter (date field), this kind of pager also doesn't work -- as I perceive it -- correctly: Instead of picking up the date of the exposed filter the pager seems to make use of the original start value of this date field [respectively the non-user-modified & original starting value of the filter. If at least it took the default value defined in the contextual filter/argument settings ... but not even that it does.
  • Well, I seem to remember a similar discussion years ago, but this time it really struck me. I had a very brief glimpse at Views' pager files -- and somehow I came to think about $_GET or not to $_GET. That's why I've stranded here.
  • I wouldn't have a problem with coding my whole task manually (for some 'insane reason' I am usually even faster when coding things manually), but in this case I am supposed to work with exactly this existing view. It seems to me that, nevertheless, there is no way around altering the form and/or the view via an own module (see above, e.g.: $form_state['pager_plugin']). Even 'Views PHP' doesn't bring me forward here since it cannot influence the pager at all.

Yes, might your brain be blessed after reading this novel ... but I am too tired to formulate things in a more appropriate manner, I am verrry sorrry! Anyhow, should you need to know something specific, just let me know. Good night.

dawehner’s picture

dawehner
Primary language German
commented

First point: This works as you expect: if you click submit the pager is changed as well: see http://drupal.org/project/issues/views for example

Second point: you need more sleep :)
This seems similar to the first point

4 point: You can write your own pager plugin which can control nearly everything the pager. There is for example a php only pager out there.

Btw: I'm really not sure what this comment had to do with this issue.

Blooniverse’s picture

Blooniverse commented

... thanks, @dereine#6! Maybe I'm really gone now, but at the moment I could nevertheless swear that this is a real issue and therefore I have issued a separate bug report on http://drupal.org/node/1433518. There, in its screen capture, the two things (exposed filter and pager) don't work together properly.

Well, about posting the comment here: my intuition told me so. There is still this $_GET in my head. But if you cannot associate any of my data with this issue, then I will probably have to buy you a beer during one of the coming camps or cons ... or, even healthier, an organic orange juice. ;D

[EDIT::add] A HUGE PUBLIC SORRY FOR MY MISLEADING TWO COMMENTS HERE! It was the 'DATE' module, 200 per cent. See updated http://drupal.org/node/1433518 ! So, f*/$, yes it was a $_GET thing, but not in relation to Views! Sooooorrrry.

Blooniverse’s picture

Blooniverse commented

@dereine#4: I would have tested your patch in favour of your kindness to cure my tiredness, yesterday. But I don't know which dev version I should apply the patch against -- in the meantime (since end of January) there are so many new Views versions out there ... making a guess doesn't make a lot of sense!

dawehner’s picture

dawehner
Primary language German
commented

Well you see this information called version, so choose the 7.x-3.x-dev and try it out there. Really simple, you seem to overcomplicate things quite easy.

Blooniverse’s picture

Blooniverse commented

Your patch works on/with my test site, a Drupal 7.9 installation with ~40 contrib and one custom module. My test view (works with a lot of fields and exposed filters in combination with the contrib module 'Better Exposed Filters') behaves just as it did before! Congratulations, your huge chunk of work seems to be okay.

I git-cloned 'Views 7.x-3.x-dev', then I did a regular git apply -- even though I find it awkward, frankly said, to proceed in this manner since it creates a certain uncertainty about whether the file/files & the patch fit! Feels a bit like gambling. Is there no preciser method? Or at list there should be a [human readable] version information in the patch file, not this index 6c7b096..53b865e 100644 in the head of the file. I don't even know what this means!

Anyhow, there is still a GET query string with all kinds of arguments respectively variables/key-value-pairs, btw!

Blooniverse’s picture

Blooniverse commented
Status: Needs review » Reviewed & tested by the community

... should I, dare I, may I?

dawehner’s picture

dawehner
Primary language German
commented
Status: Reviewed & tested by the community » Needs work

Thanks for testing the issue!

In general as you might noticed it, nothing to the end user changed, just the internal behavior of the code.

Though

This patch works, though the test does not yet.

the tests are a blocker.

Blooniverse’s picture

Blooniverse commented

... I have to admit that I didn't have enough time the last ~10months to intensely/deeply focus on things like Git or testing. If there is anything to do like testing and/or writing a 'Simple Test' test (http://drupal.org/project/simpletest), let me [respectively us] know!

I am also not too familiar yet with Drupal's Quality Assurance http://qa.drupal.org -- although I became a module co-maintainer ~12 months ago, I haven't had one minute so far to really participate. I would also like to contribute one of my lonely modules/concepts on my dev env, but same situation here! Since years I am hoping that I will have more time for such things ... and probably in about 1-2 months it might even happen, finally. Hola, again a whole text book ;)