Re: [xwiki-users] [xwiki] Clean URLs - Anyone knows why we have /bin/ in XWiki URLs?
Hello List, has there been any progress on that ? I can attest that, at least out of the box, expanding the XWiki webapp into the ROOT directory gives rather disatrous effects (i.e. still loads of paths that are /xwiki/....). It would be nice to have a rewrite engine but this has to work to ways, i.e. if I drag-and-drop a link produced by XWiki it should the short URL that one wishes and not one that is also compatible (but, e.g., is very long). thanks for hints. It is most probable by now that we shall build the intergeo platform on xwiki and curriki... paul
Paul Libbrecht wrote:
Hello List,
has there been any progress on that ? I can attest that, at least out of the box, expanding the XWiki webapp into the ROOT directory gives rather disatrous effects (i.e. still loads of paths that are /xwiki/....).
It would be nice to have a rewrite engine but this has to work to ways, i.e. if I drag-and-drop a link produced by XWiki it should the short URL that one wishes and not one that is also compatible (but, e.g., is very long).
thanks for hints. It is most probable by now that we shall build the intergeo platform on xwiki and curriki...
paul
If you deploy XWiki as the ROOT app, you must also change in WEB-INF/web.xml the <display-name> parameter to the empty string, like: <display-name></display-name> To get rid of /view/, in xwiki.cfg write xwiki.showviewaction=0 To get rid of /bin/, for the moment you have to change web.xml in a container-dependent way, so that you map the container's default servlet to existing directories, like skins, yui, tinymce and wikieditor, copy the /bin mapping to also be activated for / (copy, don't change, so that /bin works, too), then add in xwiki.cfg xwiki.defaultactionpath= This will allow you to access documents with server.com/Space/Document, server.com/Space/ (pointing to Space.WebHome), server.com/Document (pointing to Main.Document), and server.com/ will show Main.WebHome without needing a redirect. As a bonus, these changes are backwards compatible, meaning that any currently working URL will also work with these changes performed, so you won't have any broken bookmarks. All these changes aren't completely tested, so there could be some things that aren't working, because of code that parses the URL and counts the number of slashes, or expects an exact URL pattern containing /bin/ or stuff like that. But my unconfirmed guess is that it should all work fine. If you want to have different action mappings, like server.com/Space/Doc?action=edit, then there's more work, like writing a new URLFactory, changing struts-config.xml, and creating another RequestProcessor. Sergiu
This is very valuable information, il should be posted on the xwiki.org :-)
If you deploy XWiki as the ROOT app, you must also change in WEB-INF/web.xml the <display-name> parameter to the empty string, like:
<display-name></display-name>
To get rid of /view/, in xwiki.cfg write
xwiki.showviewaction=0
To get rid of /bin/, for the moment you have to change web.xml in a container-dependent way, so that you map the container's default servlet to existing directories, like skins, yui, tinymce and wikieditor, copy the /bin mapping to also be activated for / (copy, don't change, so that /bin works, too), then add in xwiki.cfg
xwiki.defaultactionpath=
This will allow you to access documents with server.com/Space/Document, server.com/Space/ (pointing to Space.WebHome), server.com/Document (pointing to Main.Document), and server.com/ will show Main.WebHome without needing a redirect.
As a bonus, these changes are backwards compatible, meaning that any currently working URL will also work with these changes performed, so you won't have any broken bookmarks.
All these changes aren't completely tested, so there could be some things that aren't working, because of code that parses the URL and counts the number of slashes, or expects an exact URL pattern containing /bin/ or stuff like that. But my unconfirmed guess is that it should all work fine.
If you want to have different action mappings, like server.com/Space/Doc?action=edit, then there's more work, like writing a new URLFactory, changing struts-config.xml, and creating another RequestProcessor.
Sergiu
On Dec 21, 2007, at 2:49 PM, Karim-Pierre Maalej wrote:
This is very valuable information, il should be posted on the xwiki.org :-)
... and since xwiki.org is a wiki, why don't you do it? -Vincent
If you deploy XWiki as the ROOT app, you must also change in WEB-INF/web.xml the <display-name> parameter to the empty string, like:
<display-name></display-name>
To get rid of /view/, in xwiki.cfg write
xwiki.showviewaction=0
To get rid of /bin/, for the moment you have to change web.xml in a container-dependent way, so that you map the container's default servlet to existing directories, like skins, yui, tinymce and wikieditor, copy the /bin mapping to also be activated for / (copy, don't change, so that /bin works, too), then add in xwiki.cfg
xwiki.defaultactionpath=
This will allow you to access documents with server.com/Space/ Document, server.com/Space/ (pointing to Space.WebHome), server.com/Document (pointing to Main.Document), and server.com/ will show Main.WebHome without needing a redirect.
As a bonus, these changes are backwards compatible, meaning that any currently working URL will also work with these changes performed, so you won't have any broken bookmarks.
All these changes aren't completely tested, so there could be some things that aren't working, because of code that parses the URL and counts the number of slashes, or expects an exact URL pattern containing /bin/ or stuff like that. But my unconfirmed guess is that it should all work fine.
If you want to have different action mappings, like server.com/Space/Doc?action=edit, then there's more work, like writing a new URLFactory, changing struts-config.xml, and creating another RequestProcessor.
Sergiu
A single attempt was pretty catastrophic with me (on 1.1)... was this working for your Karim-Pierre ? Which version ? thanks paul Le 21 déc. 07 à 14:49, Karim-Pierre Maalej a écrit :
This is very valuable information, il should be posted on the xwiki.org :-)
If you deploy XWiki as the ROOT app, you must also change in WEB-INF/web.xml the <display-name> parameter to the empty string, like:
<display-name></display-name>
To get rid of /view/, in xwiki.cfg write
xwiki.showviewaction=0
To get rid of /bin/, for the moment you have to change web.xml in a container-dependent way, so that you map the container's default servlet to existing directories, like skins, yui, tinymce and wikieditor, copy the /bin mapping to also be activated for / (copy, don't change, so that /bin works, too), then add in xwiki.cfg
xwiki.defaultactionpath=
This will allow you to access documents with server.com/Space/ Document, server.com/Space/ (pointing to Space.WebHome), server.com/Document (pointing to Main.Document), and server.com/ will show Main.WebHome without needing a redirect.
As a bonus, these changes are backwards compatible, meaning that any currently working URL will also work with these changes performed, so you won't have any broken bookmarks.
All these changes aren't completely tested, so there could be some things that aren't working, because of code that parses the URL and counts the number of slashes, or expects an exact URL pattern containing /bin/ or stuff like that. But my unconfirmed guess is that it should all work fine.
If you want to have different action mappings, like server.com/Space/Doc?action=edit, then there's more work, like writing a new URLFactory, changing struts-config.xml, and creating another RequestProcessor.
Sergiu
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Paul Libbrecht wrote:
A single attempt was pretty catastrophic with me (on 1.1)... was this working for your Karim-Pierre ? Which version ?
It should work fine for 1.1, too. What exactly failed?
Le 21 déc. 07 à 14:49, Karim-Pierre Maalej a écrit :
This is very valuable information, il should be posted on the xwiki.org :-)
If you deploy XWiki as the ROOT app, you must also change in WEB-INF/web.xml the <display-name> parameter to the empty string, like:
<display-name></display-name>
To get rid of /view/, in xwiki.cfg write
xwiki.showviewaction=0
To get rid of /bin/, for the moment you have to change web.xml in a container-dependent way, so that you map the container's default servlet to existing directories, like skins, yui, tinymce and wikieditor, copy the /bin mapping to also be activated for / (copy, don't change, so that /bin works, too), then add in xwiki.cfg
xwiki.defaultactionpath=
This will allow you to access documents with server.com/Space/Document, server.com/Space/ (pointing to Space.WebHome), server.com/Document (pointing to Main.Document), and server.com/ will show Main.WebHome without needing a redirect.
As a bonus, these changes are backwards compatible, meaning that any currently working URL will also work with these changes performed, so you won't have any broken bookmarks.
All these changes aren't completely tested, so there could be some things that aren't working, because of code that parses the URL and counts the number of slashes, or expects an exact URL pattern containing /bin/ or stuff like that. But my unconfirmed guess is that it should all work fine.
If you want to have different action mappings, like server.com/Space/Doc?action=edit, then there's more work, like writing a new URLFactory, changing struts-config.xml, and creating another RequestProcessor.
Sergiu
... and since xwiki.org is a wiki, why don't you do it?
I wanted to let the author post it, I wouldn't want someone to just copy-paste my work without my prior authorisation, and I would prefer to do it myself (for credits). I tend not to do to others what I wouldn't want to be done to me ;-) I was about to precise that in my mail, but I thought it was pretty obvious.
On Dec 21, 2007, at 4:00 PM, Karim-Pierre Maalej wrote:
... and since xwiki.org is a wiki, why don't you do it?
I wanted to let the author post it, I wouldn't want someone to just copy-paste my work without my prior authorisation, and I would prefer to do it myself (for credits). I tend not to do to others what I wouldn't want to be done to me ;-)
I was about to precise that in my mail, but I thought it was pretty obvious.
Seems like nothing will ever get done with such a strategy... :( As you have noticed Sergiu is quite busy these days. I don't find it nice to ask him to publish it when you could just help out... I can tell you Sergiu won't mind if you propose to help him. Anyway it's your call and if you don't want to help nobody is going to force you either... ;) Thanks -Vincent
Le 21 déc. 07 à 15:30, Sergiu Dumitriu a écrit :
Paul Libbrecht wrote:
A single attempt was pretty catastrophic with me (on 1.1)... was this working for your Karim-Pierre ? Which version ? It should work fine for 1.1, too. What exactly failed?
Actually, at the time, superadmin login failed... but after trying again and a browser restart it worked as ROOT context... I'll use that for now. Sorry for the wrong info. That's good news. I tried to take it further. So for Tomcat, it meant to me to add, in the web.xml: <servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/skins</url-pattern> </servlet-mapping> (on such for each subdirectory) (and no servlet element with the corresponding name, it's inherited) For the documentation entry, I think a good place would be the FAQ (there's only one of these, right?) and one should really just put a pointer to the thread for now, I think. But I do not get it fully... http://ocms.activemath.org/bin/view/Main/WebHome displays fine but http://ocms.activemath.org/Main/WebHome or http://ocms.activemath.org/WebHome seem both to be styleless and the log displays 14:46:41,745 [http-51080-3] ERROR log.SimpleLog4JLogSystem - Right side ($xwiki.null) of '!=' operation has null value. Operation not possible. [line 9, column 12] 15:12:08,829 [http-51080-3] ERROR log.SimpleLog4JLogSystem - Left side ($request.xpage) of '==' operation has null value. If a reference, it may not be in the context. Operation not possible. [line 156, column 21] paul
If you deploy XWiki as the ROOT app, you must also change in WEB-INF/web.xml the <display-name> parameter to the empty string, like:
<display-name></display-name>
To get rid of /view/, in xwiki.cfg write
xwiki.showviewaction=0
To get rid of /bin/, for the moment you have to change web.xml in a container-dependent way, so that you map the container's default servlet to existing directories, like skins, yui, tinymce and wikieditor, copy the /bin mapping to also be activated for / (copy, don't change, so that /bin works, too), then add in xwiki.cfg
xwiki.defaultactionpath=
This will allow you to access documents with server.com/Space/ Document, server.com/Space/ (pointing to Space.WebHome), server.com/Document (pointing to Main.Document), and server.com/ will show Main.WebHome without needing a redirect.
As a bonus, these changes are backwards compatible, meaning that any currently working URL will also work with these changes performed, so you won't have any broken bookmarks.
All these changes aren't completely tested, so there could be some things that aren't working, because of code that parses the URL and counts the number of slashes, or expects an exact URL pattern containing /bin/ or stuff like that. But my unconfirmed guess is that it should all work fine.
If you want to have different action mappings, like server.com/Space/Doc?action=edit, then there's more work, like writing a new URLFactory, changing struts-config.xml, and creating another RequestProcessor.
As you have noticed Sergiu is quite busy these days. I don't find it nice to ask him to publish it when you could just help out...
Literally speaking, I didn't ask anything. I made a remark that intentionally left all options open (including asking me to do it of course). I did not want to do anything that might have been perceived as out of rights (and certainly not to ask somebody to do something in my place). Apparently that wasn't enough to prevent me from being told I'm not nice. I apologise for not knowing the way things are done here. I have yet to learn, so please don't take offense from my mistakes and believe in my good will. I am used to Wikipedia's rules, where it would probably be perceived as an offense to take somebody's opus without his consent (unless of course it is already published in an article, since this would automatically place it under GFDL licence). I did face some licence problems, e.g. having to ask every contributor for his approval for a change from GFDL to CC-BY-SA (and vice-versa), so I tend to be careful. Thank you for your understanding.
Anyway it's your call and if you don't want to help nobody is going to force you either... ;)
It is done. I have put it under AdminGuide.WebHome. It is just a copy/paste of Sergiu's text with some wrappings. Due credit is given in comments. Any suggestions are welcome. And as stated above, I am new to XWiki and I may have done wrong.
I forgot to give the link to the page: <http://platform.xwiki.org/xwiki/bin/view/Main/NiceURLs>
It is done. I have put it under AdminGuide.WebHome. It is just a copy/paste of Sergiu's text with some wrappings. Due credit is given in comments. Any suggestions are welcome. And as stated above, I am new to XWiki and I may have done wrong.
Paul Libbrecht wrote:
Le 21 déc. 07 à 15:30, Sergiu Dumitriu a écrit :
Paul Libbrecht wrote:
A single attempt was pretty catastrophic with me (on 1.1)... was this working for your Karim-Pierre ? Which version ? It should work fine for 1.1, too. What exactly failed?
Actually, at the time, superadmin login failed... but after trying again and a browser restart it worked as ROOT context... I'll use that for now. Sorry for the wrong info.
That's good news.
I tried to take it further. So for Tomcat, it meant to me to add, in the web.xml: <servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/skins</url-pattern> </servlet-mapping> (on such for each subdirectory) (and no servlet element with the corresponding name, it's inherited)
That's not enough. By default, the default servlet sends resources starting from the webapp root, regardless of the mapping (and thus the URL). So, when you map it to respond to /skins/, when the URL is .com/skins/albatross, it will look not for /skins/albatross, but for /albatross, because /skins/ is just for mapping. Jetty allows to easily configure the starting point from the servlet declaration, in web.xml, but Tomcat doesn't. Instead, it uses a servlet context attribute, named "org.apache.catalina.alternateResources" for alternate docbases. I don't know how to put this attribute in the context before initializing it (as it is read only at init()). So, for the moment, until we provide our own default servlet for retrieving those resources, I can't help you any further. This is why I said that this part must be configured in a container-dependent way. Sergiu
For the documentation entry, I think a good place would be the FAQ (there's only one of these, right?) and one should really just put a pointer to the thread for now, I think.
But I do not get it fully...
http://ocms.activemath.org/bin/view/Main/WebHome
displays fine but http://ocms.activemath.org/Main/WebHome or http://ocms.activemath.org/WebHome
seem both to be styleless and the log displays 14:46:41,745 [http-51080-3] ERROR log.SimpleLog4JLogSystem - Right side ($xwiki.null) of '!=' operation has null value. Operation not possible. [line 9, column 12] 15:12:08,829 [http-51080-3] ERROR log.SimpleLog4JLogSystem - Left side ($request.xpage) of '==' operation has null value. If a reference, it may not be in the context. Operation not possible. [line 156, column 21]
paul
If you deploy XWiki as the ROOT app, you must also change in WEB-INF/web.xml the <display-name> parameter to the empty string, like:
<display-name></display-name>
To get rid of /view/, in xwiki.cfg write
xwiki.showviewaction=0
To get rid of /bin/, for the moment you have to change web.xml in a container-dependent way, so that you map the container's default servlet to existing directories, like skins, yui, tinymce and wikieditor, copy the /bin mapping to also be activated for / (copy, don't change, so that /bin works, too), then add in xwiki.cfg
xwiki.defaultactionpath=
This will allow you to access documents with server.com/Space/Document, server.com/Space/ (pointing to Space.WebHome), server.com/Document (pointing to Main.Document), and server.com/ will show Main.WebHome without needing a redirect.
As a bonus, these changes are backwards compatible, meaning that any currently working URL will also work with these changes performed, so you won't have any broken bookmarks.
All these changes aren't completely tested, so there could be some things that aren't working, because of code that parses the URL and counts the number of slashes, or expects an exact URL pattern containing /bin/ or stuff like that. But my unconfirmed guess is that it should all work fine.
If you want to have different action mappings, like server.com/Space/Doc?action=edit, then there's more work, like writing a new URLFactory, changing struts-config.xml, and creating another RequestProcessor.
Karim-Pierre Maalej wrote:
As you have noticed Sergiu is quite busy these days. I don't find it nice to ask him to publish it when you could just help out...
Literally speaking, I didn't ask anything. I made a remark that intentionally left all options open (including asking me to do it of course). I did not want to do anything that might have been perceived as out of rights (and certainly not to ask somebody to do something in my place). Apparently that wasn't enough to prevent me from being told I'm not nice.
I apologise for not knowing the way things are done here. I have yet to learn, so please don't take offense from my mistakes and believe in my good will.
I am used to Wikipedia's rules, where it would probably be perceived as an offense to take somebody's opus without his consent (unless of course it is already published in an article, since this would automatically place it under GFDL licence). I did face some licence problems, e.g. having to ask every contributor for his approval for a change from GFDL to CC-BY-SA (and vice-versa), so I tend to be careful.
Thank you for your understanding.
Anyway it's your call and if you don't want to help nobody is going to force you either... ;)
It is done. I have put it under AdminGuide.WebHome. It is just a copy/paste of Sergiu's text with some wrappings. Due credit is given in comments. Any suggestions are welcome. And as stated above, I am new to XWiki and I may have done wrong.
No need to excuse yourself. Indeed, I don't mind using what I said to complete the documentation. I'd rather have a full documentation than argue that somebody stole my work.
Rephrased into a proper documentation page: http://platform.xwiki.org/xwiki/bin/view/Main/NiceURLs Karim-Pierre Maalej wrote:
I forgot to give the link to the page:
<http://platform.xwiki.org/xwiki/bin/view/Main/NiceURLs>
It is done. I have put it under AdminGuide.WebHome. It is just a copy/paste of Sergiu's text with some wrappings. Due credit is given in comments. Any suggestions are welcome. And as stated above, I am new to XWiki and I may have done wrong.
On Dec 21, 2007, at 5:31 PM, Karim-Pierre Maalej wrote:
I forgot to give the link to the page:
Thanks a lot Karim :) I couldn't find from where it was linked so I added a link in the Admin configuration guide. I've also modified the content and name since calling it "nice" is very subjective (I replaced it with "short URLs" which is neutral). Thanks -Vincent
It is done. I have put it under AdminGuide.WebHome. It is just a copy/paste of Sergiu's text with some wrappings. Due credit is given in comments. Any suggestions are welcome. And as stated above, I am new to XWiki and I may have done wrong.
Hi, We've just installed XWiki and feel User Rights and Group administration is somewhat cumbersome in the basic install package. XWiki.org website indicate that a far more advanced user- and group admin system is available than the one natively available in XWiki 1.1.2.5797: http://platform.xwiki.org/xwiki/bin/view/Features/RightsManagement#HAdd2Crem ove2Ceditusersandgroups22onthefly22 How can we enable this functionality? Best regards, Robert
Hi, See XWiki Enterprise 1.1.2 release notes to enable new rights management UI (http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise112). 2007/12/21, Robert Hercz <[email protected]>:
Hi,
We've just installed XWiki and feel User Rights and Group administration is somewhat cumbersome in the basic install package.
XWiki.org website indicate that a far more advanced user- and group admin system is available than the one natively available in XWiki 1.1.2.5797:
http://platform.xwiki.org/xwiki/bin/view/Features/RightsManagement#HAdd2Crem...
How can we enable this functionality?
Best regards, Robert
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
-- Thomas Mortagne
Le 21 déc. 07 à 17:43, Sergiu Dumitriu a écrit :
Actually, at the time, superadmin login failed... but after trying again and a browser restart it worked as ROOT context... I'll use that for now. Sorry for the wrong info. That's good news.
As can see below, I have now managed to get as short x.org/bin/Main which is fair. Note however that the settings above are not enough there are still paths that use /xwiki or assume something such. I have seen two thus far: - the WebSearch and LuceneSearch, in the path of the submit form - the Class-Sheet, used in the class-editor, to create new instances Had I not had http://www.theserverside.com/tt/articles/article.tss?l=XWiki (which I found with Google) it'd be harder to stimulate me to make it work.
I tried to take it further. So for Tomcat, it meant to me to add, in the web.xml: <servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/skins</url-pattern> </servlet-mapping> (on such for each subdirectory) (and no servlet element with the corresponding name, it's inherited)
That's not enough. By default, the default servlet sends resources starting from the webapp root, regardless of the mapping (and thus the [...]
I suppose all this would be solved if the static resources are all served by an apache httpd instead of the servlet container. It'd be nice to suggest that no webapp-root-single-files should exist to ease this process. paul
On Sat, Dec 22, 2007 at 10:40:44PM +0100, Paul Libbrecht wrote:
As can see below, I have now managed to get as short x.org/bin/Main which is fair. Note however that the settings above are not enough there are still paths that use /xwiki or assume something such. I have seen two thus far: - the WebSearch and LuceneSearch, in the path of the submit form - the Class-Sheet, used in the class-editor, to create new instances
The other thing that can be done is to put a reverse proxy in front of xwiki and have it re-write that part of the URL out. Paul -- End dual-measurement, let's finish going metric! http://gometric.us/ http://www.metric.org/
Le 22 déc. 07 à 22:51, Paul Armstrong a écrit :
The other thing that can be done is to put a reverse proxy in front of xwiki and have it re-write that part of the URL out.
The only reverse proxy I know of is Apache mod_proxy, which we are using, and that only rewrites HTTP headers and does not change the content... e.g. relative links cannot be changed, really, you need a tuned URL-factory. paul
On Sat, Dec 22, 2007 at 11:52:14PM +0100, Paul Libbrecht wrote:
Le 22 d?c. 07 ? 22:51, Paul Armstrong a ?crit :
The other thing that can be done is to put a reverse proxy in front of xwiki and have it re-write that part of the URL out.
The only reverse proxy I know of is Apache mod_proxy, which we are using, and that only rewrites HTTP headers and does not change the content... e.g. relative links cannot be changed, really, you need a tuned URL-factory.
ProxyPass and ProxyPassReverse do what you need. See http://httpd.apache.org/docs/2.2/mod/mod_proxy.html -- End dual-measurement, let's finish going metric! http://gometric.us/ http://www.metric.org/
Le 23 déc. 07 à 03:49, Paul Armstrong a écrit :
The only reverse proxy I know of is Apache mod_proxy, which we are using, and that only rewrites HTTP headers and does not change the content... e.g. relative links cannot be changed, really, you need a tuned URL-factory. ProxyPass and ProxyPassReverse do what you need. See http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
Sorry to be stubborn. We use exactly both of them on an apache 2.1. It does not change anything to the content, hence to output URLs, it only maps one way. So if an xwiki pages contains ../../inline/xxx whereas the original path is <host>/bin/Main/WebHome, the browser will submit the URL <host>/inline/xxx which breaks. paul
participants (7)
-
Karim-Pierre Maalej -
Paul Armstrong -
Paul Libbrecht -
Robert Hercz -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol