When creating a new view to show content and filter on a taxonomy term from a dropdown, I get the following error:

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /littlestarcontest/admin/structure/views/ajax/config-item-extra/admin_0to3_year_contest/page/filter/tid
StatusText: Service unavailable (with message)
ResponseText: Error: [] operator not supported for strings in views_ui_regenerate_tab() (line 2399 of D:\xampp\htdocs\littlestarcontest\sites\all\modules\contrib\views\includes\admin.inc).

I am using Drupal 7.5.1

Any insights would be helpful. Thanks.

The relevant code where this is triggered:


poorva created an issue. See original summary.

poorva’s picture

does anybody having this issue..

joelpittet’s picture

Version: 7.x-3.14 » 7.x-3.x-dev
Priority: Critical » Major

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.

joelpittet’s picture

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()?

robertwb’s picture

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.

robertwb’s picture

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?

robertwb’s picture

Issue summary: View changes
joelpittet’s picture

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.

robertwb’s picture

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.

joelpittet’s picture

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

ridoo’s picture

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!

ridoo’s picture

@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?!


joelpittet’s picture

@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.

robertwb’s picture

Issue summary: View changes

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_...

ridoo’s picture

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.

ridoo’s picture

@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?

joelpittet’s picture

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: [meta] Pull requests in d.o. issue queues?

Thanks for the patch:)

Harsikesa’s picture

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.

iryston’s picture

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

DamienMcKenna’s picture

Status: Active » Needs review

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

TwoD’s picture

Status: Needs review » Reviewed & tested by the community

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.