Still having trouble with these constant javascript error messages when creating or editing views or using the autocomplete control. I've traced into jQuery.js and have determined that the failure happens when the code tries to eval() the data returned in the httpData section of jQuery.extend. These lines in particular:

if ( type == "json" )
data = eval("(" + data + ")");

This blows up. The data that is being eval'd upon autocomplete looks like this:

<? session_module_name("files"); ?>{ "default": "default" }

I'm an utternoob, but this doesn't look like valid json data to me... at least the first part.

When I click on the buttons in the edit screen, the data is much longer, but looks okay except for that prepended bit. It also fails in eval().

So, what's up? Is this valid json data or not? If not, why would this be returned? I'm running Firefox in Windows Vista, btw. I've seen this code work well on another machine but I haven't had a chance to trace in and examine the data on it.

#11 346662-uicrashes.patch1.81 KBesmerel
Members fund testing for the Drupal project. Drupal Association Learn more


merlinofchaos’s picture

This is not coming from Views:

<? session_module_name("files"); ?>

It *looks* like some invalidly written PHP code in some module or something that is improperly ending up in your output stream. I would start by doing a grep across your site to see if you can find where that is coming from. It may just be at the top or bottom of a module or inc file somewhere.

I'm 100% certain that this problem lies somewhere in your installation though, and the most likely culprit is bad custom code or a module doing something wrong. Another possible culprit might be embedded PHP code somewhere, though embedded PHP code is much less likely to be run during a views AJAX response, so I find this to be a less likely scenario.

gullbyrd’s picture

Edit: I tested this by programmatically trimming the prepended bit ( "<? session_module_name("files"); ?>" ) from the data, and it worked. The ajax form displayed as intended. So the question remains, where is the prefix coming from?

gullbyrd’s picture

I grepped for that string earlier without success, but I agree with what you're saying. I haven't written any custom modules, but it could be something I downloaded.

merlinofchaos’s picture

Try just 'session_module_name' as some of the other symbols are grep special characters and might mess things up for you a little bit.

gullbyrd’s picture

Problem "solved", sort of. I commented out this line in php.ini:

auto_prepend_file = c:\wamp\www\php.ini.prepend

This was nothing I had set intentionally, and it pointed to a non-existent file.

That eliminated the bad prefix to the json data, although I'm not sure if it will have any other bad side effects, but I don't think so. The question remains, what code is prepending it? Does the function that is preparing the json data think it's creating a php file?

merlinofchaos’s picture

Hm. Maybe just be something weird about that PHP prepend. If commenting that out stopped the prepend then it's just a weirdness in that configuration.

gullbyrd’s picture

I grepped for just "session_module" and got nothing.

merlinofchaos’s picture

Title: Is this valid JSON data? » Document this JSON problem
Component: User interface » Documentation
Category: support » task

Since this is clearly not a Views problem but is a server configuration issue, changing this to a task to document this for others.

dawehner’s picture

Issue tags: +Novice

add tag.

esmerel’s picture

Assigned: Unassigned » esmerel
esmerel’s picture

Version: 6.x-2.1 » 7.x-3.x-dev
Status: Active » Needs review
1.81 KB

This is pretty weak, and should possibly/likely have more to it, but it's a start. Rolling against 7.x to start with.

dawehner’s picture would be a create page to be linked.

esmerel’s picture

Status: Needs review » Fixed

Commited to 7.x-3.x

Status: Fixed » Closed (fixed)
Issue tags: -Novice

Automatically closed -- issue fixed for 2 weeks with no activity.