Won't play nice with wysiwyg_imageupload module

Confirming, I have the same exact issue. Any help on where/how to patch these modules for a solution?

it works on last dev

UPD. it does not work if I enabled fbconnect nor if I disabled fbconnect

Just tested the latest dev release (vectoroc-fbconnect-DRUPAL-6--2-0-APLHA2-49-ge66bbfa) with this module and the problem still exists.

wysiwyg_imageupload seems to only work if the file system is set to private. As soon as fbconnect is enabled, it appears to break the transfer to imagecache from wysiwyg_imageupload.

More info:

http://drupal.org/node/893974

I just ran a test using wysiwyg_imageupload. Without reloading the page with my WYSIWYG editor open, I disabled fbconnect in another tab. Going back to the WYSIWYG editor, I succeeded in loading an image.

My second test was to leave the upload screen of wysiwyg_imageupload open and enable fbconnect. I was able to again upload an image.

The final test was to enable fbconnect, then press the WYSIWYG button in the editor to upload an image. This time, it failed.

So, whatever is breaking wysiwyg_imageupload is being executed during the loading of this button.

Thus, we need to discover what fbconnect is injecting into the code for the upload box as this is the source of the problem.

Isolating this further, this is the correct sequence for wysiwyg_imageupload:

1. Press 'Image' button on WYSIWYG editor
2. 'Upload Image' screen is presented
3. On selecting and image, it is automatically uploaded.
4. 'Image Details' screen appears when upload completes

This is what happens when fbconnect is enabled:

1. Press 'Image' button on WYSIWYG editor
2. 'Upload Image' screen is presented
3. On selecting and image, it is automatically uploaded.
4. Returns to 'Upload Image' screen

So, fbconnect appears to be either modifying the source of the 'Upload Image' screen, or something it depends on, which causes it to fail.

Tested 6.x-2.0-beta1 as well and the same issue appears. I traced through the javascript and it is failing just after this code block:

Drupal.behaviors.wysiwyg_imageupload_uploadform = function () {
  $('#edit-wysiwyg-imageupload-file').bind('change', function() {
      $('.dialog-page-content *').hide();
      $('.dialog-page-content').addClass('uploading');
      $('form').submit();
    }
  );
}

wysiwyg_imageupload_uploadform.js

Traced this down to the following line:

$footer['autoconnect-form'] = '<div style="display: none">' . drupal_get_form('fbconnect_autoconnect_form') . '</div>';

fbconnect.module

Commenting out this line fixes WYSIWYG Image Upload.

Is there any way we can handle this gracefully in the code? Can we somehow test for WIU and not print this? Will it do any harm to the functionality of fbconnect?

Ok, so I've developed a fix. I wrapped the footer in an if block which looks at the value of HTTP_X_REQUESTED_WITH. If "wysiwyg_imageupload" is found, the footer is not rendered.

Current code of fbconnect.module:

    if (!fbconnect_get_fbuid(TRUE)) {
      // Display the autoconnect form.
      $footer['autoconnect-form'] = '<div style="display: none">' . drupal_get_form('fbconnect_autoconnect_form') . '</div>';
    }

New code:

    if (!fbconnect_get_fbuid(TRUE)) {

	// hack to correct conflict with WYSIWYG Image Upload
  	$queryString = $_SERVER['HTTP_X_REQUESTED_WITH'];
	$string = "wysiwyg_imageupload";  //string to find

	if(strstr($queryString,$string)) {
      // Display the autoconnect form.
      $footer['autoconnect-form'] = '<div style="display: none">' . drupal_get_form('fbconnect_autoconnect_form') . '</div>';
	}
    }

That will correct the incompatibility between WIU and fbconnect.

looks like it's WUI bug

probably error happens on $('form').submit(); line
every module could add its own form to the footer. they don't need to detect there is WIU or there is not

That's exactly where the error appears, just after the $('form').submit(). Including the footer seems to break the AJAX.

Is there anything in drupal_get_form('fbconnect_autoconnect_form') that you can think of that would cause it?

What does this form do?

WIU expects that you would submit WIU's form but $(form) selector finds all forms including unexpected fbconnect_autoconnect_form
Correct the selector

Vectoroc, thanks for that. I will pass that info to the developer and see what he says.

Could you answer a few questions?

1. Is the fbconnect code required on all pages?
2. When using facebook social, I noticed two copies of 'fb-root'. I have commented out the code coming from facebook social. Will your modified fb-root alone be sufficient for both modules? That is, are both of them required?

1. no in general
2. see http://drupal.org/node/852582

Why is the autoconnect form even there? Iam loading only my own form, so i rather can expect to be there alone. Why is the fb autoload form printed anyway?

The form is hidden, so how it is normaly even expected that it gets submitted?

- Why is the form injected - why its a form if it can get submitted by the user at all?

Vectoroc, if the code is not required in general can we restrict it to certain pages? This is not just to correct issues with WIU, but also to cut down page processing and loading times.

Would restricting your code to just the login pages and login block break the functionality?

@EugenMayer: all modules have same rights for hook_footer, yes ?
@drupal_acc: yes, can. but later

@vectoroc: it has _nothing_ to do with "rights". WUI is not even using the footer. Its about the issue that you paste those things into JSON / Ajax requests and thats defo wrong.

The code I posted before was slightly wrong. That code will only printer the footer to the WIU page. The code below blocks it from the WIU page, but printing it on every other page.

    if (!fbconnect_get_fbuid(TRUE)) {

// hack to correct conflict with WYSIWYG Image Upload
  $queryString = $_SERVER['HTTP_X_REQUESTED_WITH'];
$string = "wysiwyg_imageupload";  //string to find

if(!strstr($queryString,$string)) {
      // Display the autoconnect form.
      $footer['autoconnect-form'] = '<div style="display: none">' . drupal_get_form('fbconnect_autoconnect_form') . '</div>';
}
    }

On our particular site setup, using the HTTP_X_REQUESTED_WITH wasn't an option, so my tweaked hack is below.

    if (!fbconnect_get_fbuid(TRUE)) {

      // hack to correct conflict with WYSIWYG Image Upload
      $string = "wysiwyg_imageupload";  //string to find
      
      if($queryString == arg(0)) {
        // Display the autoconnect form.
        $footer['autoconnect-form'] = '<div style="display: none">' . drupal_get_form('fbconnect_autoconnect_form') . '</div>';
      }
    }

But the question is where can we get a permanent fix done? Some sort of universal check for Facebook Connect for modal style dialogs?

http://drupal.org/node/768966#comment-4190046

Try this patch http://drupal.org/node/893974#comment-4215780

Thanks larowlan, I thought I'm the one against the whole world :)

Seconding @larowlan's patch referral in #26

http://drupal.org/node/893974#comment-4215780

The proper fix here seems to be with the WYSIWYG Image Upload module's JS.

Being bold and marking this one as "works as designed."