Multiple WYMeditor instances / onClick update() issues

[mark_ndg]

I have been in the process of migrating a CMS from TinyMCE to WYMeditor, and I encountered a couple of issues I would like to get some input on.

The first issue is that there seems to be- in my particular case, anyway- some irregularity in the calling of wymeditor.update() when the form is submitted. I have an instance of WYMeditor on the page, and the form submit button is given the default updateSelector class of "wymupdate", and the default updateEvent of "click". Frequently, however, the update() method will not be called prior to the form being submitted, and thus any changes to the text field are not saved to the database. Browsing the forums and various other sites, it appears to me to be an issue with the 'click' event itself, and that 'mousedown' seems to be the preferred updateEvent, as it seems to fire a few milliseconds sooner than 'click'. ('mousedown' fires immediately upon pressing the mouse button, while 'click' does not fire until the button is released, so that is likely the reason for the difference)

The second issue I encountered was that there are pages in the CMS that require multiple instances of WYMeditor in the same form. When the form is submitted (regardless of whether the aforementioned updateEvent is changed), only one of the WYMeditor instances will have its update() method called. Which particular instance seems to be determined randomly. My suspicion is that there is some sort of conflict occurring when multiple WYMeditor instances attempt to bind their own update() method to a single submit button's 'click'/'mousedown' event, and that the multiple editors are essentially "fighting for supremacy". My experience with jQuery is quite limited, so my attempts to debug this have been meagre at best.
All the documentation I have been able to find regarding multiple WYMeditor instances on a single page seem to place each instance in its own form, with each editor bound to its own form's submit button. Is there any documentation regarding multiple instances in a single form? Should some be created if there is not? Searching the forms found various users with similar issues, but none that I could find the same as mine.

I was able to kill both of these birds with a single stone, by creating a custom function bound to my form submit button's 'mousedown' event, which iterates through WYMeditor.INSTANCES and explicitly calls the update() method for each, however that is not quite as graceful as being able to define everything in a single configuration.
I am curious as to whether this as been documented as an official bug (or whether it is indeed a bug at all, or rather some flaw in my implementation that I haven't caught on to yet). I didn't find anything in the trac, but I'm not entirely sure what I would even be looking for.

I am using the latest release as of this posting, 0.5b2.

I would appreciate any input that could be provided. If this has indeed been answered somewhere else, please point me in the right direction.

[eadevel]

I use multiple instances in several pages and have had no problem. But then again the default updateEvent has been working fine for me...

Try to do the following debug to check if there's some issue with your browser.

<script type="text/javascript>
function iterateUpdate() {
alert($.wymeditors(0).xhtml());
alert($.wymeditors(1).xhtml());
return false;
}
</script>
<form onsubmit="iterateUpdate();">
<textarea>text 1</textarea>
<textarea>text 2</textarea>
<button class="wymupdate" type="submit">test</button>
</form>

[mark_ndg]

Thanks for the response.

I ran the test you provided, and the xhtml returned does return the expected value, whatever was entered into the RTE. However, the changes still are not saved. Repeating the same test, only displaying the value of the textareas themselves, rather than the wymeditor windows, do not return the expected contents, but rather whatever was contained in the textarea on page load.

[eadevel]

What are you using server side? PHP? If so can you do a var_dump($_POST)?

[mark_ndg]

PHP5, yes. And a dump of $_POST returns the same result- the value of the textarea is whatever it was the last time update() was called, not what the WYMeditor window contained when the form was submitted.

Two things I neglected to mention in the initial post:
- I placed an alert('Updated!') directly into the update() method in the wymeditor core JS file, and it does not always appear when the form is submitted. That is what lead me to conclude that it is the update() method itself that is not firing.
- While the occurrence of the update() issue is seemingly random, I can force it to occur by clearing my browser's cache and refreshing the page before editing and submitting the form.

[eadevel]

Well... that's really weird...
Try changing the iterateUpdate function and update through iteration:
function iterateUpdate() {
for (i in WYMeditor.INSTANCES)
WYMeditor.INSTANCES[i].update();
return true;
}

If that doesn't work, try adding the following in top of your form page:
header("Expires: Mon, 20 Dec 1998 01:00:00 GMT");
header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");
header("Cache-Control: no-cache, must-revalidate");
header("Pragma: no-cache");

Have you tried different browsers?

[mark_ndg]

Yeah. That is essentially what the solution I mentioned in the intial post was- I created a function that updates the wymeditor instances through iteration, and tied it to the 'mousedown', rather than 'click' event of the form submit button. And that seems to have solved both of my issues.

I've tested this issue in Firefox 3.0.5 in Linux(Fedora 10), as well as IE6/IE7 in Windows XP, and encountered it in all three.

Regardless, the fix I mentioned before does seem to have solved the problems, but I thought they were bizarre enough to mention here.

Thanks for your help.

My final solution for both problems, if anyone else encounters this:
(included as its own .js file)

Code: Select all

jQuery(document).ready(function()
{
   jQuery('.wymupdate').mousedown(function()
   {
        c = WYMeditor.INSTANCES.length;
        for(i = 0; i < c; i++)
          jQuery.wymeditors(i).update();
   });
});

[mr_lundis]

Hi!

WYMeditor should be able to handle this internally, see the customization page on the wiki for more information.

http://trac.wymeditor.org/trac/wiki/0.5 ... pdateEvent

If the problem still remains I'd suggest you to post a ticket at the Trac site.

Cheers!

[eadevel]

One last thing that comes to my mind is the version of jquery.
Could you try the latest stable (1.3.1) and the latest "tested" (1.2.6)? Just to make sure it's wymeditor related..

[mark_ndg]

I just tried it with version 1.3.1 of jQuery, no change in behaviour. I had been using 1.2.6 initially.

I have created a trac ticket for each of these issues:
https://trac.wymeditor.org/trac/ticket/149
https://trac.wymeditor.org/trac/ticket/150

Thanks again for your help.

[cookiemonster]

I'm using WYM with Django's admin system and have also been having this exact problem throughout all browsers. I thought it might be my jQuery, tried different versions including the jQuery it came bundled with, no luck.

[mark_ndg]

I guess that means I'm not alone in this problem then. Did you give the fix I posted further up the topic a try? That may work for you as well.

[cookiemonster]

Yup thanks, using your fix at the moment. Also noticed, my single instances don't save correctly all the time either...

[mr_lundis]

Yup thanks, using your fix at the moment. Also noticed, my single instances don't save correctly all the time either...

Unless you use a custom updateSelector/Event you'll need to add the class "wymupdate" to your submit button, otherwise WYMeditor won't know when to update the replaced textarea. If you've done this and still can't get things to work, then set up a test page (or at least post some code) so that the rest of us can take a look.

Cheers