Implement Drupal.detachBehaviors()

I have absolutely no idea which "drag and drop on textareas" you are talking about. Neither do those project pages explain which issue they claim to solve.

Without further information I'm forced to mark this issue won't fix. Feel free to re-open it.

Detot, I think i see what you are saying. When using CCK, you have the option of setting the number of values for a field. Setting it to "unlimited" allows users to add as many fields as they want by simply clicking "Add another item" - also allowing them to rearrange them by drag and drop.

The issue is, TinyMCE does not work well with this "Add another item" feature. Effulgentsia created TinyMCE AHAH Intigration which fixes this issue (other modules are needed). But, that module only works with TinyMCE WYSIWYG Editor module. Not with Wysiwyg API.

My particular issue is that Wysiwyg API is a nice way of integrating editors and allowing users to better control where the editor is shown on the site. Is there a way TinyMCE AHAH Intigration would be able to work with Wysiwyg API?

Doing this would allow the "Add another item" drag and drop fields from CCK to work well with TinyMCE, but also giving the user the power of Wysiwyg API..

Though this may be more of an issue for TinyMCE AHAH Intigration..

Could you please elaborate on this:

The issue is, TinyMCE does not work well with this "Add another item" feature.

"Does not work well" does not tell anything.

Sun -- I think the description is:

When TinyMCE is used with CCK text fields that have "add another item", TinyMCE does not load correctly and drag and drop reordering of fields doesn't work.

For example. I set a "Recipes" content type in which i have some some custom CCK fields. One of which is "Ingredients". That particular field is set to have "unlimited" values so that the user can click to add more Ingredients fields if they chose..

The original problem before adding the TinyMCE AHAH Integration Module was that when you clicked on "Add another item" the TinyMCE editor would disappear on the text areas above the newly added text area. NOW, after i added the AHAH integration Module and its required modules, the above text areas work correctly(it keeps the editor), but the newly added area does not have the editor on it... Kind of the opposite problem from what i was having before. (see attached screenshot)

Moments ago i did figure out that in the visibility settings of the TinyMCE editor preferences, if i allowed the editor to appear on ALL text areas over the entire site that everything would work correctly. But using these visibility settings from the TinyMCE WYSIWYG Editor seems dated and i would just like the editor to appear on just those fields, not the entire site..

Thank you for you help

Prior D7, this is a gentlemen agreement by contributed module authors and maintainers. The following explains how the implementation is supposed to work:

// Any contrib module that needs to detach behaviors, f.e. Wysiwyg API.

Drupal.behaviorsDetach = Drupal.behaviorsDetach || {};

Drupal.behaviorsDetach.myDestructor = function(context) {
  // Detach here.
};


---
// Any contrib module that implements AJAX/AHAH contents, f.e. CTools, CCK, or Panels.

Drupal.behaviorsDetach = Drupal.behaviorsDetach || {};

Drupal.detachBehaviors = function(context) {
  context = context || document;
  // Execute all of them.
  jQuery.each(Drupal.behaviorsDetach, function() {
    this(context);
  });
};

Unfortunately, there seems to be no other way to detach behaviors before the AHAH-event/callback is triggered than to replace ahah.js with a customized version. The only change in this file is our tiny Drupal.detachBehaviors() in this snippet:

  // Bind the ajaxSubmit function to the element event.
  $(element_settings.element).bind(element_settings.event, function() {
    Drupal.detachBehaviors($(this.wrapper));
    $(element_settings.element).parents('form').ajaxSubmit(options);
    return false;
  });

That is, because .ajaxSubmit() serializes the form values already, and since our editors are still attached at this point in time, the actual values are not contained in the serialized form data.

I actually hope that we can move almost all of this code into CTools, since only 13 lines of this patch solely apply to Wysiwyg API in reality.

Moving to CTools, since CTools already requires a custom implementation of ahah.js and Wysiwyg API 2.x will soon depend on CTools.

Hi Sun,
Thank you for the patch. I applied it, and it partially fixes the problem.

What works:
When I click "Add Another Item", the existing WYSIWYG editors are preserved.

What does not work:
If I drag one of the fields, the content inside the WYSIWYG editor for the dragged field disappears. The editor toolbar still exists, but it is not responsive. Also, clicking "disable rich text" does not disable the editor or change anything about the field.

My configuration:
Drupal 6.9
Wysiwyg: 6.x-1.0
TinyMCE: 3.2.1.1
Browser: Firefox 3.0.6

Addendum: dragging behavior does work in IE7, but not Firefox or Safari.

I'm willing to dig into this further, but I need some guidance. I am a PHP rockstar, but a Javascript newbie. I also lack understanding on how "detach behaviors" is supposed to work. Any help would be greatly appreciated.

