Hi Jonas, Marius Dumitru Florea wrote:

Jonas Almfeldt wrote:

...

Hi,

On Fri, Apr 17, 2009 at 1:58 PM, Marius Dumitru Florea <[email protected] <mailto:[email protected]>> wrote:

Hi Jonas

Jonas Almfeldt wrote: [snip]

Where can I find those templates? in the .war file or in the database?

Yes, in the war, in templates directory. Have you changed editwysiwygnew.vm or wysiwyginput.vm?

No haven't.

I have now deployed the same .war file in both environments and the instance running in Tomcat works fine with the rendering in the wysiwyg editor, but the instance running in WAS environment does not. :-(

[snip]

This means the XWiki syntax is no converted to XHTML before loading the editor. Can you try a simpler example just to be sure? For instance to this:

* edit a new/empty page * type a word like "bug" * select the word * click the bold button on the tool bar * save and edit again

Do you get **bug** in the WYSIWYG editor? If so, then cancel the edit. The "bug" is in bold in view mode right? Then please append "xpage=wysiwyginput" to the query string of your URL and tell me the output. For instance:

http://localhost:8080/xwiki/bin/view/Sandbox/Test?xpage=wysiwyginput

I suspect the output is **bug** right?

Yes, the output is: **bug**\\

Now if you append also "render" like in:

http://localhost:8080/xwiki/bin/view/Sandbox/FF?xpage=wysiwyginput&render <http://localhost:8080/xwiki/bin/view/Sandbox/FF?xpage=wysiwyginput&render>

<http://localhost:8080/xwiki/bin/view/Sandbox/FF?xpage=wysiwyginput&render <http://localhost:8080/xwiki/bin/view/Sandbox/FF?xpage=wysiwyginput&render>>

is the "bug" in bold?

No :-( the output of ...?xpage=wysiwyginput&render is still: **bug**\\

Can you try this:

* edit a NEW page with the Wiki editor and past this content:

-----8<----- {{velocity}} #set($mydoc = $xwiki.getDocument("Sandbox.FF")) $mydoc.getRenderedContent($mydoc.content, $mydoc.syntaxId) {{/velocity}} ----->8-----

* replace Sandbox.FF with the space and the page where you wrote **bug**. Save and view. What does it display? I get:

<p><strong>bug</strong></p>

I also get:

<p><strong>bug</strong></p>

Then something wrong happens in wysiwyginput.vm template. This is what I have http://pastebin.com/m118b997b . Can try the following:

(1) Replace line 16 with

#set($content = "**nobug**")

and refresh the page containing "bug". What the output if you append xpage=wysiwyginput&render to the query string of the view URL?

(2) Revert the previous change. Replace line 28 with

#set($content = $tdoc.getRenderedContent("**nobug**", $tdoc.getSyntaxId()))

and refresh again. What's the output now?

(3) Revert the changes from (1) and (2) and instead of xpage=wysiwyginput&render put xpage=wysiwyginput&render=true in the query string of the view URL. What's the output this time? I suspect the WAS environment doesn't support query string parameters without a value.

Thanks, Marius

...

Some additional details: The WAS 6.1 jvm has java version 1.5.0 btw. My local Tomcat runs with the JRE of jdk1.5.0_08.

I also forgot to mention to the list that this problem is not specific to 1.8.1. It happens when I test with 1.8 also. (same wiki db content used, created with 1.8 stable and the 1.8 XAR archive as a base).

[snip]

Thanks, Marius

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

Yeahh! I figured out a temporary (?) solution to the problem: I added =true after &render at line #73 of See http://pastebin.com/m78e1155c I changed #set($inputURLQueryString = $inputURLQueryString + "&render") to #set($inputURLQueryString = $inputURLQueryString + "&render=true") It looks like query parameters with no value occurrs in other places of the code as well. I have not suffered from that so far. But it would be good to know if/how this issue will be handled in coming xwiki releases. My personal opinion is that it is probably good for XWiki and the community if it is as platform independent as possible out of the box. Thanks & kind regards, Jonas On Fri, Apr 17, 2009 at 10:41 PM, Jonas Almfeldt <[email protected]>wrote:

On Fri, Apr 17, 2009 at 4:05 PM, Marius Dumitru Florea < [email protected]> wrote:

...

Jonas Almfeldt wrote:

[snip]

Then something wrong happens in wysiwyginput.vm template. This is what I

...

have http://pastebin.com/m118b997b . Can try the following:

(1) Replace line 16 with

#set($content = "**nobug**")

and refresh the page containing "bug". What the output if you append xpage=wysiwyginput&render to the query string of the view URL?

http://server:8080/xwiki/bin/view/Sandbox/test+2?xpage=wysiwyginput&rendergi... the output:

**nobug**

(2) Revert the previous change. Replace line 28 with

...

#set($content = $tdoc.getRenderedContent("**nobug**", $tdoc.getSyntaxId()))

and refresh again. What's the output now?

Output of http://server:8080/xwiki/bin/view/Sandbox/test+2?xpage=wysiwyginput&renderis now:

**bug**

and if I edit the page, the wysiwyg opens up displaying:

**bug**

So the condition in the if statement on line 27: #if($request.render) does not seem to be satisfied. See my result for (3) below.

[snip]

(3) Revert the changes from (1) and (2) and instead of

...

xpage=wysiwyginput&render

put

xpage=wysiwyginput&render=true

in the query string of the view URL. What's the output this time?

I suspect the WAS environment doesn't support query string parameters without a value.

Maurius, your suspicion seems very likely! :-)

When I have reverted changes (1) and (2), and using url: with render=true instead of just render it displays * bug

in bold text, just as it should do. *

Thanks for having such good patience to guide me through the troubleshooting!

Is this a bug in WAS 6.1? or is it actually following some servlet standard more strictly than other application servers do? or just interpreting the standard more strictly perhaps :-)

