Jump to:
| Project: | Chaos tool suite (ctools) |
| Version: | 7.x-1.x-dev |
| Component: | Views Content |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
If a view uses ajax, and user can able to change Items per page value + pager exits, the pager won't work as well, if 'items per page' has different value, than the original view's pager option.
To reproduce: Create a view pane, Set pager to 'Paged output, full pager', and set 'Items to display' on views pager settings form to 10. On pane configuration let the 'Allow settings' check 'Items per page'.
Then add a new pane, and set 'Item per page' on pane input form to 1.
On page load, the 1 item will show up with pager. Then use pager, the result will be 10 item, as in the original view was set up.
This is, because the ajax callback of views just load the default view settings, and give back $this->preview() as result. No chance to add the pane's own parameters.
I'm not sure how do we need to handle this.. I tried to extend the preview() in views_content_plugin_display_panel_pane.inc, but I didn't get any relevant information from exisiting variables. The one of my idea to pass number of items by url, but I'm not sure, this is the best way (I think, we could have other pane settings, which would be lost)
Comments
#1
This is a known, unfixable issue, and there is warning text in the pane settings that addresses this.
Well, okay, I just went and looked; that warning text actually doesn't appear due to D6 -> D7 upgrade changes that got missed. Go figure. I'll have to fix that.
#2
Hi,
all i can say is that none of the allowed settings (pager element, offset, items per page, etc.) actually work with ajax. I see that in views module : includes/ajax.inc that is a line :
$view->display[$display_id]->handler->set_option('pager_element', $pager_element);
that should set he pager element but it has 0 influence on the result.
The easiest step to reproduce :
create test page , create test view with content , add content page display , set it to ajax , allow page settings to be set in the panel and set the pager element to be 0 and items per page to be 2 (for the test) , attach the view pane in the panel and set page element to be 1 and items per page to be 1. Add 5 nodes so we have some content.
Now when you open the page /test (or whatever is the url) that we will see 1 node with pager as expected and the linkst are correct page=0,1 or page=0,2 etc.
But when you click any of the pager it just reloads 2 nodes and loads the first page not the one you selected and when you check the pager links they are page=1,1 or page = 2,1 etc. So the pager handler has 0 clue of the settings that were posted trough ajax.
I will try to dig more into it this days and hope to find solution as I need to for one of my projects but I can't promise how far I will go and if the client won't just accept to reload the page as then the listings are working correctly.
Kind Regards
#3
Hi,
a few more lines i can add to this but all are connected with view module.
Instead of :
$view->display[$display_id]->handler->set_option('pager_element', $pager_element);you should use the pager array options :
$options = $view->display[$display_id]->handler->get_option('pager');and then setup the ones posted from ajax :
$options['options']['id'] = $pager_element;$options['options']['items_per_page'] = $items_per_page;
$options = $view->display[$display_id]->handler->set_option('pager', $options);
then we will have to add :
$items_per_page = isset($_REQUEST['items_per_page']) ? intval($_REQUEST['items_per_page']) : NULL;and in theme/theme.inc in the template_preprocess_views_view function in the ajax settings we will have to add :
'items_per_page' => isset($view->query->pager) ? $view->query->pager->get_items_per_page() : 0,Probably adding a function to the plugin display base class might look cleaner approach in order to handle this situation but that should also require to use array for pager settings in the ajax so other modules could add settings that would need but i guess that would require too much change in the views module.
I think that this could be related more to the views module to provide either option so other modules could add their own javascript settings and also to process them but again that is too much to ask. I am not that good to write such patch for the views module to provide such extendibility but the above changes does work quite well for me so i will commit a patch soon.
Kind Regards