Description: ------------ For some reason Structures_DataGrid renders header links (for sortable columns) incorrectly. I'm using DataGrid in a subpage which is shown when "subpage" parameter is added. The $dg->renderer->getPaging() method returns html footer that contains the parameter. For example: main.php?go=a&subpage=b&page=2 However, the header links for sorting the table do not contain the subpage parameter anymore, meaning the sorting doesn't work (link leads to elsewhere). main.php?go=a&page=1&orderBy=name&direction=ASC For some reason all my own parameters are stripped from these header links. It would work perfectly if the header links were created just like the footer links are. If I add extraVars to getPaging method, it still doesn't work in _headers_: $dg->renderer->getPaging('Sliding', '|', '<<', '>>', 5, array('extraVars' => array('subpage' => 'b'))); Adding $dg->setRequestPrefix("subpage=b&"); helps with sorting, but then the paging doesn't work and the url parameter count keeps on increasing... Is there any way of making the header (sorting) links work just like the footer (paging) links are currently working?

I found the bug... In DataGrid/Renderer/HTMLTable.php on line 356: } elseif (stristr($element, $this->_dg->requestPrefix . 'page') && That stristr seems to match all parameters with "page" in them. So, for now I've fixed this by changing my "subpage" to just "sub" and it works. I guess this needs to be fixed in HTMLTable.php?

I think you can use your "subpage" as before, if you give $this->_dg->requestPrefix a value (there should be a set...() method for this) like "myapp". Then $this->_dg->requestPrefix wouldn't be empty and the stristr won't match your own "subpage" parameter.

I tried setting the requestPrefix (with setRequestPrefix method, as mentioned in my first report), but it doesn't quite work. If I remember correctly, the prefix was added to every parameter and the count of those kept on increasing. At some point I had a dozen or so orderBy's etc. Also the paging stopped working after setting the prefix. By changing my "subpage" to plain "sub" everything works for me, but this is just getting around the problem, not fixing it.

Ups, sorry I did not see that you mentioned setRequestPrefix. But I think that this is wrong: $dg->setRequestPrefix("subpage=b&"); It should be: $dg->setRequestPrefix("sub"); Please try this and provide an example URL that SDG generates (in the case that this does not work).

Adding $dg->setRequestPrefix("subpage"); to another page fixed the sorting problem there. The paging seems to work too, so I guess this solves the problem in a way. Though I must say that I'll use the "sub" parameter without setting the prefix, because with requestPrefix set the url looks like this: main.php?go=reports&subpage=currencies&subpageorderBy=currency&subpagedirection=ASC I don't like that repeating subpage prefix, so I'll change "subpage" parameter everywhere to "sub" and get around the bug this way.

If you don't like having "subpage" in front of every SGD parameter, why don't you use instead $dg->setRequestPrefix("sub"); or $dg->setRequestPrefix("dg"); or $dg->setRequestPrefix(NAME_OF_YOUR_APP); or something like that? Please do not forget to close this bug, if your problem is solved. If you don't like the current behaviour, you should change the type to "feature request".

There is no reason to use the requestPrefix. This is a bug, "subpage" is not "page" and this stristr() test was bug prone. I've fixed this, now checking strictly for "page", "orderBy" and "direction". Can you please test the current CVS to see how it works for you ?

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.