1

A view is embedded in a page template via this code. It's AJAX enabled and uses exposed filters which I have to mess around with for business purposes :

$view = views_get_view('rechercher', $reset);
$view->set_display('default');
$view->set_use_ajax(TRUE);

$set_exposed_input  = array();
if (isset($_GET['commune'])) {
  $set_exposed_input['field_commune_value'] = filter_xss($_GET['commune']);                
}
if (arg(1) == 646 && ! isset($_GET['raz'])) {
  $set_exposed_input['field_type_vente_value'] = 'LOCA';
} elseif (arg(1) == 645 &&  ! isset($_GET['raz'])) {
  $set_exposed_input['field_type_vente_value'] = 'VENT';
}
if ($set_exposed_input) {
  $view->set_exposed_input($set_exposed_input);
}
$view->execute();
print $view->render();

It works perfectly.

Now the query must be altered via hook_query_alter :

function my_module_views_query_alter(&$view, &$query) {

  // Unrelevant stuff here

  if ($view->name == 'rechercher') {
    $view->query->add_table('field_data_field_cp');    
    $view->query->add_where(1, 'field_data_field_cp.field_cp_value', '%' . $_SESSION['filtres']['field_commune_value'] . '%', 'LIKE');    
  }

As soon as I uncomment this code, I have to submit the view twice to have the results refreshed.

Except for this, the view behaves as expected (query returns the right data, etc.).

I guess it's some kind of cache and/or form caching issue but can't figure what exactly.

Any help would be appreciated.

EDIT : Some more details

Please forget AJAX : it has nothing to do with it, as the behaviour is exactly the same without it.

One more info : the query is correctly altered on the first filters form submission. Dumping proves it.

So it boils down to something that happens AFTER query altering. The mistery remains as to what and when.

|improve this question
  • Try moving the code out of the template file and into a theme preprocess function in a module...setting up forms (which calling $view->execute() would do on your behalf) in template files sometimes causes problems of a 'delayed reaction' nature. – Clive♦ May 26 '12 at 15:41
  • I did put the first block of code in my_module_preprocess_page, adapting some parts of it to its new context, and it works exactly as before : still have to submit twice :-(. – Countzero May 29 '12 at 6:53
  • I narrowed it down a bit : it seems AJAX is not at fault here : deactivating it leads ti the same behaviour, so it must be something with embedding. Still in need of help. – Countzero May 29 '12 at 8:25
  • Is it possible that the filter part of views also implements a query alter hook, and is being run after your hook, thus overwriting the changes you've made? It's a long shot but probably worth checking. Change the weight of your module to something high in the system table, clear the caches, and see if it makes a difference – Clive♦ May 29 '12 at 8:38
  • Agree it was worth checking, but I already updated the system table to make my module 1000, which places it on top. – Countzero May 29 '12 at 9:06
1

It was some kind of mess with the $_SESSION variable, which I used for independant reasons.

I corrected my code this way :

  if ($view->name == 'rechercher') {
    $view->query->add_table('field_data_field_cp');    

// Old code
// $view->query->add_where(1, 'field_data_field_cp.field_cp_value', '%' . 
// $_SESSION['filtres']['field_commune_value'] . '%', 'LIKE');

// New code
    $view->query->add_where(1, 'field_data_field_cp.field_cp_value', '%' . $view->exposed_data['field_commune_value'] . '%', 'LIKE');    
  }

... and everything seems to be fine, AJAX and all.

Thanks to Clive for the help.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.