SID-01825: WYSIWYG editor changes text that it should not
| Status: |
Answered |
TWiki version: |
6.0.0 |
Perl version: |
This is perl, v5.10.0 built for i686-linux-thread-multi |
| Category: |
CategoryEditing |
Server OS: |
Ubuntu linux 2.6.20-15-serve i686 |
Last update: |
12 years ago |
I have a very simple TWiki topic that contains a single line, which I created using the raw editor (
not WYSIWYG):
This topic contains nothing but a link to the !TWiki [[http://twiki.mycompany.com/wiki/bin/configure][configure]] page.
If I then use the WYSIWYG editor to add another line, and do
NOT touch the line containing the fully qualified URL to the Configure page, the URL nevertheless gets replaced so that, using "raw view" the topic now contains:
This topic contains nothing but a link to the !TWiki [[bin.configure][configure]] page.
And this sentence.
So, I added the "And this sentence." But notice that the original URL for Configure has been replaced by "bin.configure".
What's up with that? It calls into question every edit we've ever done with the WYSIWYG editor. How many other things has it silently changed without our being aware of it?
--
Barry Lake - 2013-11-16
Discussion and Answer
Does not look good. In any case, I recommend using SCRIPTURL instead of hard-coded URL. This allows you to move TWiki content to another domain (for testing, upgrade, archive, company acquisition) without breaking links. If you feel like you can submit a bug at
TWikibug:WebHome
.
Test, source:
* [[http://google.com/][Google]]
* [[%SCRIPTURL{configure}%/%WEB%/%TOPIC%][TWiki.org with SCRIPTURL & Web/Topic]]
* [[http://twiki.org/cgi-bin/configure/%WEB%/%TOPIC%][TWiki.org with absolute URL & Web/Topic]]
* [[http://twiki.org/cgi-bin/configure][TWiki.org with absolute URL, no Web/Topic]]
Result, after WYSIWYG edit:
--
Peter Thoeny - 2013-11-16
Result, verbatim:
* [[http://google.com/][Google]]
* [[%SCRIPTURL{configure}%/Support/SID-01825][TWiki.org with SCRIPTURL & Web/Topic]]
* [[%SCRIPTURL%/configure/Support/SID-01825][TWiki.org with absolute URL & Web/Topic]]
* [[%SCRIPTURL%/configure][TWiki.org with absolute URL, no Web/Topic]]
So, different result, but at least it does not break the URL. The
%SCRIPTURL{configure}% survives the WYSIWYG edit properly.
--
Peter Thoeny - 2013-11-16
Thanks for the reply. I have filed a bug report as you suggested:
Item7383
Also, thanks for confirming that you have observed this incorrect behavior, too. Finally, thanks for the work-around solution. However, I have a few issues with it.
1) It may be easy enough to retrain all my users to employ SCRIPTURL whenever they create any future content. But whenever we edit existing content, we will now have to scan the entire topic for instances of hard-coded URLs, even if they appear in areas of the topic we wouldn't otherwise be editing, and fix those too. That adds a fair amount of extra work to
every Twiki edit we perform from now on. This kind of detracts from the ease of use, and pleasure in using Twiki software.
2) We happen to have noticed this behavior after our upgrade to Twiki 6.0. But we don't really know how long this has been going on. Perhaps the WYSIWYG editor has been damaging our content for years. We don't have an easy way to test earlier versions of Twiki, do you? So, given that this problem may have existed for some time, the very real possibility exists that many of our topics have been changed incorrectly by WYSIWYG. So we're faced with the daunting task of figuring out A) if this has happened; B) If so, to which topic; and C) how to fix the problem?
3) Given that we may have many hard-coded URL's in our content, and given that we may not be able to rely on all users to follow the guidelines as I described in #1, we may be faced with having to locate all such URLs and fixing them manually.
4) Really this is the main issue, and should probably be #1: Why in the world would the WYSIWYG editor go out of its way to change areas of a topic that are not being edited by the user?
Any editor, not just the WYSIWYG editor, should make exactly the changes entered by the user and do
nothing else.
I have seen this problem, and so have you. So I think it's fair to assume that
any TWiki user out there might also see it. This problem could be affecting literally hundreds or thousands of web sites. I would think that a problem of this nature would instantly rise to the top of your "fix it now" stack. I'm glad there's a potential work-around, but I'd think that this problem must ultimately be fixed, and the sooner the better.
--
Barry Lake - 2013-11-18
As an open source project we depend on users to support the community. If you feel that this requires some TLC you could sponsor the work.
As for fixing existing content, you could install the
GlobalReplacePlugin and do a global search & replace. Attention, this plugin can damage content on user error, so best to do this after a backup.
--
Peter Thoeny - 2013-11-19
If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.