The $errors = $view->validate(); line in views_ajax() is causing the view to be constructed (at least in part) before the pre_view hook is called.
The specific case is when trying to set the value of an exposed date filter using hook_views_pre_view. The programatically set value works for the initial page load (non-ajax), but when using the ajax pager, the values do not get set due to date_api_filter_handler::init() being called before the pre_view hook. There are other date specific issues related to setting exposed filter values (#523224: Date API filter handler does not honor view::set_exposed_input()), but the validate() before the pre_view hook complicates the situation when using ajax views. Using the hack in the date-specific issue and commenting the validate call makes the view work as expected with ajax paging.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | views_ajax_934104-3.patch | 1.21 KB | hefox |
Comments
Comment #1
dawehnerThis seems to be somehow related to #837816: $view->add_item() doesn#t work in hook_views_pre_build(&$view) with Ajax
Comment #2
iamjon commentedtauno,
did you ever find a solution? if yes please update. if no please respond to dereine's comment.
closing from lack of activity. please feel free to reopen.
Comment #3
hefox commentedI've seen this many times and finally got annoyed off about it enough to look into it.
Validate does initialize a whole bunch of things before regular hooks, making stuff done within them useless. If doing stuff like adding a filter related to controlling access to something, bam, got a tiny security issue with your site :(.
As far as I can tell, all validate does is make sure the view is still (all plugins still exist, etc.). No one outside of admin screens uses it, and no one before executing the view (as far as I can tell). Don't see why ajax callback is using it, so here's a patch just removing it.
Comment #4
dawehnerSee also #1360336: views_ajax() can't find certain handlers for a similar issue which removed this validation for ajax.
You can totally agree that you don't need this kind of validation at that point. It is simply wrong.
This issue might be worth to be added to 6.x-3.x and 6.x-2.x as well, even i don't think that there will be release in the future.
Comment #5
dawehnerWow there hasn't been a 6.x-2.x commit for quite long time. Committed and pushed to 6.x-2.x