22 Feb
2019
22 Feb
'19
9:59 a.m.
Hi devs,
Because of tomcat and because tomcat is by far the most used container for xwiki and
because we also bundle tomcat in the debian and docker dsitributions, I think we should
disallow / and \ in page names by default. It's causing too much trouble for users. We
keep having users posting problems and for one user who post a problem there are 100 who
don't.
The latest one:
https://forum.xwiki.org/t/please-help-broken-link-routing-cannot-open-page-…
Implementation idea:
* Offer an extension point in the create page UI to allow plugging some cleaning
algorithm
* Provide the \ and / cleaning algorithm by default
* Handle backward compat. Find ways to not break existing users who are having / and \ in
page names. For example we could imagine a property in xwiki.properties that we would set
to point to the hint of the / and \ cleaner component. Thus existing users would need to
voluntarily upgrade their xwiki.properties to have it if they want it. We would need to
provide some script to convert existing pages with / and \ too probably.
WDYT?
Thanks
-Vincent
22 Feb
22 Feb
11:31 a.m.
New subject: [xwiki-devs] [Proposal] Disallow / and \ in page names by default
On 22 Feb 2019, at 09:59, Vincent Massol
<vincent(a)massol.net> wrote:
Hi devs,
Because of tomcat and because tomcat is by far the most used container for xwiki and
because we also bundle tomcat in the debian and docker dsitributions,
Re docker and debian we already set the proper config for Tomcat so the issue is with all
users not using those distributions, which represents a sizable proportion (around
25-30%). I believe almost 100% of those are having the problem at some point.
Thanks
-Vincent
I think we should disallow / and \ in page names by
default. It's causing too much trouble for users. We keep having users posting
problems and for one user who post a problem there are 100 who don't.
The latest one:
https://forum.xwiki.org/t/please-help-broken-link-routing-cannot-open-page-…
Implementation idea:
* Offer an extension point in the create page UI to allow plugging some cleaning
algorithm
* Provide the \ and / cleaning algorithm by default
* Handle backward compat. Find ways to not break existing users who are having / and \ in
page names. For example we could imagine a property in xwiki.properties that we would set
to point to the hint of the / and \ cleaner component. Thus existing users would need to
voluntarily upgrade their xwiki.properties to have it if they want it. We would need to
provide some script to convert existing pages with / and \ too probably.
WDYT?
Thanks
-Vincent
10:31 p.m.
New subject: [xwiki-devs] [Proposal] Disallow / and \ in page names by default
Hi devs,
Because of tomcat and because tomcat is by far the most used container for xwiki and
because we also bundle tomcat in the debian and docker dsitributions, I think we should
disallow / and \ in page names by default. It's causing too much trouble for users. We
keep having users posting problems and for one user who post a problem there are 100 who
don't.
The latest one:
https://forum.xwiki.org/t/please-help-broken-link-routing-cannot-open-page-…
+1 for me for the stripping of slashes. Even if configured properly
there is a problem with tomcat: if you create a page e.g. in the Sandbox
with a title of "Page A / B", this creates a page with the reference
"Sandbox.Page A . B.WebHome", and you get an "empty" intermediate
space.
As users mostly see titles in the current XWiki version, it should not
matter to them what happens to the page name.
Implementation idea:
* Offer an extension point in the create page UI to allow plugging some cleaning
algorithm
* Provide the \ and / cleaning algorithm by default
* Handle backward compat. Find ways to not break existing users who are having / and \ in
page names. For example we could imagine a property in xwiki.properties that we would set
to point to the hint of the / and \ cleaner component. Thus existing users would need to
voluntarily upgrade their xwiki.properties to have it if they want it. We would need to
provide some script to convert existing pages with / and \ too probably.
WDYT?
About backwards compatibility, I do not get the point. What will break
for users who have already existing pages?
As long as the cleaning algorithm only runs on newly created pages there
should not be any bw/compat problem.
If they really want no cleaning, we can provide them with a property
which contains the characters to be scrapped from the name with a
default value of '/\', and if they do not want this, they can set this
property to an empty value.
Or what am I missing here?
Best,
Clemens
Thanks
-Vincent
P.S. As a side note, when using MySQL creating spaces with a trailing
whitespace seem to cause some odd problems, too. I have seen at least
one occurrence of an entry in the xwikispaces with no corresponding
entries in xwikidoc. This causes an entry in the navigation tree which
leads to a non-existing page and no good way to get rid of it from a
users point of view. I have not figured out how to reproduce the
problem, unfortunately.
(For the issue with trailing spaces try "select 'x' = 'x ',
'x' like 'x
'; " and read https://dev.mysql.com/doc/refman/5.7/en/char.html )
23 Feb
23 Feb
12:18 p.m.
New subject: [xwiki-devs] [Proposal] Disallow / and \ in page names by default
Hi Clemens,
On 22 Feb 2019, at 22:31, Clemens Robbenhaar
<robbenhaar(a)green-meadows.de> wrote:
I’ve just tested with the XWiki Docker image 10.11.3, where Tomcat is correctly configured
and it works as it’s supposed to:
Hi devs,
Because of tomcat and because tomcat is by far the most used container for xwiki and
because we also bundle tomcat in the debian and docker dsitributions, I think we should
disallow / and \ in page names by default. It's causing too much trouble for users. We
keep having users posting problems and for one user who post a problem there are 100 who
don't.
The latest one:
https://forum.xwiki.org/t/please-help-broken-link-routing-cannot-open-page-…
+1 for me for the stripping of slashes. Even if configured properly there is a problem
with tomcat: if you create a page e.g. in the Sandbox with a title of "Page A /
B", this creates a page with the reference "Sandbox.Page A . B.WebHome",
and you get an "empty" intermediate space.
As users mostly see titles in the current XWiki version, it should not matter to them
what happens to the page name.
Yes you’re right. But what’s important is to not change the behavior: if they were using
“/“ and “\” in page name we shouldn’t break them and they should continue to do so unless
they choose not to. However for new users we can configure them to filter page names by
default.
Hence my proposal about the new config property in xwiki.properties. When you uprgade
you’ll decide if you want to merge it or not and if not you’ll continue to get the same
behavior as before.
Implementation idea:
* Offer an extension point in the create page UI to allow plugging some cleaning
algorithm
* Provide the \ and / cleaning algorithm by default
* Handle backward compat. Find ways to not break existing users who are having / and \ in
page names. For example we could imagine a property in xwiki.properties that we would set
to point to the hint of the / and \ cleaner component. Thus existing users would need to
voluntarily upgrade their xwiki.properties to have it if they want it. We would need to
provide some script to convert existing pages with / and \ too probably.
WDYT?
About backwards compatibility, I do not get the point. What will break for users who have
already existing pages?
As long as the cleaning algorithm only runs on newly created pages there should not be
any bw/compat problem.
If they really want no cleaning, we can provide them with a property which contains the
characters to be scrapped from the name with a default value of '/\', and if they
do not want this, they can set this property to an empty value.
I prefer the implementation that I mentioned based on a component role and provide the
hint in the config. It not allows the 2 use cases mentioned above but also any other type
of custom use cases (other characters to strip, different logic, like force all creations
under a given page, etc). The idea would be to take the reference as input and clean it
and generate another reference as output (and display the cleaned version to the user
somehow so that there’s no surprise - display the value that’ll be used as a form field
hint for ex).
Or what am I missing here?
Best,
Clemens
Yeah just tested and it worked fine for me (the URL is
http://localhost:8080/bin/view/Test%20/ ).
Thanks
-Vincent
P.S. As a side note, when using MySQL creating spaces with a trailing whitespace seem to
cause some odd problems, too. I have seen at least one occurrence of an entry in the
xwikispaces with no corresponding entries in xwikidoc. This causes an entry in the
navigation tree which leads to a non-existing page and no good way to get rid of it from a
users point of view. I have not figured out how to reproduce the problem,
unfortunately.
(For the issue with trailing spaces try "select 'x' = 'x ',
'x' like 'x '; " and read
https://dev.mysql.com/doc/refman/5.7/en/char.html )
Vaguely rings a bell. Would be great to open a jira issue if you can reproduce the issue
with the query.
Thanks
-Vincent
2:02 p.m.
New subject: [xwiki-devs] [Proposal] Disallow / and \ in page names by default
Hi Vincent,
Maybe one can have both: the property for the hint to configure the
component, and a property for the preinstalled component with the
characters it removed from the page name. If the hint points to that
component, it can be further customized with the latter property.
But that is a detail; I can see the idea of a component selected via
hint is more flexible, and no objections from my side to that approach.
Best,
Clemens
P.S. yes, if I had been able to reproduce, I would have created an issue
already ;)
Hi Clemens,
I’ve just tested with the
XWiki Docker image 10.11.3, where Tomcat is correctly configured and it works as it’s
supposed to:
Interesting. I run into this issue on a regular basis with the standard
Debian package, but without docker (so one gets the default Debian
tomcat, which needs configuration tweaks anyway). It seems I miss
something that is configured in the docker image; but this is not
documented at
https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/…
unless I missed it there, too. (Or it is caused by having apache httpd
in front of it.) I need to check this - but nothing relevant for the
discussion here.
Hi devs,
Because of tomcat and because tomcat is by far the most used container for xwiki and
because we also bundle tomcat in the debian and docker dsitributions, I think we should
disallow / and \ in page names by default. It's causing too much trouble for users. We
keep having users posting problems and for one user who post a problem there are 100 who
don't.
The latest one:
https://forum.xwiki.org/t/please-help-broken-link-routing-cannot-open-page-…
+1 for me for the stripping of slashes. Even if configured properly there is a
problem with tomcat: if you create a page e.g. in the Sandbox with a title of "Page A
/ B", this creates a page with the reference "Sandbox.Page A . B.WebHome",
and you get an "empty" intermediate space. As users
mostly see titles in the current XWiki version, it should not matter to them what happens
to the page name.
Yes you’re right. But what’s important is to not change the
behavior: if they were using “/“ and “\” in page name we shouldn’t break them and they
should continue to do so unless they choose not to. However for new users we can configure
them to filter page names by default.
Hence my proposal about the new config property in xwiki.properties. When you uprgade
you’ll decide if you want to merge it or not and if not you’ll continue to get the same
behavior as before.
Implementation idea:
* Offer an extension point in the create page UI to allow plugging some cleaning
algorithm
* Provide the \ and / cleaning algorithm by default
* Handle backward compat. Find ways to not break existing users who are having / and \ in
page names. For example we could imagine a property in xwiki.properties that we would set
to point to the hint of the / and \ cleaner component. Thus existing users would need to
voluntarily upgrade their xwiki.properties to have it if they want it. We would need to
provide some script to convert existing pages with / and \ too probably.
WDYT?
About backwards compatibility, I do not get the point. What will break for
users who have already existing pages?
As long as the cleaning algorithm only runs on newly created pages there should not be
any bw/compat problem. If they really want no cleaning, we can provide
them with a property which contains the characters to be scrapped from the name with a
default value of '/\', and if they do not want this, they can set this property to
an empty value.
I prefer the implementation that I mentioned based on a component
role and provide the hint in the config. It not allows the 2 use cases mentioned above but
also any other type of custom use cases (other characters to strip, different logic, like
force all creations under a given page, etc). The idea would be to take the reference as
input and clean it and generate another reference as output (and display the cleaned
version to the user somehow so that there’s no surprise - display the value that’ll be
used as a form field hint for ex). Or what am I
missing here?
Best,
Clemens
Yeah just tested and it worked fine for me (the URL is
http://localhost:8080/bin/view/Test%20/ ).
Thanks
-Vincent
P.S. As a side note, when using MySQL creating spaces with a trailing
whitespace seem to cause some odd problems, too. I have seen at least one occurrence of an
entry in the xwikispaces with no corresponding entries in xwikidoc. This causes an entry
in the navigation tree which leads to a non-existing page and no good way to get rid of it
from a users point of view. I have not figured out how to reproduce the
problem, unfortunately.
(For the issue with trailing spaces try "select 'x' = 'x ',
'x' like 'x '; " and read
https://dev.mysql.com/doc/refman/5.7/en/char.html )
Vaguely rings a bell. Would be great to open a jira issue if you can reproduce the
issue with the query.
Thanks
-Vincent
2:26 p.m.
New subject: [xwiki-devs] [Proposal] Disallow / and \ in page names by default
On 23 Feb 2019, at 14:02, Clemens Robbenhaar
<robbenhaar(a)green-meadows.de> wrote:
Hi Vincent,
All that is done is to configure
https://github.com/xwiki-contrib/docker-xwiki/blob/master/template/tomcat/s…
If you have an apache front end, then you also need this (documented at
https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/…
):
https://httpd.apache.org/docs/current/mod/core.html#allowencodedslashes
Hi Clemens,
I’ve just tested with the
XWiki Docker image 10.11.3, where Tomcat is correctly configured and it works as it’s
supposed to:
Interesting. I run into this issue on a regular basis with the standard Debian package,
but without docker (so one gets the default Debian tomcat, which needs configuration
tweaks anyway). It seems I miss something that is configured in the docker image; but this
is not documented at
https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/…
unless I missed it there, too. (Or it is caused by having apache httpd in front of it.) I
need to check this - but nothing relevant for the discussion here. Hi devs,
Because of tomcat and because tomcat is by far the most used container for xwiki and
because we also bundle tomcat in the debian and docker dsitributions, I think we should
disallow / and \ in page names by default. It's causing too much trouble for users. We
keep having users posting problems and for one user who post a problem there are 100 who
don't.
The latest one:
https://forum.xwiki.org/t/please-help-broken-link-routing-cannot-open-page-…
+1 for me for the stripping of slashes. Even if configured properly there is a
problem with tomcat: if you create a page e.g. in the Sandbox with a title of "Page A
/ B", this creates a page with the reference "Sandbox.Page A . B.WebHome",
and you get an "empty" intermediate space. As users
mostly see titles in the current XWiki version, it should not matter to them what happens
to the page name.
Yes you’re right. But what’s important is to not change the
behavior: if they were using “/“ and “\” in page name we shouldn’t break them and they
should continue to do so unless they choose not to. However for new users we can configure
them to filter page names by default.
Hence my proposal about the new config property in xwiki.properties. When you uprgade
you’ll decide if you want to merge it or not and if not you’ll continue to get the same
behavior as before.
Implementation idea:
* Offer an extension point in the create page UI to allow plugging some cleaning
algorithm
* Provide the \ and / cleaning algorithm by default
* Handle backward compat. Find ways to not break existing users who are having / and \ in
page names. For example we could imagine a property in xwiki.properties that we would set
to point to the hint of the / and \ cleaner component. Thus existing users would need to
voluntarily upgrade their xwiki.properties to have it if they want it. We would need to
provide some script to convert existing pages with / and \ too probably.
WDYT?
About backwards compatibility, I do not get the point. What will break for
users who have already existing pages?
As long as the cleaning algorithm only runs on newly created pages there should not be
any bw/compat problem. If they really want no cleaning, we can provide
them with a property which contains the characters to be scrapped from the name with a
default value of '/\', and if they do not want this, they can set this property to
an empty value.
I prefer the implementation that I mentioned based on a component
role and provide the hint in the config. It not allows the 2 use cases mentioned above but
also any other type of custom use cases (other characters to strip, different logic, like
force all creations under a given page, etc). The idea would be to take the reference as
input and clean it and generate another reference as output (and display the cleaned
version to the user somehow so that there’s no surprise - display the value that’ll be
used as a form field hint for ex). But that is a detail; I can see the idea of a
component selected via hint is more flexible, and no objections from my side to that
approach.
Cool
Thanks
-Vincent
Best,
Clemens
P.S. yes, if I had been able to reproduce, I would have created an issue already
;)
Or what
am I missing here?
Best,
Clemens
Yeah just tested and it worked fine for me (the URL is
http://localhost:8080/bin/view/Test%20/ ).
Thanks
-Vincent
P.S. As a side note, when using MySQL creating spaces with a trailing
whitespace seem to cause some odd problems, too. I have seen at least one occurrence of an
entry in the xwikispaces with no corresponding entries in xwikidoc. This causes an entry
in the navigation tree which leads to a non-existing page and no good way to get rid of it
from a users point of view. I have not figured out how to reproduce the
problem, unfortunately.
(For the issue with trailing spaces try "select 'x' = 'x ',
'x' like 'x '; " and read
https://dev.mysql.com/doc/refman/5.7/en/char.html )
Vaguely rings a bell. Would be great to open a jira issue if you can reproduce
the issue with the query.
Thanks
-Vincent
2085
days inactive
2086
days old
5 comments
2 participants
participants (2)
-
Clemens Robbenhaar -
Vincent Massol