Error: http://mysite.org/admin/build/views/ajax/add-item/comm_sites/default/field. [#682778]

While creating a new view, I receive the error message:

An error occurred at http://mysite.org/admin/build/views/ajax/add-item/comm_sites/default/field.

where the word after default/ is basically any of the functions involved in adding a new view. It won't allow me to create a new view, because I get these error messages.

May be related to http://drupal.org/node/420536 or http://drupal.org/node/354024, in that I recently made my site secure and now the web address http://www.mysite.com is now https://www.mysite.com.

The reason I'm wondering if this has something to do with it, is that in the above mentioned posts a redirect in their .htaccess file caused problems with Views. I'm grasping at straws here, but I can't figure out why Views quit working.

Views version: 6.x-3.0-alpha1
Drupal: 6.15

Most recent added module: Custom Pagers, Weather module update.

I first received the error mss. when I added a new view "comm_sites", view type "node." Next I clicked "items to display" under Basic Settings, and changed 10 to 0. Upon clicking "Update" I get the error mss described above. I also receive the error message if I try to change any of the Defaults. As a test, if I create a new view named "test" and leave all the defaults, it will allow me to click "Save", but then displays the warning, "Display 'Defaults' uses fields but there are none defined for it or all are excluded." Which makes sense I suppose, but it won't let me change any of the Defaults.

Anyone know what's going on here?

Comment	File	Size	Author
#4	1-13-2010 10-00-42 AM.png	18.75 KB	ShannonK
#2	1-12-2010 5-33-59 PM.png	17.27 KB	ShannonK

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

merlinofchaos CreditAttribution: merlinofchaos commented 12 January 2010 at 20:58

Two things to check:

1) using firefox and firebug, check the actual POST response and see what it looks like. Sometimes you can get a lot of information from this.
2) Check your apache/php/watchdog logs and see if there was a crash of some kind.

Comment #2

ShannonK CreditAttribution: ShannonK commented 13 January 2010 at 03:22

File	Size
1-12-2010 5-33-59 PM.png	17.27 KB

Using firebug there was a POST in the body:

form id="search-theme-form" method="post" accept-charset="UTF-8" action="/index.php?q=admin/build/views/edit/comm_sites"

I don't think that helps does it?

Is https://www.mysite.org/admin/reports/dblog the same thing as watchdog?

If so, I get a lot of logs that look like this (attached). (I blocked out my website name in the interest of preventing spammers/hackers). Does this log message mean anything significant to you?

Comment #3

merlinofchaos CreditAttribution: merlinofchaos commented 13 January 2010 at 05:10

The POST is what you sent to the server; what was the POST response? That's the more interesting thing.

dblog is the same as watchdog. I don't think that notice is relevant...though I have no idea what that notice even *means*.

Comment #4

ShannonK CreditAttribution: ShannonK commented 13 January 2010 at 18:21

File	Size
1-13-2010 10-00-42 AM.png	18.75 KB

I attached another log message, but it doesn't tell us anything, I don't think. By the way, my whole site is secure...why do the logged error messages say http instead of https? Does this tell us anything?

So I found the POST message (hopefully this is what you mean) by using Firebug and going to DOM and the postMessage. But where do I find the POST response?

Thank you in advance, sorry I'm such a novice!

Comment #5

ShannonK CreditAttribution: ShannonK commented 13 January 2010 at 21:05

Update: Somewhere I remember reading to try disabling Javascript for Views, so I just tried it and now I can add a new view without the error message. I'm not sure why this started happening, since I've used Views fine in the past. I'll post back if there are additional issues with this, but for now it appears to be working.

Comment #6

merlinofchaos CreditAttribution: merlinofchaos commented 14 January 2010 at 00:05

Do you see any 503 errors in your error_log or as a response via firebug?

Comment #7

ShannonK CreditAttribution: ShannonK commented 14 January 2010 at 01:18

Not in the logs...but where do I look exactly using firebug?

Comment #8

mcarbone CreditAttribution: mcarbone commented 20 February 2010 at 01:21

I was getting this error when clicking + on Fields, Arguments, etc, and I just solved the problem by finding an obscure bug that wasn't triggering any PHP errors.

Namely, I discovered that I had introduced some hidden line breaks in some CCK field labels by copying and pasting from a PDF, and those line breaks weren't being escaped in the JSON and hence were causing a "parseerror" in the $.ajax call. (I was led to this by validating the JSON response into JSLint, although I first had to remove any "\x"'s first as they were throwing off JSLint's parser.)

I'm not sure if this is a views bug, for not properly escaping the line breaks, or a CCK bug, for letting them get through and into the database in the first place. My guess is that either way, it wouldn't hurt for Views to account for line breaks when constructing the JSON response.

Another suggestion: $.ajax's error setting provides some arguments (XMLHttpRequest, textStatus, errorThrown) which might be helpful for debugging these kinds of issues. By adding textStatus in the error alert in views/js/ajax.js, I was able to determine it was a parse error, which led me to JSLint. It's probably worth throwing at least that argument into the error alert popup, if not the other objects.

Comment #9

merlinofchaos CreditAttribution: merlinofchaos commented 20 February 2010 at 01:37

Wow. If that's really the case, it sounds like it's actually a bug against core. drupal_to_js() should escape anything that needs to be escaped.

Comment #10

mcarbone CreditAttribution: mcarbone commented 20 February 2010 at 02:14

Hmm, I just tested drupal_to_js directly on the string and it did indeed escape the line feed -- but I can assure you that it wasn't being escaped in the JSON response I was looking at. (You can test this rather easily by creating a CCK field with line breaks in the label.) But I guess in order to test this properly, we'd have to find the exact place in the code where the object coming from CCK is sent through drupal_to_js -- as maybe it's that particular data structure that's not being handled properly.

Comment #11

merlinofchaos CreditAttribution: merlinofchaos commented 20 February 2010 at 02:30

Views exclusively uses drupal_to_js() for its AJAX work. I don't know how this could be possible. Hm.

Comment #12

mcarbone CreditAttribution: mcarbone commented 23 February 2010 at 18:59

I dug a little deeper, and it's definitely a bug with drupal_to_js. I ran the label with the special characters through drupal_to_js and it preserved them, and then ran it through PHP's json_encode and they were converted to the unicode escape sequence "\u2029" (the paragraph separator character). In other words, drupal_to_js is not unicode safe.

I'll open an issue for this.

Comment #13

mcarbone CreditAttribution: mcarbone commented 23 February 2010 at 19:54

There was already an issue open to add more escapes to drupal_to_js, and I added these unicode separators to it: #479368: D7: Create RFC compliant HTML safe JSON

Note that this isn't an issue with Drupal 7 since the PHP requirements allow us to use PHP's json_encode function, which handles this properly.