Call to a member function validate() on a non-object views/includes/admin.inc on line 895

can you try to reproduce the error:
- Define a click-patch so this error appears.

This would really help to solve the problem

I can duplicate this on current DRUPAL-6--2 code. I was creating a new node view, added a sort on updated DESC, and added a NID field. Didn't change anything else and pressed 'Save'.

If I bypass the validate() call, I get Call to a member function save() on a non-object in /home/dave/Projects/www/drupal6dev/sites/all/modules/views/includes/admin.inc on line 915. So yeah, there is no View object in $form_state['view']. Major breakage.

@Dave Reid: I did exactly that you said in #2 and I cannot replicate this issue. Even more I'm using a fresh drupal installation with the lastest views 2.x dev package. When you say "added a sort on updated DESC" you want to say Node: Updated Date?

However I think that this can be indeed a complex bug. Months ago I was working in a module that try to find $form_state['view'] performing a hook_form_alter to the exposed form. When ajax was disabled all works fine, however when ajax was enabled I cannot got this value.

Turns out my problem was using form_controller. It's probably messing with some internal $form stuff, so I've confirmed that Views itself is not the problem.

Doing the following in hook_form_alter() or hook_form_FORM_ID_alter() is what caused it:

  if (!isset($form['#cache'])) {
    $form['#cache'] = TRUE;
  }

Actually, maybe this should go into includes/admin.inc? Maybe we could prevent more problems like this and not allow the form to be cached?

Um...holy crap. I think the includes/admin.inc must have had some kind of funky line endings. Trying to work on a smaller patch for a one line addition...

Here is a smaller patch

Working with form controller as well, I found this bug in views.
This patch fix the problem

Ditto, fixed the issue with form_controller

This is not a bug in Views.

Confirm the bug.
Moved to form_controller issue queue since it not a bug in Views.

Just going to through in my cents (whether they're 2 or not, too tired to count).

I've had another form's having problem and not working correctly due to form_controller.

The form was configure filter that had a wyswyg filter (http://drupal.org/project/wysiwyg_filter). Wyswyg filter added in a submid and validation handler; as far as I could tell neither was called. I evantually got it working via clearing cache and changing around with code, but as I could not reproduce it yet I couldn't figure out what caused it.

So, perhaps this should be combined with #653128: Be more selective about which forms get a 'control this form' link. and a way to identify what forms are
1) undesirable to configure (views preview form, views analyze form, etc.)
2) will bug out if altered/cached (or figure a way around the bugging out).

My guess is just adding the ability for blacklist forms would be annoying without a way to provide default blacklists; imagine having to black list all those views forms for every time it's enabled :(.

Shrug :>

This one just bit me too.

Count me in. It's also affecting path_auto. I disabled it, and everything went back to normal.

I fixed it by turning off the Form module. I'm using View 3 though.

EDIT: whoops, I thought this was the Views section. nevermind.

Surely, better than a blacklist would be a whitelist. ie. if a module wants to make a form(s) configurable, it notifies the form module which forms it want's to configure - by the implementation of some hook or something.

Hm, there should also be a way for people to enable for themselves via some understandable (ie not devolper centric) way.

For example, vertical tabs probably doesn't know all the forms that desire fieldset; however, it is bugging for some of the forms that have fieldsets, so it cannot base it's white list off of a form having fieldsets. However, a user may know form xxx is desirable for form module.

How I image it is 3 states
white list -- form controller
neautral -- unknow, ask
black list -- never

white list -- configure link (or icon) appears
neautral -- enable for form controller link
black list -- no configure link. (For example, do not want any link appearing all over views!).

The issue with doing a text area config form that it is probably not user friendly; ie they'd need to figure out the form id.

Also, 1 or 2 hooks, like hook_form_whitelist, hook_form_blacklist where modules can return what forms they want white listed.

I'm overthinking it though :>.

Please continue this discussion in #653128: Be more selective about which forms get a 'control this form' link..

I was unable to get this patch to work for me. I am using the form module, not form controller. Those who have had success with the one line patch above mention using form controller. Has anyone had luck with this patch or another using the form module?

@jayson: The patch is for views_ui.module, not form.module.

I tried this patch in the views module and it didn't work.

I'm also experiencing the same problem.

The general concisious is of the other thread is just enable/disable form module as needed until a better solution is figured out in #653128: Be more selective about which forms get a 'control this form' link.

I think this is pretty critical for form, as it breaks major setups.

I agree. Needs to be addressed.

steinmb@#12 I’m not using form controller or form and the issue is showing on my site.

I'm having the same error
Fatal error: Call to a member function validate() on a non-object in .../modules/views/includes/admin.inc

adding
if (!isset($form['#cache'])) {
$form['#cache'] = TRUE;
}

didn't help ... only once!
I have the problem with cache all around the web. Where is the problem?
Does anybody know?

Problem came from the flashvideo in my case => #909224: Flashvideo is breaking Views.