Ajax http 500 error using taxonomy to filter view

I'm getting this as well. It will still add the filter and you can edit it, so I'm demoting to major but still yeah it's annoying. Hopefully I can find the cause and write a patch.

Couldn't figure out how to deal with the switch between rendered string output and ajax commands in views_ui_regenerate_tab().... got stuck, $js = TRUE still, maybe set the output with = views_ajax_command_set_form()?

Hey @joelpittet - I get this error as well, though not using taxonomy terms. The error occurs for me when adding new fields to views that have aggregate=TRUE, after selecting the aggregate function and pressing "Apply and Continue". This has begun recently for me, and I am wondering if there are some patches that I've applied that have caused this. Would be interested in comparing notes.

Hey @joelpitet and @poorva - are you guys running on PHP 7 by any chance? I just upgraded to 7 and am wondering if this has to do with something that was OK in the past, but no longer allowed in 7?

I think for this I was running PHP7 but I don't believe that is the root cause. The code switches between AJAX and non-AJAX and tries to attach ajax commands to rendered output which is already a string when it tries.

Thank @joelpittet - you may be right, but for my case, I just migrated a system completely -- that is, I copied all of my drupal dirs to a new front end server with php7 but kept the same backend DB -- and I don't know that I modified anything else, and this error began. I surely may have missed something, but I thought I'd put it out there.

It would be worth a bit to rule that out. If you can get an older version to run the code against and see.

I am facing that problem too (when trying to setup taxonomy filter using taxonomy_entity_index module). However, in case I can give you more infos you need to fix this issue, please let me know!

@joelpittet: I was wondering why views_ajax_form_wrapper() returns either an array of render commands (in case of a form didn't execute while using ajax) or an already rendered string (otherwise). This seems to me inconsistent, as two different return types might lead to unexpected side effects (I think we are discussing one of them right now).

I grep'ed and found out that views_ajax_form_wrapper() (in ajax.inc) is only called from views_ui_ajax_form() (in admin.inc) which passes the result to views_ui_regenerate_tab() expecting $output always to be an array!

I am quite new to Drupal, so I am not sure if views_ajax_form_wrapper() could be part of a public API and such behaviour is expected and could not be changed. However, in case it is not, what about always returning an array of rendering commands?!

Thoughts?

@ridoo We may be able to return an array always which could resolve this. Let's not worry about the API if it's busted at this point, we can let the maintainers decide that part.

I was attempting something like this, but the ajax api confuses me still, it's trying to return commands as an array but not sure what to do with the rendered string and how to deal with it... feel free to play around with it and propose an patch.

Added link to D8 version of function since backporting is generally the swiftest path to review by maintainers for a D7 issue. http://www.drupalcontrib.org/api/drupal/drupal%21core%21modules%21views_...

had a second (and third look to be honest .. ). As confusing views_ui_ajax_form() and views_ajax_form_wrapper() might be, I think the actual error is in the following lines of views_ui_ajax_form() (patch preferres 1):

  $stack = $view->stack;
  $top = array_shift($stack);
  $top[0] = $js;
  $form_state = call_user_func_array('views_ui_build_form_state', $top);

Here, views_ui_build_form_state() expects $view parameter to be a reference. Could either re-set view in the array as reference (proposal 1) or pass the exploded array in a direct call (proposal 2):

  $top = array_shift($stack);
  $top[0] = $js;
//  $top[2] = &$top[2];  // proposal (1)
//  $form_state = call_user_func_array('views_ui_build_form_state', $top); // proposal (1)
  $form_state = views_ui_build_form_state($top[0], $top[1], $top[2], $top[3], $top[4]); // proposal (2) 

This however, does not clean up the whole ajax stuff, but to be honest I didn't understood everything to be sure to not break more than fixing. I hope my patch leaves alone the that stuff.

@joelpittet: aren't patches a bit old school? Is there a way to provide pull requests? I read Drupal's git FAQ where it is mentioned that "They don't exist yet, but may well be the most-desired feature currently being discussed". Is there any news about that?

OT: Patches are old school in one way but handy to know regardless. Even github.com's pull requests can be turned into patches, so there is still a need out there for patches, though yes it would be nice to have pull requests too and people are working on it. Follow this issue if you want to help out there: #2205815: Merge requests in Drupal.org issue queues?

Thanks for the patch:)

Hi, I also having the same problem, but when I enable the List field module then I finally can edit the filter (Has taxonomy term) using autocomplete.

Hope this help.

I had that problem too after switch on PHP7 environment.
# 15 fix the problem.
Testing patch on PHP5 also works fine.
Ready for RTBC.
Thanks, @ridoo

Thanks for the patch. Don't forget to set the issue to "Needs review" when you upload a patch.

I can confirm #15 fixes the issue for us too (PHP 7 as well).
We don't have it on taxonomy forms though, just a regular node view and some relationships to other nodes.
The error used to pop up every time I added a field, but with this patch it's gone.

+++ b/includes/admin.inc
@@ -2946,6 +2946,7 @@ function views_ui_ajax_form($js, $key, $view, $display_id = '') {
+      $top[2] = &$top[2]; // https://www.drupal.org/node/2823977

This comment needs to be changed to correspond to Drupal code standards.

This change actually fixes the issue and not only this issue. There is also at least one #2810431: Parameter 3 to views_ui_build_form_state() expected to be a reference, value given in views_ui_ajax_form(). I prefer approach from the referenced issue to this one but will probably leave the decision to the community/maintainers around how to manage this situation.

Changed comment to comply with code standard.

I can confirm #23 fixes the issue.

Just out of interest, would you mind testing #2767167-9: AJAX "Fatal error: [] operator not supported for strings" when adding fields to new display with aggregation enabled and let me know if that solves the problem too. Thanks.

#23 worked for me

i can confirm that patch in #23 works for me too.

I use VIEWS 7.x-3.20.

Thanks @RoSk0

It turns out this is identical to #2810431: Parameter 3 to views_ui_build_form_state() expected to be a reference, value given in views_ui_ajax_form(), but I've credited you all anyway. Thanks!