Posted by damiancugley on January 9, 2009 at 11:54am
83 followers
| Project: | Wysiwyg |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
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.
Testing Matrix
| Editor | IE8 | IE9 | FF11 Win | Chrome Win | Safari OSX | FF11 OSX | Chrome OSX | ckeditor | Y | Y | Y | Y | Y | Y |
|---|---|---|---|---|---|---|---|
| tinymce | Y | Y | Y | Y | Y | Y |
Comments
#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 :).
#6
subscribing
#7
You might want to try the ajax module which contains an ajax_wysiwyg module that fixes this behavior in some cases.
#8
Wow, I have a large flat patch on the side of my head after banging it into this brick wall for daaaaaaays.
In the end, whaddaya know, there's a glitch in TinyMce where it doesn't recognise an ahah request as completed, and therefore can't initialise the editor properly.
After your callback, add a line of js before you call attach behaviors like so...
$.ajax({url: url,
dataType: 'json',
success: function (response) {
$(target).html(response.data);
},
error: function (xmlhttp) {
alert('An error occured: ' + xmlhttp.status);
},
complete: function(){
tinymce.dom.Event.domLoaded = 1;
Drupal.attachBehaviors($(target));
}
#9
I've the same problem with textareas which have a "Add more" button. The first time I hit the "Add more" button a textarea via TinyMCE appears but it is frozen, the second time another textarea with TintMCE appears - the previously added textarea becomes unlocked and the newly added is frozen. I've tried TinyMCE 3.3.9 and 3.3.9.2. I have ajax_wysiwyg a go but with no luck.
Do I need to perform some magic in hook_form_alter() ?
#10
I wrote down the solution I came up with: The Wysiwyg and CCK multiple value fields.
In short: you can fix most issues by installing the Wysiwyg API CCK Integration module, which itself depends on three other modules: JS Alter, jQuery Form Update and jQuery AOP.
If you still have issues then the only solution is to use the FCKeditor plug-in for the Wysiwyg module. It's the only one that doesn't have any issues with multi-value cck fields. (So yes, even CKEditor has issues.)
#11
This can only be fixed in Drupal 7.
#12
to people more intelligent than me on this:
Are there some simple steps that can be included here to add in template.php or something to get this functional for D7? how difficult is this? I'm a bit out of my realm. Please provide a step by step if possible.
Thanks in advance!
#13
No, there are no simple steps to get this to work, which is part why we've waited for D7 to arrive.
Wysiwyg needs to be redesigned a bit for this to work as now it loads all the necessary files right away and it wouldn't know how/when to load them at a later stage. D7 also has a later version of jQuery which supplies the events we need, but the clientside code also expects all files to be there already so it doesn't react to those events yet.
#14
subscribe
#15
subscribe
#16
ok, I officially don't get this:
To understand what I mean, you need:
drush -y en wysiwyg_test#17
Same as before, but this one loads something. :) Well, no editor yet, but it looks promising ;)
#18
subscribing
#19
sun, your time spent on this is much appreciated, thanks!
#20
bump bump :)
#21
subscribe
#22
subscribe
#23
subscribe
#24
subscribing
#25
I've been looking into this some today and I've been able to get CKEditor to load/display (though not perfectly).
The main issue that I've found is that when the editor is being loaded via AJAX the basePath isn't getting set before the editor loads and thus the skin and some related files are being loaded from an invalid path.
I've been able to get the editor to display by adding the following line to the top of "wysiwyg.init.js".
window.CKEDITOR_BASEPATH = 'http://test.localhost/sites/all/libraries/ckeditor/';I'll continue working on this today and hopefully will be able to submit a patch in the next day or so to help move things forward.
#26
Here is an updated version of Sun's patch in #17 that moves things forward a bit. We at least now have CKEditor displaying.
This patch adds two things to Sun's patch:
1. In ckeditor.inc, I add a new setting value that specifies the name of the global variable CKEditor looks at for the basePath.
2. In wysiwyg.init.js, I added some code that scans the settings array for all enabled editors and sets the global basePath variable if defined.
These are the remaining issues that I'm aware of at the moment:
#27
Just a quick update on my progress. I have CKEditor working with the Panels module, though there are still a couple issues to work out.
The main issue I solved today is that I had to change the order of the form submit handlers so that the WYSIWYG submit handler fires before the Panels/CTools submit handler. This solved the problem with the WYSIWYG content not being saved.
The remaining issues to resolve include:
I'm hoping to submit an updated patch in the next day or two.
#28
Attached is a fully functional patch that allows CKEditor to work with Panels or in theory any other AJAX loaded text area. I haven't tried using any other editor yet, so there may be issues there that still need to be addressed.
This patch is rolled against the Feb 25 dev release of WYSIWYG.
I'm sure there are some things that could be implemented better and I'm certainly willing to continue making refinements to the patch as needed.
Please give it a try and post the results of your testing here.
Here is a quick summary of the enhancements made to the patch in comment #17.
editors/ckeditor.inc
wysiwyg.init.js
wysiwyg.js
#29
Here is a modified version of the patch in #28 that doesn't have absolute paths to the files so that it can be directly applied to the wysiwyg module.
#30
Any update on this?
#31
I'm waiting for some feedback from the community on the patch and to have some other folks test it out. The patch works with CKEditor in the D7 project I'm working on right now, but I expect that it will need some more refinement before it can be merged into the main dev tree.
#32
Okay, I just did a quick test using the views module where I first had this issue. (Reference: http://drupal.org/node/1027064)
The module applied without issues against the mentioned -dev branch.
When I tried to edit a text editor in the view module, the text area appeared.
Prior to this patch, the text area did not appear.
However, clicking the submit or even cancel button causes some sort of ajax error such that the page turns into a single line of ajax jargon.
The other issue I have had is that my particular editor is not showing up in the views.
I personally do not care about it appearing here, but this may or may not be intended by the lazy-load process.
#33
Hey @Shawn_Smiley, thanks for submitting the patch. It does allow wysiwyg to load ckeditor in panels, great. The data doesn't save, however. I'm using drupal7+bartik+panels... and your patch. Saves without the ckeditor. Also, you have a lot of debug statements in the patch that cause the javascript to fail unless you have something to support that function, throws lots of js errors. Thanks!
#34
Just to follow up on #29, it's all working except for the saving. I can't get the changes to stick.
#35
subscribe
#36
Has anybody else tried #29?
#37
Thanks for the feedback thekevinday and schaub123. I'll try to find some time to investigate these issues over the weekend.
Related to content not saving, one of the challenges I found was that I have to re-arrange the order of the event handlers when the overlay window is submitted or closed. Otherwise the form was being processed before the WYSIWYG had a chance to update the underlying form field with the updated content.
#38
Hey Shawn_Smiley, what module are you using to handle the $.debug calls in the javascript? Firebug for drupal? Debug isn't released for dp7 yet.
Thanks.
#39
@schaub123
I think something got lost in the patch generation so that we don't have the $.debug() function defined any longer. It was just a wrapper around Firebugs Console.debug() statement if I remember correctly.
Here is an updated patch that removes all of the debug statements.
Can you give me the exact versions of Drupal, contrib modules, and CKEditor that you're using so that I can try to replicate the issue?
Also, if you click the "Disable Rich-text" link before saving, does the correct HTML display in the text field?
It's working correctly for me with the following configuration (everything is latest version):
@thekevinday
I also wasn't able to reproduce your issue with the above configuration. I was able to enter and format the global header text using the WYSIWYG.
#40
$.debug() is provided by the admin_devel module, which ships with admin_menu.
#41
Ok, here's the issue with #39. Turn off the "disable rich text" link in the wysiwyg setttings and things stop working. I think it's because you are counting the handlers +2. So, you are expecting that folks will have the disable rich text link enabled. That's why it wasn't working for me. Is there a way to get it to not require that option being checked? Thanks, cool stuff!
#42
Ah, excellent information. I'm sure I can come up with a better check before resetting the event handlers based on this info. I'll try to get an updated patch rolled out on Friday or at the latest Monday.
#43
Fyi, something else got changed in patch #39 that causes the window not to show on re-edit. Patch #29 was better, and I just manually removed the debug. Nevermind, #39 loads the editor, just no save.
#44
Can you give me some exact steps to reproduce the issues including which browser you're using?
I just did the following this morning:
I've done these tests using Firefox 3.6.10 on OS X 10.6.
#45
#39 works for me without issues.
I am using the feb-25 dev release.
#46
I am using everything the same as you in #39. The only difference is that I'm using alpha4 of ctools. Tried firefox 3.6 on OSX 10.6. I couldn't use git apply, complained about whitespace. Used patch -p1 instead, but it said it patched all files cleanly. Using stock bartik with seven as admin theme in latest drupal 7 from dev.
#47
Shawn_Smiley. Just downgraded to ctools alpha3, no dice. Are you using the bartik theme and the stock admin menus?
#48
Found it. It was jquery_update. Disabled it and all is now working. Not sure what would cause that, but jquery_update was causing the issue. Patch #39 is working.
#49
Thanks for the update schaub123. I haven't been running the jquery_update module, but I'll get it installed and see if I can track down where the conflict is at.
#50
I've done some investigation of the issue related to jquery_update. It appears that the object structure returned when querying existing events on an object has changed between jquery 1.4.x and 1.5.x. Which is causing the WYSIWYG event binding to break when it's loaded in a ctools overlay.
I've implemented a hack of an update to confirm the problem and potential solution, but I want to come up with a cleaner implementation before submitting a patch.
Does anyone know of a clean way of getting a list of events bound to an object that works in both jQuery 1.4 and 1.5?
Currently I'm doing the following: event_list = $("selector").instance.data().events;
The problem with jQuery 1.5 is that $("selector").instance.data() returns an intermediate object with an instance specific name so you have to do $("selector").instance.data().jquery2358723598237542.events to get a list of bound events. The name of the object "jquery2358723598237542" changes with every page request so I ended up having to loop over the properties of the data() object to find the correct item to query.
#51
hello guys!
1st, i'm new in drupal.
last time i work at my own website hosted by hostmonster.com.
my problem: in panel-> content it dont will be show wysiwyg editors.
my question: how can i patch with "lazyloadeditors-356480-39.patch"#39 or "wysiwyg-ajax-29.patch" #29?
my configuration:
drupal 6
ctools 6x18
panels 6x39
devel 6x123
wysiwyg 6x23
full pack of editors...
again i host my site at hostmonster, here no git programm and it seems will be difficult to install.
"git apply" command -only one way?
thanks
#52
Hi loop54 and welcome to the Drupal community.
Unfortunately this patch only works with the Drupal 7 version of WYSIWYG right now. See comments 11 and 13 above for more detail.
#53
subscribing
The patch in #39 is working with the following configuration:
I also tested with TinyMCE (3.4.2-jquery), but it didn't work. The editor simply didn't show up.
Again with ckeditor 3.5.3, I tested IMCE (7.x-1.3) and IMCE wysiwyg bridge (7.x-1.x-dev) which also seemed to work. I'm able to add images to my custom content in panels with ckeditor.
Thanx for the patch, Shawn!
Just for the sake of completeness: the patch could only be applied to the git master branch of wysiwyg. It failed on the dev release.
#54
great works #39 works for me as well (wysiwyg 7.x.-2.0)
update: looks like it works. Unfortunately it works not always and the content pasted via wysiwyg is not beeing saved!!!!
Any ideas?
#55
@luckystrikerin: I have the impression this doesn't work with all configurations, can you post your module versions?
#56
Drupal: 7.0
Chaos tool suite: 7.x-1.0-alpha4
Libraries API: 7.x-1.0
Panels: 7.x-3.0-alpha3
Wysiwyg: 7.x.-2.0
CKEditor 3.5.2.6450
After this patch I could at least see the wysiwyg editor sometimes, before I always got a white place with nothing. But the content I inserted via ckeditor is not beeing saved.
#57
@luckystrikerin: I was not able to apply the patch to Wysiwyg: 7.x.-2.0. It generated failures (1 out 5) when I tried (even on the dev version, which I think is weird). In my case, it only applied correctly on the git version, with git apply ...
It's the master branch: http://drupal.org/node/181465/git-instructions/master.
#58
@zilverdistel: thanks for your help. Its working now with the git version.
#59
Any update on the jQuery 1.5 issue? I can confirm that the patch in #39 works with wysiwyg loading in a ctools modal (privatemsg send form in this case) with jQuery 1.4, but not 1.5.
#60
Patch in #39 is working for me with CKEditor but not with TinyMCE.
Using:
Seeing the same issue with JQuery Update.
#61
Not sure if relevant, but referencing nevertheless detail about CKEditor base path in duplicate issue #1067792: Editor not showing on Views Global text area - m.lang.contextmenu is undefined
#63
subscribe
#64
sub
#65
sub
#66
patch in #39 also worked for me
#67
#39 worked for 7.2, but not master. weird.
However, changes are still not saved.
#68
I've fixed #39 (for at least CKEditor and TinyMCE) by correcting the logic that inserts Wysiwyg's event handlers before CTools's. Also, TinyMCE is now manually instructed to load by telling it DOM is loaded.
Granted, TinyMCE still doesn't work that well with Panels IPE,
but I suspect it's IPE's fault(see #69).#69
This is starting to look really good!
Though, it does reveal a bug in Core: #1287368: Drupal.settings.ajaxPageState.css gets overwritten.
#70
sub
#71
subscribing
#72
Subscribe
#73
Subscribing.
#74
@ the last two posters, you realise there's a "Follow" button in the top right of every issue page now so you don't have to type "Subscribe" in a post to get alerts? Right now it'll say "Following" because you were auto-subscribed, but before that (on any other issue) it's a big green "Follow" button in the right sidebar.
See: http://drupal.org/node/1306444
#75
What's holding up the patch from #68 getting committed?
#76
Patch in #68 plus patch from #1287368-7: Drupal.settings.ajaxPageState.css gets overwritten work nicely to get CKeditor in the Panels custom content popup in my Drupal 7.10 site.
#77
@animelion, not much. A final review of #68 should be able to RTBC it now that #1287368-25: Drupal.settings.ajaxPageState.css gets overwritten is RTBC, and it can get committed when problems caused Core won't cause a flood of bug reports/comments about this fix not working properly. (Without the Core patch, some editors will look really crappy when lazy-loaded by, for example, the Panels' Pane-editor due to missing stylesheets.)
That might still happen considering not everyone will also update to the latest Core when updating Wysiwyg. But at least then we can close those issues with a quick "Please try with the latest Core release first, then re-open this issue."-message. Hopefully, that won't happen so often, as anyone about to create such an issue should be reading this existing issue and comment first. ;)
#78
I applied the patch in #68, and now CKEditor works in Panels Panes. Marvelous. However, I noticed that on line 23 and 32-34 of the patch, some commented-out code was added. It should be removed, unless it was meant to be un-commented. FYI.
#79
is related to http://drupal.org/node/1391034 ?
I applied patch in #68 and still wysiwyg editor is not loaded via ajax ( TinyMCE )
EDITED: TinyMCE
#80
sun code in #1 in form creation load wysiwig toolbar twice (actually cause the call of wysiwyg editor twice)
#81
#80 happen when filter format with wysiwyg profile activated is the first (default) for the form element, moving to second position, thus activating it by changing drop down, do not cause problem
#82
@smartango, http://drupal.org/node/1391034 does not lead anywhere. Wrong nid?
The editors won't always be loaded via AJAX when the #68 patch and the D7 patch from #1287368-40: Drupal.settings.ajaxPageState.css gets overwritten are added (it's been committed to D8), but it should make it possible to use them in the Panels editor and other places where textareas with format selectors are loaded via AJAX.
Sun's code from #1 was an experiment, it's of no use now as things have changed a lot since 2009.
#83
@TwoD I've done a wrong test, #68 works with TinyMCE, css loading is missing but I added it to the initial form.
So, for me #68 is ok
I think http://drupal.org/node/1391034 is the same problem: editor not loaded if node_add il called in ajax callback. Am I wrong?
#84
Ah, now the link works (I got a 404 earlier for some reason).
If the situation in #1391034: wysiwyg is not loaded when used with node_add() in ajax forms works after applying #68, it's the same issue.
#85
Sorry, I´m reading this post and documentation about patch and i don´t understand where and how i have tu apply this patch. My english is very bad and I suppose it´s a big problem.
I´d like somebody could help me a little, please.
#86
@comodo1980, you apply the patch from #68 to your wysiwyg folder, and the latest patch from #1287368-40: Drupal.settings.ajaxPageState.css gets overwritten to the root Drupal folder. How to apply a patch depends on which OS you have, start at Applying patches with Git, or HowTo: How to apply a patch to a contributed module - Beginner's version (Windows).
#87
I'm not sure if this is related to this patch or issue, but when loading in a modal using ckeditor 3.5.2 (after doing something similar to sun's code in #1) there are two ckeditor spans beneath the textarea (thus getting duplicate toolbars). I, then, only get one span if I close the modal and re-opening (after applying/using #947676: Support new CTools event for detaching when the modal closes - this doesn't matter for this issue i'm running into other than it doesn't happen on re-opening the modal).
The only place I found to fix this was in wysiwyg.js line 65, changing an if to an else if. I am not sure what the effects of this are as I am not familiar with Wysiwyg API.
if ($this.is(':input')) {Drupal.wysiwygAttach(context, params[format]);
}
// Attach onChange handlers to input format selector elements.
// Without this else if I get two duplicate ckeditor toolbars on the FIRST load in a modal, but the second time it's fine.
// I have no idea why.
else if ($this.is('select')) {
$this.change(function() {
// If not disabled, detach the current and attach a new editor.
Drupal.wysiwygDetach(context, params[format]);
format = 'format' + this.value;
Drupal.wysiwygAttach(context, params[format]);
});
}
#88
It sounds like the editor gets attached twice. The change to an "else if" prevents the editor from being attached when there's a format select box present. Your screenshot does not include anything below the area, but I assume there is a selectbox there.
Why are you using code similar to that in Sun's #1? It is not needed if you apply the patch from here, since any Wysiwyg/editor scripts that should get loaded when a format-enabled textarea is created are automatically added by Drupal/Wysiwyg.
Can you try with just the patch from here to Wysiwyg 7.x-2.x-dev, then apply the one from #947676: Support new CTools event for detaching when the modal closes? I'm not sure the last one is needed for D7 since we now support detaching behaviors.
Could you attach or link to the code loading the modal if it doesn't work so we can try to reproduce the issue?
#89
Yeah, I'm going to have to try to narrow down and simplify the code to see if I can reproduce it first.
#90
I followed instructions in #86, cleared cache (important), and it works! Thanks TwoD!!!!
#91
#88. Yes, the patch does solve the double issue I was having (instead of having to make that js modification). Patch didn't apply on my 7.x-2.x-dev so I have re-rolled it here.
I did not need to apply #1287368-40: Drupal.settings.ajaxPageState.css gets overwritten to get wysiwyg with ckeditor to load in a ctools modal.
#92
Thanks for rerolling the patch.
Additionally, I think it's finally time to decide what to do with that commented section (per #78).
EDIT
For clarity:
+// if (typeof Drupal.wysiwyg.editor.initialized.ckeditor == 'undefined') {+// Drupal.wysiwyg.editor.init.ckeditor(settings);
+// }
#93
I followed Twod's instructions in #86, cleared cache, and it works fine!
Thank you !
#94
Patch from #91 works great!
#95
Just tested it and can confirm that #91 works great!
For the German users (and others of course who would like to use it - but blog post is in German), I've provided a temporary patched wysiwyg module download at my blog post:
http://julian.pustkuchen.com/drupal-7-wysiwyg-tinymce-panels-benutzerdef...
which I am using myself.
(As a short help for users who don't know how to patch, of course handle with care, it's just a reviewed patch!! See warning at the end of the blog post.)
#96
I am not sure if this is what #43 was running into, but the first submit does not transfer values to form_state. After the form is rebuilt, it works fine. For instance, if you had a button that just saves and returns the form in ctools, then on the next save/submit, the value is saved.
Is anyone seeing this as well? I don't want to knock this out of RTBC if I can't reproduce that issue.
#97
#91 works fine so far for me too.
+1
#98
Sadly, I'm definitely seeing an issue with core ajaxSubmit and putting ckeditor wysiwyg in a ctools modal. If I add the following javascript to misc/ajax.js line 254, then it works, but without it, ckeditor.js does not update in time. I think this is because Drupal ajax is binding way late in the process.
Does anyone have any tips for solving this bug and getting updateElement() to fire before ajaxSubmit?
for (instance in CKEDITOR.instances) {CKEDITOR.instances[instance].updateElement();
}
#99
This does not seem like the right way to do things:
$(document).ready(function() {window.setInterval(function() {
for (instance in CKEDITOR.instances) {
CKEDITOR.instances[instance].updateElement();
}
}, 500);
});
#100
Sorry to break the flow, but most of the above is beyond my technical expertise. I came here from #97 on the Textareas issue. I'm experiencing the exact same problem described there:
I was hoping someone could indicate to me if any progress on fixing this has been made. I know of the wysiwyg_panels module, but because it's not available on Drupal.org I'm hesitant to use it, and would prefer a fix in the Wysiwyg module itself. Thanks!
#101
Try decreasing z-index for those dialogs?
#102
91 works for fixing the broken CKEditor+WYSIWYG with Panel popups.
#103
The ckeditor div.cke_kama is a sibling of modalContent so it's child, div.cke_rcombopanel, is outside of modalContent as well. On OSX Firefox 10 this means that you can't click on any item in the combo box.
#104
@DanielF, @mradcliffe: Perhaps something to do with #905546: modalContent focus?
#105
My issue was apparently a Flash issue because I had a flash object on the page and a modal above that with WYSIWYG (ckeditor). Strange bug that also had an effect on Firebug.
#106
#91 worked me too. Thanks!
#107
Review comment #92 and patch #91
Edit: I forgot to change this back to needs review after I discovered the issue with Flash.
#108
#91 works... Thanks!
#109
Here is a quick reroll of #91 for the -p0 standard. No other changes have been made.
#110
Patch on #109 works fine
#111
Here's a table of testing if anyone else wants to confirm "works for me" status. I have the following tested for ckeditor.
#112
TinyMCE seems to have an issue with the 91 patch, but CKEditor seems to be lazy loading fine. The problem I found with TinyMCE is that when you hit save in a modal, it loads the AJAX request text into the actual browser window (tested in Chrome) and doesn't redirect back to the Panels interface.
It does seem to save though... if I refresh then the content is changed to whatever I made it in the TinyMCE modal edit window.
#113
@112: This might be an issue with either not having the ctools detach behavior.
Edit: I can't reproduce this in a simple ctools modal loading tinymce in Safari Windows or Firefox 11 or IE8. Clicking Save works properly.
#114
Here are the screenshots of what I was experiencing in #112, aftersave shows the text loaded inside Chrome.
#115
I'll try in Google Chrome on Windows tomorrow. Need to install it first. Google Chrome in OSX works fine in both panels and in custom ctools modals.
Do you get the same problem with this custom module (it exposes a menu item in the navigation menu)?
#116
I just tested my test module and in panels with latest Chrome in Windows XP. I could not reproduce the issue you ran into with either tinymce or ckeditor, vilepickle.
Any IE9 testers out there?
#117
Patch #109 fixed mine.
#118
Juan C, what browsers did you test the patch in? Can you add any more confirmation for the testing matrix?
#119
I've been trying to debug the TinyMCE related changes from the #109 patch in Chrome (under Ubuntu) by opening the node edit form in a CTools modal dialong - which I originally created to test #947676: Support new CTools event for detaching when the modal closes.
The reason TinyMCE doesn't work seems to be that its theme doesn't get registered properly when its script file is loaded.
For some strange reason, inspecting TinyMCE's ThemeManager right after the theme script registers itself does show that the theme was added to
tinymce.ThemeManager.lookup, but when inspecting it from other scopes it's no longer there.It only happens the first time TinyMCE is rendered. Subsequent calls to the render() method does correctly register the theme so the rest of TinyMCE sees it.
It's really difficult to debug this with the tools in Chrome because it sometimes completely skips over calls into dynamically loaded scripts even if there are breakpoints in there, so one has to rely on
console.log()calls...#120
Tested on OSX: Safari, Firefox, and Chrome.
Update: Using ckeditor
#121
I've tested the patch in #109 with panels only and it globally works really well. With ckeditor (3.6.2.7275) everything is perfect, but for TinyMCE (3.5.0.1) I had a this little error when submitting a form.
Uncaught TypeError: Cannot call method 'replace' of undefinedDrupal.wysiwyg.editor.attach.tinymce (content:86)
...
It appears that the Drupal.wysiwyg.editor.attach.tinymce function is called when the modal is closed but the dom element is removed. This is called from Drupal.behaviors.attachWysiwyg, by looking at Drupal.settings.wysiwyg.triggers[this.id].
Simply adding a 'delete' inside the detach function seems to do the trick, but I'm not sure if this can create other issues. So the only difference with patch in #109 is one extra line in Drupal.behaviors.attachWysiwyg.detach:
Drupal.behaviors.attachWysiwyg = {...
detach: function (context, settings) {
$('.wysiwyg', context).removeOnce('wysiwyg', function () {
var params = Drupal.settings.wysiwyg.triggers[this.id];
Drupal.wysiwygDetach(context, params);
+ delete Drupal.settings.wysiwyg.triggers[this.id];
});
...
I did the test with these browsers:
mac: firefox 12 / opera 11.64 / safari 5.1.5 / chrome 19
windows: ie7 / ie8 / chrome 19
#122
I wanted to test the patch from #121 with the custom test module in #115 but the modal content was empty. Here is an updated version. I've tested it with chrome on windows and mac and I had exactly the same error as described in #121. Here too, the "delete" looks enough to fix that.
#123
Hi Guys, Anyone have latest wysiwyg with patch for ckeditor already added?
Thanks a lot in advance for posting if you have it.
greetings, Martijn