Method views_handler::options_form() ends with:
// Allow to alter the default values brought into the form.
drupal_alter('views_handler_options', $this->options, $view);
However, at this point $view is not defined, and hook implementations just receive a NULL. Changing the code like this appears to bring the expected functionality:
options_form implementation.
// Allow to alter the default values brought into the form.
drupal_alter('views_handler_options', $this->options, $this->view);
Child handlers classed tend to be affected too because most (all ?) of them invoke parent::options_form() from the own
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 0001-Issue-2115213-by-fgm-incorrect-parameter-in-hook_vie.patch | 804 bytes | fgm |
Comments
Comment #1
fgmSuggested patch. This does not seem to be tested anywhere.
Comment #2
merlinofchaos commentedSend $this instead of $view -- $this->view will get you the view *and* you can completely get the handler. And since right now it's always passing NULL, we know that no one can rely on the existing behavior to be meaningful. I don't really see this hook as being particularly useful without access to the whole handler.
Comment #3
fgmMakes sense indeed.
Comment #4
chris matthews commentedThe 5 year old patch to handlers.inc applied cleanly to the latest views 7.x-3.x-dev and if still applicable need review.
Comment #5
damienmckennaCommitted, with a small extra comment, because at the very least there is no
$viewat that part of the scope.