How to reproduce - example (a)
1) Goto http://drupal.org/project/issues/search
2) Submit the search form
3) See the pager links at bottom. You'll see something like:
http://drupal.org/project/issues?page=1&states=1,8,13,14,2&form_zero=Array
Note &form_zero=Array, at the end.

How to reproduce - example (b)
1) Goto http://www.example.com/admin/logs
2) Submit the form on the top of the table (any filter)
3) See the pager links at bottom. You'll see something like:
http://www.example.com/admin/logs?edit=Array&op=Filter&page=1
Note edit=Array&op=Filter, at the end.

Why does it happen? Where's the problem?
I believe that those arguments are built in tablesort.inc. It seems that almost all items of items of the $_POST array are used to build them.

How to fix?
Good question. I'm not sure, heh. I believe it is required a deep understanding of the forms api here.

Comments

markus_petrux’s picture

markus_petrux commented

Yup!

s/items of items/items

chx’s picture

chx commented
Status: Active » Fixed

that's pre form API (and pre pager redo) stuff.

markus_petrux’s picture

markus_petrux commented
Status: Fixed » Active

Please, look at tablesort_get_querystring(). When a form is involved, it gets all POST variables to build the new query string for pager links, but it doesn't take into account if a POST element is an array. Which leads to this problem.

Also, in the case of admin/logs, the form variables do not need to be passed along requests. The purpose of that form is just to update session variables. Follow? The pager should ignore POST items in that case.

Sorry, it isn't fixed, IMO, the problem remains. It probably lies between the forms api and the pager.

markus_petrux’s picture

markus_petrux commented

Same issue provides a patch:
http://drupal.org/node/48834

jvandyk’s picture

jvandyk commented

Cannot reproduce example (b). But see explanation at 48834.

markus_petrux’s picture

markus_petrux commented

>> Cannot reproduce example (b)

Indeed. It seems something has changed in the way forms are processed. Now, after a POST all forms seem to end up on a redirection (ie. a request made via drupal_goto, aka header location) that produces a GET request that do not contain POST variables, only the original query string.

The problem will appear only if/when tablesort_get_querystring() deals with a POST request, which is something that seems to be quite impossible now.

The problem originally repored on the issue starter has been indirectly fixed, though a couple of questions remains:

1) may the code in tablesort_get_querystring() be simplied to deal only with GET vars?
2) should it be fixed to correctly deal with arrays passed by POST vars?

markus_petrux’s picture

markus_petrux commented

The fixed for 2) in my previous POST could the one posted by remi here:
http://drupal.org/node/48834

still, I think not all POST variables need to be passed across requests, so if anything has to be done to correctly deal with POST vars in tablesort_get_querystring(), it probably needs a method to tell which POST variables should be taken into account (or which should be ignored) to built the new query string.

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Closed (duplicate)

see http://drupal.org/node/5371. please reopen if this is not a dupe