When I tried the WYSIWYG editor I was prompted to logn. After that, the editor showed up normally, but the topic content included the classic skin header and footer. See screen shot. Saving the topic showed the classci skin header and footer embedded in the topic text.

I edited without WYSIWYG and removed the header & footer, then re-edited with WYSIWYG. This time it was OK. I think it has to do with login. I recall that I previously have seen a strange screen after login prompt.

This should be an "Urgent" item, but I leave this as "Normal" only because of release timing.

-- PTh

This need more detail to be reproducible, apparently no problems in naive testing. Any special content in edited topic?

Tested with classic skin setting in topic and in preferences, and with template login / htpasswduser.

-- SP

Here's what might be happening. The WysiwygPlugin works by rendering the edit template, which contains an empty IFRAME. This IFRAME loads the URL .../view/Web/Topic?skin=kupu&wysiwyg_edit=1. Now, assume that the edit template can be loaded without triggering an access control violation (ACV). But then, when the IFRAME loads the view URL, there is an ACV. This will trigger the webserver login process. When this process completes, it is supposed to redirect to the URL that caused the ACV in the first place. Let's say it doesn't; let's say that instead, the URL gets corrupted and the skin=kupu parameter is lost. In this case, the default template version of the topic will be recovered, which can easily be mistaken for classic skin.

CC

This happened here on develop.twiki.org on Sandbox.PlayWithMe. I forgot to attach the screenshot, now it is. I tried to reproduce by logging out, then WYSIWYG editing the topic Sandbox.WysiwygTesting (which caused the ACV), but I could not reproduce the bug. This might have been wrong timing, caused by the automated SVN update of this TWiki?

-- PTh

Not sure if this is exactly the same issue, but I got the same symptom due to a rewrite rule as per TWiki:Codev.ShorterURLs. Mod_rewrite seems to default to escaping the & character. I fixed it by adding a NE parameter to the RewriteRule line.

-- TWiki:Main.MartinRothbaum

The rewrite rule issue is a different problem, that should be noted in the documentation web on TWiki.org. I have tried all sorts of ways to reproduce what peter desccribed, and I can't. Given how often we see problems during updates on this site, I have to assume that is the cause and close this, pending a reproducible report.

CC