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

Comments

fgm’s picture

Status: Active » Needs review
StatusFileSize
new810 bytes

Suggested patch. This does not seem to be tested anywhere.

merlinofchaos’s picture

Send $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.

fgm’s picture

Makes sense indeed.

chris matthews’s picture

Issue summary: View changes

The 5 year old patch to handlers.inc applied cleanly to the latest views 7.x-3.x-dev and if still applicable need review.

damienmckenna’s picture

Status: Needs review » Fixed
Parent issue: » #2960871: Plan for Views 7.x-3.23 release

Committed, with a small extra comment, because at the very least there is no $view at that part of the scope.

  • DamienMcKenna committed d0e5ea7 on 7.x-3.x authored by fgm
    Issue #2115213 by fgm, merlinofchaos: Incorrect $view parameter passed...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.