I needed some hours to track down a bug that breaks uploading of new files with upload.module.

The malicious code I needed to remove (see patch) must have come into devel.module in the past week.

Firebug throws the following errors:

$ is not defined
[Break on this error] $(document).ready(function() {
js (line 2)

missing ) in parenthetical
[Break on this error] lue=\"http://ulm/upload/js\" class=\"upload\" /\x3e\n\x3cinput type=\"hidden\" ...
drupal.js (line 131)
CommentFileSizeAuthor
#9 devel.module_8.patch5.97 KBsun
devel.upload.patch983 bytessun
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

wflohr’s picture

i also investigated some hours to track down a problem mit activemenu and expanding menu trees :-)

it was the same lines of code which sun already reported

laurentchardin’s picture

I have this problem with the newly ajaxified CCK imagefield: when devel module is activated, it adds some javascript code at the end of the Ajax callback, triggering an error. Would be nice to deactivate this lines of JS code that are appended to every calls.

laurentchardin’s picture

tracked down the issue in the devel_shutdown function: line 427.
I m not a Devel guru, but looks like the Ajax callbacks are not caught by the line 380's test.

yched’s picture

salut laurent :-)

I think the proper fix would be for the imagefield ajax callback stuff to add something like
drupal_set_header('Content-Type: text/plain; charset=utf-8');
before sending its result.

sun’s picture

Title: Devel breaks Upload » Devel javascript breaks other modules

devel breaks dba module, too.

laurentchardin’s picture

Title: Devel javascript breaks other modules » Devel breaks Upload

Hi yves,

Well it seems to me that the problem occurs at the other end, i mean, when the browser is requesting a specific forged URL (aka http://xxxx/imagefield/js) which is used to upload the media to the server: it is a 100% javascript issue (most probably by using Drupal.redirectFormButton() in the upload.js code) because the jquery code is supposed to mimic a MultipartForm data form.

That might explain why Ajax upload (using hidden iframe) are not viewed by the server as javascript calls... We gonna need a JQuery guru to explore this bug.

sun’s picture

Title: Devel breaks Upload » Devel javascript breaks other modules
wflohr’s picture

i aggree with yves answer.

further investigation in this problem shows me that the devel mod is not the problem.
the devel mod already contains some checks to not break non html content.
see line 380 : devel.module

  // Try not to break non html pages.
  if (function_exists('drupal_get_headers')) {
    $headers = drupal_get_headers();
    if(strstr($headers, 'xml') || strstr($headers, 'javascript') || strstr($headers, 'plain')) {
      return;
    }
  }

if the i.e. the ajax routine doesn't set a proper header type, the devel shutdown routine will break the result.

for the jstools activemenu.module I added the following line of code (line 50, activemenu.module). after this change the menu work together with an enabled devel module

ADDED THIS LINE>>>>    drupal_set_header("Content-Type: text/javascript");
    print drupal_to_js(array('status' => TRUE, 'content' => theme('menu_tree', $pid)));
sun’s picture

Status: Active » Needs review
FileSize
5.97 KB

The solution for this problem can't be to fix countless contrib modules.

Attached patch moves the shutdown function to devel_exit(), where it should belong. Since devel has the greatest weight of all modules drupal_footer() executes devel_exit() last. Furthermore, drupal_footer() is only executed from index.php, not from xmlrpc.php, which is actually the fix for this bug.

wflohr’s picture

@sun

well done ;-) - works perfect!

sun’s picture

Status: Needs review » Reviewed & tested by the community
moshe weitzman’s picture

Status: Reviewed & tested by the community » Closed (works as designed)

it is in shutdown for a reason. i want to catch the queries issued by sess_write(). as mentioned, modules that send xml or javascript down the pipe should identify their content as such. specifically with http header of text/xml or text/javascript ... then devel will stay away. a good patch for core that addresses this issue is at http://drupal.org/node/115139. please review that patch and if you approve, mark it RTBC.

if someone comes with a solution that keeps this call in shutdown but doesn't break these modules, please reopen this issue.

jonathan_hunt’s picture

Status: Closed (works as designed) » Active

I've reopened this in order to resolve an interaction with profile_csv.module. I just performed an export using profile_csv.module,v 1.9.2.1 2007/03/24 (5.x-1.x-dev) and the following was appended to the export:

<script type="text/javascript">
      $(document).ready(function() {
        $("body").append("");
      });
    </script>

This comes from the devel module devel_shutdown(), but profile_csv has declared the headers for the non-HTML response from the server: line 179: header("Content-type: text/plain; charset=UTF-8");

moshe weitzman’s picture

Status: Active » Closed (works as designed)

the latest devel does not use javascript to output the querylog. maybe that alone will fix the problem. but i think the issue is that profile_csv is not outputting its header through drupal_set_header() or somesuch. it is using header() directly. there is also a $GLOBALS[devel_shutdown'] = FALSE that a module can set in order to avoid being appended to.