Load Wysiwyg/libraries for AHAH forms
damiancugley - January 9, 2009 - 11:54
| Project: | Wysiwyg |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
My module has a page that has a form that appears via the Popups module. This works by getting the page with the form via XMLHttpRequest and then puplling the form out of the HTML and pasting that in to the existing page. This means that when the Wysiwyg API module is scanning the form and modifying it to trigger the JavaScript code that adds the editor, the JavaScript files and Drupal behaviours' settings added drupal_add_js have no effect, so the editor is not activated.
I imagine the same problem would affect text areas added to the page via the AHAH machinery.
I have worked around this by adding code that creates a fake form and calls wysiwyg_process_form directly in order to get the code added to the page.
#1
Yes, I experienced this issue as well, and we have yet to find a proper solution for it.
Currently, I'm doing the following in a custom form_alter() implementation to load all libraries for the Panels 2 page content (display editor) page:
<?php// Panels support.
if (module_exists('panels') && $form_id == 'panels_edit_display') {
// Load potential editor.
foreach (filter_formats() as $format => $object) {
if ($profile = wysiwyg_get_profile($format)) {
wysiwyg_load_editor($profile);
wysiwyg_add_plugin_settings($profile);
wysiwyg_add_editor_settings($profile, 'advanced');
}
}
}
?>
I.e.: All libraries are loaded upfront on the executing page, without knowing whether the libraries will be needed at all.
Lacking a better idea, I thought of introducing a wysiwyg_load_all() function or similar for other modules that just does that.
#2
In case it's helpful, you may be interested in checking out the ajax_load module and/or the combination of ahah_response, ahah_page_storage, ahah_script_ensurer, and ahah_style_ensurer.
Both ajax_load, and the combination of the 4 ahah_* modules, try to address this general limitation to using AJAX/AHAH. At some point, I hope the developers of ajax_load and I can collaborate on how to improve/integrate these modules, as well as work towards solving the issues in core for drupal 7.
#3
Note, there is an issue about WYSIWIG-enabling Panels: http://drupal.org/node/235764
@sun, I think your code may need to be updated to the latest Panels 3.
#4
Having a similar issue - got an AHAH call on the node form that replaces the body field (
edit-body-wrapper) and when the field reloads the WYSIWYG no longer works on the node body. I think is because I don't seem to be able to use the core node_body_field() function to replace the form field, so I'm reduced to rebuilding them myself - probably some hooks not invoked or something like that?But this will be a recurring problem I think, because there doesn't seem to be any elegant way to manipulate the node body field with AHAH right now, which is a shame. =(
Edit: my related issue, if anyone is interested: #527622: WYSIWYG editors disappear after node body rebuild and switching filter does not bring them back
#5
Suscribing :).