Thanks for all you do!

I'm confused about this patch being for the Chaos tool suite module. In its current form it doesn't require the module, correct? It only replaces ahah.js and modifies the wysiwyg module?

I tested this patch and it works in that all new data is kept when pressing "add new" and all wysiwyg editors remain active, but it does a complete page refresh instead of just loading a new textarea.

Yes, the patch was originally written for Wysiwyg API. However, after further discussion with merlinofchaos as well as considering the fact that Wysiwyg API will soon require CTools for a number of other reasons, and since CTools already ships with an alternative implementation of ahah.js, Drupal.detachBehaviors()' best home is CTools.

Unfortunately, I'm still trying to spare some time to dig further into the world of CTools (and how we could let Wysiwyg API use its static object caching, plugin system, and possibly also DND handling).

The weird thing is that I get the expected behavior with the altered ahah.js but without changing the wysiwyg module. The weight issue mentioned above is still there, but the RTE settings are as expected and the text is still formatted. I hope this information helps somehow.

Subscribing

I believe the originally reported problem with AHAH may happen when the initial page lacks a javascript library or stylesheet that is required by the content sent through the ajax request. I had to use the ajax_load module to solve similar situations. Not sure if this is also applicable here, though. :P

Hi Marc, could you enlighten what "similar" situations were fixed using that module? Thank you so much for your work on the multigroup module btw, it's an amazing piece of work.

@wmostrey: Of course, the changes to Wysiwyg API's files are required to gather a change at all. It is perfectly possible that this patch no longer applies cleanly though.

@markus_petrux: No, that's a different issue: #356480: Lazy-load editors

@sun: Thanks for the link.

@wmostrey: Thanks for the compliments. By "similar situation" I meant in custom code for the project I'm working on, that I have to load stuff using ajax, and the loaded content may require js/css that is not present on the page. I solved that using the ajax_load module.

So I would suggest looking at the ajax_load module, as it contains a few tricks that are required in order to dynamically load js/css, with support for color module (recent patch), and support for jquery_update (patch needing review).

Sorry to hijack this issue, but I believe the solution is tricky, so I hope it helps the pointer.

Sorry to be joining this conversation so late. I think it's morphed into something different than how it started. In case it's helpful, I created separate issues for the Wysiwyg API project related to the description and first 7 comments of this issue.

#452666: Data loss when clicking "Add another item" from CCK text field
#452678: Data loss when using tabledrag to re-order items for a CCK text field using tinymce/CKEditor

@sun #18: hmm... no. I think it's the same issue. And this could be solved with the help of ajax_load module. Ajax in Views 2 uses it, so where's the problem with this module? Why re-invent the wheel when ajax_load has the know-how?

Is there any particular reason why ajax_load module is not being used in CTools, as it's been used in Views 2?

Views does not use ajax_load module

Views implements hook_ajax_data_alter() in ajax.in and ajax_views.js, and this hook is where ajax_load module does its job, so I assumed that was intentional. In any case, this is what deals with dynamic additions of javascript files and stylesheets as a result of AJAX responses. It works great here, and I think it contains several tricks to do it properly in Drupal. I always thought something like this ought to be part of core.

Oh. Okay, mayb ethat was intentional and I never thought about it, because I'm happy to do stuff like that when the impact is minimal.

And that little thing is what makes Ajax Views shine when rendering anything that needs js/css not already present on the page.

Would you accept a path for CTools ajax-responder to support ajax_load? ...or do you plan to provide this kind of features in some other way?

Seems like an easy one. It makes total sense. Though it does seem like something that should have a more or less built in solution.

Yes, I would also like to find a way to universalize (*) the knowledge behind ajax_load, which is tricky by itself.

The problem I see is that this would have to be part of Drupal core, or something pretty close to it. That way, no one else needs to reinvent the wheel.

Is this food for CTools? I don't know... so maybe we could start by doing here now something like in Views? ...or do you think CTools Ajax is something that every other ajax tool in Drupal should rely on at this moment? ...maybe this is something to decide for D7?

I'm currently writing a patch to integrate all the good parts of the CTools ajax.inc with ahah.js for D7, so it's something worth thinking about.

At worst we should go ahead and include the ajax_load integration. It solves a problem and it costs us almost nothing.

Note that Wysiwyg module 3.x requires CTools. I'm not sure whether client-side editors can be lazy-loaded at all (I've heard rumors from quicksketch not being able to do so), but if CTools's ajax handling would already contain/provide this (ajax_load) feature, it may already solve the lazy-loading issue for some scripts, and in effect, would mean one dependency less. So I'd vote +1 for doing that.

