28 Jun
2012
28 Jun
'12
8:28 p.m.
When editing an Xwiki page and choosing the WYSIWYG option instead of showing
the editor it takes the user to a blank HTML cache page in
/xwiki/resources/js/xwiki/xwe/*.cache.html.
Do any of you know the cause of this and/or how to fix such?
--
View this message in context:
http://xwiki.475771.n2.nabble.com/WYSIWYG-goes-to-cache-instead-of-opening-…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
28 Jun
28 Jun
11:19 p.m.
New subject: [xwiki-devs] WYSIWYG goes to cache instead of opening the editor?
On 06/28/2012 02:28 PM, echocoder wrote:
When editing an Xwiki page and choosing the WYSIWYG
option instead of showing
the editor it takes the user to a blank HTML cache page in
/xwiki/resources/js/xwiki/xwe/*.cache.html.
Do any of you know the cause of this and/or how to fix such?
Are you sure this is what's happening? It is normal for the WYSIWYG to
load some resources like xwe/*.cache.html, since those implement the
actual functionality of the WYSIWYG (they're compiled GWT code), but it
should load via an XHR something like
/xwiki/bin/edit/Space/Page?xpage=wysiwyginput&token=1fxAIU1MxkGTY9MqrON3oA
which is the actual content that is supposed to be displayed in the
editable area.
Note that not every page is editable in WYSIWYG mode. Documents that are
supposed to be edited in "Inline mode", as a form, should only be edited
in inline mode, since they don't really have a content that's supposed
to be edited, they have objects displayed by sheets. For example, it's
normal to get a blank WYSIWYG when trying to edit blog posts or users.
To check that the WYSIWYG works, try editing a document from the
sandbox; if that doesn't work, then you might have a real bug, in which
case some more details are required: what browser, what operating
system, what version of XWiki are you using.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
30 Jun
30 Jun
2:49 a.m.
New subject: [xwiki-devs] WYSIWYG goes to cache instead of opening the editor?
Thank you for your quick reponse, Sergiu!
I am able to edit the WebHome page perfectly fine via wysiwyg.
/xwiki/bin/edit/Main/WebHome?&editor=wysiwyg
Then editing a page within a user defined space via wysiwyg goes to a blank
cache.html file. However, I can click the back arrow on the browser a few
times and it allows me to load the page in the wysiwyg editor.
The blank page URL is:
/xwiki/resources/js/xwiki/wysiwyg/xwe/ADF3814286AF82911EECBC7DB34EA9C0.cache.html
---
What I have noticed is that the pages where I have this problem do not
display a submenu when the mouse hovers over Edit.
Also, it may be worth noting that these pages also include content from
other Xwiki pages (custom menus) using the {{include document}} syntax.
Each of these pages contain the following html block (which I am starting to
think may be the culprit):
{{html}}
{{/html}}
---
I am using Windows 7 Ultimate on my client PC and Windows 2003 Enterprise on
the server that handles Xwiki.
Apache Tomcat 5.5.33
JVM 1.6.0_25-b06
Xwiki version=2.7.33656
Apache 2.2.19
Mod_ssl 2.2.9
OpenSSSL 0.9.8
Mod_jk 1.2.25
--
View this message in context:
http://xwiki.475771.n2.nabble.com/WYSIWYG-goes-to-cache-instead-of-opening-…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
2 Jul
2 Jul
7:51 a.m.
New subject: [xwiki-devs] WYSIWYG goes to cache instead of opening the editor?
On Sat, Jun 30, 2012 at 3:49 AM, echocoder <echocoder(a)gmail.com> wrote:
Thank you for your quick reponse, Sergiu!
I am able to edit the WebHome page perfectly fine via wysiwyg.
/xwiki/bin/edit/Main/WebHome?&editor=wysiwyg
Then editing a page within a user defined space via wysiwyg goes to a blank
cache.html file. However, I can click the back arrow on the browser a few
times and it allows me to load the page in the wysiwyg editor.
The blank page URL is:
/xwiki/resources/js/xwiki/wysiwyg/xwe/ADF3814286AF82911EECBC7DB34EA9C0.cache.html
This is actually the source code of the WYSIWYG editor, loaded in a
separate hidden iframe. I don't see how the iframe used by the rich
text area could possibly point to the WYSIWYG editor source code. How
did you established that? If you inspect the rich text area with
Firebug (on Firefox) is the URL you pasted above the value of the
'src' attribute of the iframe?
---
What I have noticed is that the pages where I have
this problem do not
display a submenu when the mouse hovers over Edit.
See http://platform.xwiki.org/xwiki/bin/view/Features/PageEditing#HAdvancedMode
. This is just a setting. Are you sure the account/user you were using
when you tested was an advanced one?
Also, it may be worth noting that these pages also include content from
other Xwiki pages (custom menus) using the {{include document}} syntax.
Each of these pages contain the following html block (which I am starting to
think may be the culprit):
{{html}}
{{/html}}
Neither the include macro nor the HTML macro (as long as you don't use
clean="false") should cause such a problem. It would help if you can
provide as the minimal wiki content that reproduces the problem on a
new page.
>
---
> I am using Windows 7 Ultimate on my client PC and Windows 2003 Enterprise on
> the server that handles Xwiki.
>
>
> Apache Tomcat 5.5.33
> JVM 1.6.0_25-b06
Xwiki version=2.7.33656
This is an older version. See
http://www.xwiki.org/xwiki/bin/view/Main/Support . Even if we find a
bug on 2.7, if it's not reproducible on 4.x then we probably won't fix
it.
Thanks,
Marius
Apache 2.2.19
Mod_ssl 2.2.9
OpenSSSL 0.9.8
Mod_jk 1.2.25
--
View this message in context:
http://xwiki.475771.n2.nabble.com/WYSIWYG-goes-to-cache-instead-of-opening-…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4459
days inactive
4463
days old
3 comments
3 participants
participants (3)
-
echocoder -
Marius Dumitru Florea -
Sergiu Dumitriu