Hi Vincent,
Hi Clemens,
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-from-navigation-any-help-appreciated/4448
+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.
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/InstallationWAR/InstallationTomcat/#HTroubleshooting
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.
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.
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.
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).
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
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.
Yeah just tested and it worked fine for me (the URL is
http://localhost:8080/bin/view/Test%20/ ).
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
P.S. yes, if I had been able to reproduce, I would have created an issue
already ;)
