This bug has already been reported by myself and marked as "closed" but it is still here in the DEVELOP version.
Here is a test case :
1) attach a picture with the normal way to do it : press the attach button, select a file, check the lake link box, ok.
2) Try to edit the page with the wysiwyg editor.
The picture is not displayed.
This problem arises another one : the wysiwyg editor produces static links when pictures or files are attached from within the editor. This is not the right way to do it. If one moves changes the server name, everything will be broken.
All the variables referring to local attachment, %WEB%, %TOPIC% etc... should be translated both ways.
This also breaks sites that have more than one URL to access content, such as http... if behind firewall and https... if outside.
No it doesn't. Bidirectional translation is achieved by asking TWiki to provide a template URL and then using that template to match the URI for un-translation. As long as this template matches the URI generated by %ATTACHURL% there is no problem. This includes URLs generated by adding attachments; as long as the URI root matches the template, they will get converted to variables.
The problem Michel is actually reporting is that https://develop.twiki.org/pub/Bugs/Item1042
is not expanded when the editor is opened. This is because % vars are protected from the editor, and is a different
problem to the one reported before (it has to be; I only added this functionality recently!).
We will have to make a "special case" for https://develop.twiki.org/pub/Bugs/Item1042
, and possibly some other variables.
It will never be perfect, just because of the way that TWiki works; it is very difficult to reliably detect where the user intended an image to be used, as against any other kind of link. TWiki does all sorts of nasty context-sensitive tricks in the background that could be copied, but I'm really questioning the value.
So, the full URL gets expanded, but there is no "implied image insertion".