How can we solve this?

Will this be adressed in a coming xwiki release?

Kind regards, Jonas

Jonas Almfeldt wrote:

Yeahh! I figured out a temporary (?) solution to the problem:

I added =true after &render at line #73 of See http://pastebin.com/m78e1155c

I changed #set($inputURLQueryString = $inputURLQueryString + "&render") to #set($inputURLQueryString = $inputURLQueryString + "&render=true")

Yep, that's the fix I'm going to apply.

It looks like query parameters with no value occurrs in other places of the code as well. I have not suffered from that so far. But it would be good to know if/how this issue will be handled in coming xwiki releases.

Yes, I'll fix this for the WYSIWYG editor. Thanks, Marius

My personal opinion is that it is probably good for XWiki and the community if it is as platform independent as possible out of the box.

Thanks & kind regards, Jonas

On Fri, Apr 17, 2009 at 10:41 PM, Jonas Almfeldt <[email protected]>wrote:

...

On Fri, Apr 17, 2009 at 4:05 PM, Marius Dumitru Florea < [email protected]> wrote:

...

Jonas Almfeldt wrote:

[snip]

Then something wrong happens in wysiwyginput.vm template. This is what I

...

have http://pastebin.com/m118b997b . Can try the following:

(1) Replace line 16 with

#set($content = "**nobug**")

and refresh the page containing "bug". What the output if you append xpage=wysiwyginput&render to the query string of the view URL?

http://server:8080/xwiki/bin/view/Sandbox/test+2?xpage=wysiwyginput&rendergi... the output:

**nobug**

(2) Revert the previous change. Replace line 28 with

...

#set($content = $tdoc.getRenderedContent("**nobug**", $tdoc.getSyntaxId()))

and refresh again. What's the output now?

Output of http://server:8080/xwiki/bin/view/Sandbox/test+2?xpage=wysiwyginput&renderis now:

**bug**

and if I edit the page, the wysiwyg opens up displaying:

**bug**

So the condition in the if statement on line 27: #if($request.render) does not seem to be satisfied. See my result for (3) below.

[snip]

(3) Revert the changes from (1) and (2) and instead of

...

xpage=wysiwyginput&render

put

xpage=wysiwyginput&render=true

in the query string of the view URL. What's the output this time?

I suspect the WAS environment doesn't support query string parameters without a value.

Maurius, your suspicion seems very likely! :-)

When I have reverted changes (1) and (2), and using url: with render=true instead of just render it displays * bug

in bold text, just as it should do. *

Thanks for having such good patience to guide me through the troubleshooting!

Is this a bug in WAS 6.1? or is it actually following some servlet standard more strictly than other application servers do? or just interpreting the standard more strictly perhaps :-)

How can we solve this?

Will this be adressed in a coming xwiki release?

Kind regards, Jonas

_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

Jonas Almfeldt wrote:

Another question:

I have access to my wiki restricted to registered users. Unauthorised visitors should however be redirected (?) automatically to a page in a public space instead of just being redirected to the log in page. How can that be achieved?

This is not currently implemented (feel free to open a feature request on jira.xwiki.org if you want it), but there's a workaround possible. - in WEB-INF/xwiki.cfg, add this: xwiki.hidelogin=true - in templates/accessdenied replace the "notallowed" line with something like: #if($context.user == 'XWiki.XWikiGuest') $response.sendRedirect($xwiki.getURL('Your.PublicPage')) #else #xwikimessageboxstart($msg.get("error") $msg.get("notallowed")) #end -- Sergiu Dumitriu http://purl.org/net/sergiu/