Call to a member function options_validate() on a non-object when adding a field

I have the same, and I could not fix this yet :-(

I have the same issue when saving a new field to a view involving message's.

*EDIT* Actually this occurs because the view was locked, although I never performed any action that indicated I was locking the view. If I unlock the view then it works fine. I think the reason for this is that none of the people mentioning the issue actually did any intentional locking and there is no error handling for this use case.

This got me too. In my case it's when adding a custom integer field as a sort to a EFQ Content View (built using the efq_views module).

I tried wrapping that line in "if (is_object($form_state['handler'])) { }" as a quick hack but that just broke things more. I'll debug ASAP.

Turns out that in my case, this was just because I was using a master/slave setup (using the autoslave module) and the slave was like 10 minutes behind the master due to a large migration I had running.

So since the slave was ONLY being used for SELECTs, views would add the field or filter to the view but then when it tried to get it back out to configure, it wouldn't be there, hence the error.

In my particular circumstance, this is happening when trying to add a sort to a view that is inheriting sorts from the default display. When it builds the form, the new field is an option on the default display ($this->default_display->get_option('sorts') returns my new sort), but after submitting the form, during validation, this new sort is NOT on the default display of the view. In turn, the handler is never added to $form_state. Digging in deeper now, but as with any Views bug, I'm never sure how deep this rabbit hole goes. :)

Bumping to major, since this is blocking the ability to add sorts to a View.

Hmm, oddly enough, after a bit of tinkering with this, an old Lock appeared on the view. Breaking the lock fixed the issue. I wonder if this was somehow a stale cache item that didn't get purged properly?

It's guilty, not quilty.

Got this problem too on Views 7.x-3.7:
Fatal error: Call to a member function options_validate() on a non-object in sites/all/modules/views/includes/admin.inc on line 4442

I have the same error when trying to add new filter in a view

can anyone help solve this pls?

Same error, adding a field with Representative Node relationship

Same here, after adding a flag relationship to a node, and trying to add a filter based on the flag value. Drupal 6.

Same problem here!

after delete a filter criteria.

Fatal error: Call to a member function options_validate() on a non-object in [mysite]/sites/all/modules/views/includes/admin.inc on line 4398
https://www.drupal.org/node/1761104

This happens because another user may be in the view editing page as the same time as you. Drupal is preventing the second person from editing the view while the first person is still making changes. If you look at the top of the view edit page where you are adding a new field or making changes , you should see a link that tells you which use is editing the view and a link to kick them out so you can make changes. You can accidentally run into this scenario when rolling down and importing databases. Meaning someone could have been in a view at the moment you rolled down the db.

I was facing the same issue when applying the sorting for the publish_date and category field in a web services (Drupal 7). There was 500 error when running the API in the postman.

It was working fine for title field sorting but not working for other's field sorting. For all other fields, there was 500 error. I checked the apache error logs and there was "Call to a member function render_fields() on null in sites/all/modules/services_views/includes/views/views_plugin_display_services.inc on line 45" while in watchdog report it was "Illegal choice publish_date in Sort by element.".

Tried many post but didn't find solution. Later on I found that if we apply the full value name like field_data_field_publish_date or field_data_field_category in the sort_by then it works well. So just check the same that you are using the correct key to map the field.

Hope this helps.

thanks.