AJAX WSOD when adding empty Relationship

Folks,

I am curious as to the status of this bug. It's pretty-much a show-stopper for me.

Thanks,

You know all people which had this issue in d7 had some kind of php error in the background.

So please enable the display and logging of php errors and have a look what's in there... http://drupal.org/node/158043 is also a page you should definitive read and understand.

If you want to trick everything else disable javascript in your browser and all will be fine.

Thank you. The page is not throwing any PHP errors. Turning off Javascript enables me to get to the Add Relationship page, but the page does not let me actually define a Relationship; it simply returns to the Views page.

With Javascript enabled, there is an AJAX POST (op = Add and configure relationships) and the JSON that is returned contains 6 objects with these commands:

1. settings
2. viewsDismissForm
3. viewsShowButtons
4. viewsTriggerPreview
5. insert (method=html)
6. insert (method=replaceWith)

Javascript does not throw any errors. But the commands in the returned JSON are obviously not being executed.

Additional notes:
Interestingly, when the Add Relationship popup is shown there is a Javascript error thrown on line 350 of views-admin.js:

  search = this.$searchBox.val().toLowerCase();  // this line throws an error
  words = search.split(' ');
  wordsLength = words.length;

I changed it to this:

  try
  {
     search = this.$searchBox.val().toLowerCase();
     words = search.split(' ');
     wordsLength = words.length;
  }
  catch(err)
  {
     words = new Array();
     wordsLength = 0;
  }

While this solved the WSOD, I am simply displayed a message: "There are no relationships available to add" and I cannot add any. But this is getting closer.

Thanks in advance for any suggestions as to where to look next.

/Joel

In my case enabling or diabling javasript has no influence at all , I stil got the same WSOD
Turned on logging and error and see no php errors appearing ?
in an other Issue they mentioned the logging of Devel is the cause , but neither this is the case .

How can I continue ? I' m stuck.

In my case the root cause was that I was creating a View on an Entity that had incompletely defined metadata. Specifically, some elements in the array returned by HOOK_entity_property_info() did not have the correct "type" set.

However, in keeping with the idea of practicing safe programming, I suggest that the code I added (above) be implemented.

@godfriedv: your seems like a legitimate WSOD issue that you need to resolve outside of views. This is a symptom not the cause. Please check your php error log for more information and post it back if you dont find a solution.

@jfinkel: your post in #5 explains the real issue the best but your fix just swallows the error in an exception. After reading through the ajax response im convinced that it is the contents of the main view edit screen not the add relationship dialog that is being sent across. This explains the bounceback behavior you described with JS disabled (and i experienced as well.)

I think that the menu path (plus arguments) that is supposed to be defined for this dialog is missing but i dont know what provided it or where to find it. Ive honestly never seen this "Add relationships screen" and just need it to define a relationship between an LDAP field and the base node table. (hopefully it provides that :).

Ill try and chase it down in the views forms and see what it is attempting to redirect to.

@ earl or tim: do you have an example of this dialog working in a clean install so i can see the expected operation and debug it that way?

I too had this problem - my problem was that I had created a View based on a custom entity. I then tried to make a relationship between 2 custom entities within Views (7.x.3.5), but I hadn't established a relationship between those entities outside of Views -- this was the problem!

I installed the Entity Reference module (http://drupal.org/project/entityreference), and added an 'Entity Reference' field to a bundle in one of my custom entities. This field referenced another field in bundle within a different custom entity. Once that reference field was added, when I clicked on the Add Relationships button, that relationship was a choice in the Add Relationships dialog - no more WSOD!

Diagnosis:
* There's a JavaScript error because we're lowercasing an undefined value.
* This occurs because we are attempting to get the value of a form element that does not exist (jQuery set of 0 elements).
* This occurs because we do not validate that a search field exists before apply logic to the search field.
* Which, in turn, is because we assume that Views Add Item Forms will always have an Edit Options Search input field.
* This assumption can be violated when AJAX calls return 0 results.

There are several refactoring ways to fix this. They're probably good solutions, but might break something else :(

So, I went the minimalistic route, and kept type-safety, so the code moves forward without error.

That did the trick for me thanks @robcolburn

We've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.

If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.

We apologize for the trouble, and appreciate your patience.

Re-uploading previously RTBC'd patch from #10 for testing.

Thanks!

Let's confirm that this issue actually also applies to core.

Also, in general, we should consider filing separate issues in the core queue and ideally fix the core issue first; otherwise there is an implict regression when migrating from D7 to D8. See #2462101: [policy, no patch] Update backport policy to account for 8.x minor versions and 7.x divergence for how we plan to update the backport policy in core to include separate issues for D7 and D8.

I have created a new issue for this against D9 to confirm whether the bug exists there, but it was fixed in 7 so marking this ticket Fixed.

Have transferred contributors over to #3154992: Verify whether we can improve Views' search transparency for other code errors for credit.