WYMeditor filter works inconsistently

Ruby Apps Radiant CMS
1

I’m curious whether anyone has been successful with the WYMeditor
extension. I read the January thread regarding how to get drag & drop
working with page_attachments, and thought I would give it a try.

I installed the extension from the svn trunk (see
http://wiki.radiantcms.org/Thirdparty_Extensions and
SumoCoders, geeks coding with body )

on my test machine, my laptop running Fedora Core 4, radiant Rev 631,
lighttpd 1.4.11, extensions back_door 0.4.2 (tag), copy_move 1.9.1
(trunk), shards 0.3 (trunk), language_redirect 0.2.1 (trunk).

I did not make any of the page_attachments mods to permit d&d with
images.

I found that I could edit pages in WYMeditor, which does look cool by
the way, but that my results were inconsistent at best. Many times I
would save my page only to find that my edits were not saved. Sometimes
my edits were saved. I tried several different browsers to see if was
something wrong with my ‘normal’ Firefox 1.5 on Fedora; I also tried
Firefox 2.something on both Mac OS X & Windows XP. I also used those
same browsers on the WYMeditor demo ( http://demo.wymeditor.org/ )
without success.

One idea that occurs to me is that in the wymeditor external in the
extension I might need to freeze its reference to something other than
the trunk on wymeditor, but I’ve not anything to investigate it.

I’m somewhat at a loss. I think it would be a very cool thing to give to
my current client, but it’s too frustrating to use in its current state.

Perhaps I’ve overlooked something… Thank you for any advice.

Bill

2

Bill B. wrote:

I found that I could edit pages in WYMeditor, which does look cool by
the way, but that my results were inconsistent at best. Many times I
would save my page only to find that my edits were not saved. Sometimes
my edits were saved. I tried several different browsers to see if was
something wrong with my ‘normal’ Firefox 1.5 on Fedora; I also tried
Firefox 2.something on both Mac OS X & Windows XP. I also used those
same browsers on the WYMeditor demo ( http://demo.wymeditor.org/ )
without success.

Sorry Bill, I have not experienced any data inconsistencies with
WYMeditor. Are you saying that every browser you tried had inconsistent
saving?

3

On Mon, 2008-02-11 at 20:56 +0100, David P. wrote:

Sorry Bill, I have not experienced any data inconsistencies with
WYMeditor. Are you saying that every browser you tried had inconsistent
saving?

That is correct. I tried most with the Firefox 1.5 browser running on
the same laptop as the test server. I ran only a few tests using Firefox
2 on OS X & XP before giving up. Each browser failed to save an edited
page most of the time; only occasionally was the page saved.

It’s very curious; I’m much more accustomed to finding a complete
failure which is then fixed by something I overlooked, or by finding &
fixing a bug.

Thanks!

Bill

4

think i know what your problem is…

when you turn off WYM, you should first ‘save and continue editing’,
then do your edits and save as normal. This is not the case when you go
from none-wym to wym.

the why; when WYM is booted, it hides the original textarea, and injects
a whole new divs structure with also a new textarea. There is a hook on
the page submit button that copies the content of this newly injected
textarea to the original one, so that those contents are sent to the db.

When WYM is disabled, it removes the editor, and puts back the original
textarea, but the hook on the submit button is still present. Thus, when
you click submit, it again sends the data from the injected textarea to
the default radiant one. As the injected textarea only holds the
contents that were there before you turned off wym, you lose all the
edits since switching off WYM.

I’ve been aware of this, but got so used to it that i forgot to
mention…

fixing this has been on my to-do list for quite a while, but that list
grows faster than it shrinks…, i bet you know how it goes :slight_smile:

if anyone feels like helping out, i’d be more than glad to add you patch
to my repository and give credit for it. What needs to happen is that in
the unboot_wym funtion (in radiant.wymeditor.js) needs to also remove
the hook (class name) on the submit button.

about the wymeditor.org demo; afaik you’re not supposed to be able to
actually save those contents…

regards,

Benny

5

On Tue, 2008-02-12 at 09:32 -0800, Bill B. wrote:

I may try this again in a cleaner test environment - one that has only
Radiant, Shards, and WYMeditor. If that works okay, then I can look for
other causes.

I installed WYMeditor on a vanilla radiant instance, running the demo,
and only the shards extension. I am able to get consistent behavior (I
think) while editing a brand new file in the WYMeditor filter.

But the behavior seems a bit weird to me. I can always save my edits if
I conclude my editing session with a click on one of the “Containers >
container_type” selections in the WYM editing area upper right. If I
don’t conclude with one of these clicks, then my edits are not saved.

I will reinstall WYM on my test cms with copy_move, page_attachments,
and back_door installed and see whether I observe the same behavior.

So is this normal? Is it a bug? Am I missing something?

I may delve into the code a little, but of course I was hoping not to…

Thanks! Bill

6

Hi Benny,

Thanks for your response, and of course for sharing your work on this
extension.

On Tue, 2008-02-12 at 10:53 +0100, Benny D. wrote:

think i know what your problem is…

when you turn off WYM, you should first ‘save and continue editing’,
then do your edits and save as normal. This is not the case when you go
from none-wym to wym.

I wish that was what was happening for me… I started by creating a new
page with WYM, and adding content to that. I found that I could add
content to an existing

container, but that both “save” and “save and
continue editing” would not always save the new content. So saves
sometimes worked, and sometimes didn’t. It was very weird.

I messed about for a while trying to find some pattern to the “worked”
and “didn’t work” modes, but failed to do so. This makes it hard for me
to write a useful bug report, and instead makes me suspect something is
flakey in my environment; I just don’t see what the flakey thing is…

I may try this again in a cleaner test environment - one that has only
Radiant, Shards, and WYMeditor. If that works okay, then I can look for
other causes.

I’d love to be able to give WYM to my users. They are doing okay with
Textile, but they don’t want to think about their content in that way.

fixing this has been on my to-do list for quite a while, but that list
grows faster than it shrinks…, i bet you know how it goes :slight_smile:

Yes I do know how that is!

about the wymeditor.org demo; afaik you’re not supposed to be able to
actually save those contents…

I suspected that might be the case…

Bill

7

Thanks for the quick response!

On Thu, 2008-02-14 at 01:25 +0100, Benny D. wrote:

Hmm no this is far from normal…

Okay - that’s really good to know. I can continue to pursue this
solution without feeling silly for trying…

It seems like a JS issue, but at the moment i don’t have a clue what
causes it…
I’m on the same environment as you are (firefox 2 on OSX), and i know
for sure the filter also works on many other environments, so i don’t
think that’s where the problem lies…

Actually, I’m most commonly running firefox 1.5 on Linux. When I first
began working on this I tried using firefox 2 from OSX as the client,
but with lighttpd & rails running on my Linux laptop.

Could you perhaps set up an online instance, so i can have a look around
myself?

This is a good idea. I’ll set up a test environment at my host, the
estimable Dreamhost. Of course that’s running FastCGI on Apache, but
I’ve found my test environment to be mostly equivalent. I’ll let you
know when I have the thing working.

Thanks!
Bill

8

Hmm no this is far from normal…

It seems like a JS issue, but at the moment i don’t have a clue what
causes it…
I’m on the same environment as you are (firefox 2 on OSX), and i know
for sure the filter also works on many other environments, so i don’t
think that’s where the problem lies…

Could you perhaps set up an online instance, so i can have a look around
myself?

9

I wanted to follow up on the issue I had with the WYMeditor filter from
2-1/2 weeks ago. See
http://lists.radiantcms.org/pipermail/radiant/2008-February/007773.html

Benny D. looked at an online instance I set up of WYMEditor
filter running with the Radiant demo version and checked the diffs in
the public/wymeditor tree. It turned out that his svn:external for the
WYMeditor itself was pulling its code directly from the trunk; this
caused the weird behavior I saw.

So here’s what Benny did in his own repository - he constrained the
svn:externals to the proper revision to work with his own code. So if
you check out or export the WYMeditor filter from his repository you
should also get the correct revision of WYMeditor. For the record,
here’s how it looks from the root of his extension in
vendor/extensions/wym_editor_filter:

billb@lyell wym_editor_filter $ svn propget svn:externals public
wymeditor -r 465 svn://svn.wymeditor.org/wymeditor/trunk/src

Since that time I’ve been careful to constrain all the svn:externals in
my project to so that changes in their trunks don’t cause breakage in my
own project.

Thanks for the help Benny!

Bill

10

Bill B. wrote:

I wanted to follow up on the issue I had with the WYMeditor filter from
2-1/2 weeks ago. See
http://lists.radiantcms.org/pipermail/radiant/2008-February/007773.html

So here’s what Benny did in his own repository - he constrained the
svn:externals to the proper revision to work with his own code. So if
you check out or export the WYMeditor filter from his repository you
should also get the correct revision of WYMeditor.

Thanks for solving this and letting us know the issue has been fixed.