Item1396: Anchors and Links are not handled by WysiwygPlugin

Links should be displayed as links in the editor just as well. Today there is an ugly reformatting, that disturbs inexperienced users.

See this video for a demonstration.

Sample code

Test 2.7
www.bmw.de
BMW
Anchor

Information about the tested instances and browser

Testing environments:

Browser:

---

I accept that is incorrect, and is a problem in the WysiwygPlugin. Confirmed.

-- CrawfordCurrie - 02 Apr 2009

Ok, we know link handling sucks at the moment - it does need to be shinier - but we are all aware of this and will hopefully get better link dialogues/inline link support eventually.

Re-titling this to something more bug-like, and that's the anchor handling

And set to MichaelTempest in case he has some ideas

-- PaulHarvey - 25 Jun 2010

There are several problems here:

1. square-bracketed links are not rendered correctly
   • This could be fixed now (at least for simple cases), in TML2HTML
2. If you enter square-bracket text (e.g. [[link]]) and apply a link in TMCE, you get junk like this: [[http://google.co.za][google]]
   • This could be fixed now, in HTML2TML
3. Once you create an anchor in TMCE, you cannot edit it
   • This needs javascript stuff in TMCE
4. Anchors are not converted to TML-style anchors if the anchor name is a wikiword
   • This could be fixed now, in HTML2TML
5. HTML anchors and TML-style anchors are not rendered as anchor-images, like those created by TMCE
   • This could be fixed now, in TML2HTML, but there is no point in doing so until TMCE can edit anchors

I have removed myself from waiting-for.

-- MichaelTempest - 26 Jun 2010

I think I have the solution for cases 1, 3, 4, 5. Case 2 seems to need another fix, in HTML2TML to not convert to square brackets notation links that have [ or ] in their labels, but somehow "mark" them to be re-emitted as unprotected A tags for TML2HTML to feed them raw to the WYSIWYG editor to handle them properly.

The trick should be in TML2HTML to convert the [[...][...]] to HTML anchors, but not protect them, so that TMCE can edit them. This fixes the main pain point which is that novices were unable to edit links they created in TMCE.

I will run the attached patch LinkEditingInWysiwyg-1.patch in production for some time to see if there is no ill side effects

-- ColasNahaboo - 26 Feb 2012

Great! Set WaitingFor myself so I don't forget (I've been preparing some major WYSIWYG work for the last few weekends).

-- PaulHarvey - 26 Feb 2012

While I was on it, I made a second patch LinkEditingInWysiwyg-2.patch for case 2, that will quote square brackets entered in links in TMCE so that we will be able to re-edit them. [ and ] are quoted as %5B and %5D in the href part, and as HTML entities in the text.

-- ColasNahaboo - 26 Feb 2012

After some stress tests by novices of patches 1&2, the only issue found has been a corruption at edition of links generated for attachments in wiki text. Macros in [[...][...]] messes things up. Should not be hard to fix, will have a go at it tonight...

-- ColasNahaboo - 28 Feb 2012

Great - given that you have svn commit access, are you happy to commit? But before you do, I'll do some work on the weekend to adjust the tests (and add some new ones)

And while we're at it, I need to see if this work can help close Item10089

-- PaulHarvey - 28 Feb 2012

Ok, fixed. To test, just apply patch LinkEditingInWysiwyg-3.patch (remove the 2 patches above if you added them before). I now have understood the liftout / dropback routine to protect properly tags and was able to shield the [[...][...]] expression early on.

For Item10089 I guess my code will help and maybe solve it.

I will test a bit again to be sure it does not break anything else before commiting.

Ideas for improvement: now that I understand better the code (great code btw, kudos to Crawford), I guess I will try to make the WYSIWYG editor understand all anchors that it can produce, that is not only square brackets, but anchors with attributes TARGET, TITLE, and CLASS that are settable and editable in the editing popup.

-- ColasNahaboo - 28 Feb 2012

LinkEditingInWysiwyg-4.patch new version that let anchor links untouched if they only have attributes HREF, TARGET, TITLE, and CLASS and thus are properly seen as html links by the editor, and be edited via its link pop-up. Others will be seen as "sticky" html verbatom in the editor, as before.

I will test it in production the rest of the week before commiting.

-- ColasNahaboo - 29 Feb 2012

Colas, I've applied your latest patch to Foswiki 1.2, and it seems to work fine. It breaks a couple of unit tests but in expected ways, so I can fix them.

If you have any examples of links that should be Sticky, vs. rendered as TML, I'll try to add them to the unit tests.

Any objections to my checking this patch in? There is also a patch in Item10082 which appears to try to accomplish similar things. But it breaks a lot more unit tests.

-- GeorgeClark - 22 Apr 2012

These patches have been working work fine at work & home, I have seen no problems. Didnt had time yet to manage to set up a foswiki dev env to commit them in foswiki svn, so I am really glad you incorporated them. Patches in Item10082 cannot work as you have to move part of the link-handling logic earlier in the processing to protect the translation of square bracket TML notation into html A tags intended for WYSIWYG editor handling before the handling of A tags kicks in and "quotes" them.

On exemples of what should keep sticky: A tags with ID or STYLE attributes. A useful unit test would be the links generated by ATTACHing files, e.g: [[%ATTACHURL%/LinkEditingInWysiwyg-4.patch][LinkEditingInWysiwyg-4.patch]] this was broken by an early version of the patch.

-- ColasNahaboo - 22 Apr 2012

I've found one small issue. A link with styled link text ends up as uninterpreted TML in the next editing pass.

• Create a TML link

  [[Main.WebHome][A <b>BOLD</b> WebHome]]

• Edit with TMCE, it is properly rendered. with BOLD in bold
• Save, It is converted to

  [[Main.WebHome][A *BOLD* WebHome]]

• Edit again, and the link is displayed as *BOLD* using asterisks, and not html bold markup.

-- GeorgeClark - 22 Apr 2012

Patches are checked in to trunk. Also added unit tests, and added support for markup in the link text. This could probably go into 1.1.6, so setting to NeedsMerge.

-- GeorgeClark - 24 Apr 2012

I think I have fixed the bug. Quick tests here seem to work, but this code should be exercised more to be sure. One line fix is to let TML2HTML convert the TML code in TEXT in the notation

[[HREF][TEXT]]

whereas patch 4 was not converting it. I provide 2 forms of the patch:

• LinkEditingInWysiwyg-5.patch: Combined patch, replaces 1 to 4 for applying to a vanilla 1.1.5 distrib
• LinkEditingInWysiwyg-4-5.patch: Incremental patch from 4 to 5 for applying over patch 4

-- ColasNahaboo - 01 May 2012