However, as mentioned earlier, the purpose of this issue is to implement Drupal.detachBehaviors(), not lazy-loading of scripts via ajax. Unfortunately, I'm swamped with a lot of work; but I still hope to be able to get to work on this asap - if no one beats me to it.

@sun: Yes, sorry for that, but I think both things are related. Ajax_load is needed to dynamically include js/css that may come with ajax requests, then detachBehaviors is required to perform cleanup tasks before replacing DOM content. Both are required to make Wysiwyg editors work when Ajax is involved.

Well, I was surprised by the fact that no one was mentioning Ajax load. In Views, it is there, but even Earl forgot about it. And that was making me cry (lol), because that little thing solved me a lot of problems here.

Agree on that the possible integration of ajax_load in CTools could be discussed on a separate issue. I'll open one with a patch for review - if this can be of any help here.

[EDIT] #522744: Integration of Ajax_Load module in CTools?

Subscribe

Is this issue still valid? Also related #862522: Resizable textarea behavior does not detach

I'm starting to think that this is the final piece of the puzzle to getting wysiwyg to work in a CTools modal.

With wysiwyg module, I have tested CKEditor. Everything works, except for the submit button. I admit, when this whole thing started, I was never quite cognizant of what the detach actually was intended to do, which might explain why I let this issue sit.

Now that I'm to the point where it's blocking, I think I'd like to proceed.

The question is...how in the world do we get a detachBehaviors in Drupal 6? Is wysiwyg module already supporting this concept?

Yes, that's built-in already, as all editors need to attach and detach anyway, to switch editors and stuff like that.

However, since we don't have the new behavior objects with proper attach/detach methods of D7, Wysiwyg is implementing a separate function Drupal.wysiwygDetach(), see http://drupalcode.org/viewvc/drupal/contributions/modules/wysiwyg/wysiwy...

Okay. So this puts puts us back to the idea that CTools should host a detachBehaviors similar to Drupal.detachBehaviors. Obviously we can't have behaviors.foo.attach and behaviors.foo.detach the way D7 does, but we could possibly have a Drupal.detachBehaviors namespace for D6 and run essentially the same code. I could implement a Drupal.CTools.detachBehaviors() and wysiwyg could respond to it appropriately.

Right, that was the idea we already discussed + documented in #8 in this issue. :)

Technically allowing all modules to implement detaching behaviors, not dependent on CTools, but any D6 module that wants to invoke detaching behaviors without depending on CTools needs to implement Drupal.?.detachBehaviors() on its own.

That said, I wouldn't mind if CTools would just simply take over and implement Drupal.detachBehaviors() -- it's a backport after all.

--

Speaking of, Wysiwyg's current detach methods don't support all parameters of D7's detaching behaviors yet. Especially the 'trigger' argument was invented for D7 (by markus_petrux or effulgentsia or am I mistaken?), which allows modules like Wysiwyg to differ between just serializing and completely detaching + unloading.

I'm not at all familiar with any of the features surrounding D7 and detach (I just looked at D7 wysiwyg module and didn't see support for detach at all?)

IMO Ctools AJAX framework is important enough that if we can get this working, it's easy to point to it and say "If you want this to work, just use that", so that's probably the way to go. I'm still not yet sure how to do the backport, but it should be easy enough to backport detachBehaviors on the CTools side. Getting it to respond properly on the wysiwyg side is a bit beyond me just now.

The idea of a trigger seems valuable, but to be honest it's very difficult to *know* prior to submit whether or not the data will be destroyed. In a modal it's a lot easier and we can assume total destruction, but when using something attached to a select box that may or may not change out a form elsewhere on the page...that's tougher. It may be hard to *use* triggers properly.

@merlinofchaos: In case you're interested, this is the D7 issue that implemented detach() with a trigger parameter, and made sure it got called from where it needed to be to make wysiwyg work: #561726-35: ajax.js and tabledrag.js need to implement Drupal.detachBehaviors().

Looking at the current state of all related issues and modules (D6 and D7), I think this issue can simply be marked as "fixed".

Does CTools now have the functionality of ajax_load?

This issue was fixed as part of #848580: Problem - Can't edit text fields in modal popups for panel panes that use wysiwyg editor in ctools 6.x-1.8, and it's fixed in ctools 7.x-1.x-alpha2 as well.

It still is a problem for wysiwyg though

and this conversation is very old!

Sorry for double-posting (again) but i came up with this #1155678: Implement Drupal.behaviors.attachWysiwyg.detach
i thought u would like to know

Marking fixed based on wmostrey's comment.