> On 23 Feb 2019, at 14:02, Clemens Robbenhaar <robbenh...@green-meadows.de>
> wrote:
>
> 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.
All that is done is to configure
https://github.com/xwiki-contrib/docker-xwiki/blob/master/template/tomcat/setenv.sh#L33
If you have an apache front end, then you also need this (documented at
https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/InstallationWAR/InstallationTomcat/#HAllowing222F22and225C22inpagenames
):
https://httpd.apache.org/docs/current/mod/core.html#allowencodedslashes
>
>>> 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.
Yes, we can have a default component implementation (a “stripping” one that is
customizable and which allows choosing stripping a set of characters).
> 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
>
>>> 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 ;)
