On 21 Apr 2017, at 16:19, Miroslav Galajda
<miroslav.galajda(a)gmail.com> wrote:
Hi, the slugify is different component than speakingurl, but currently it
doesn't matter on this.
Ok, how would we solve this globally? Not only in default page creation
process but also in custom applications, that create pages in their own.
For example the FAQ uses this code to redirect to new FAQ page after
entering question name:
#set ($newFAQReference = $services.model.createDocumentReference('', '',
"$question"))
$response.sendRedirect($xwiki.getURL($newFAQReference, 'inline',
"$!{request.queryString}&title=${escapetool.url($question)}"))
The solution you propose will be transparent for this code or will it
require som modifications?
My proposal is to do 2 things:
1) Introduce some new Component in XWiki Platform. I don’t know where. It could be inside
some existing modules in
or introduce a new
one in there.
So a Component + a Script Service so that it can be accessed from wiki pages inside
scripts (velocity, groovy, etc).
This should cater for the need to be able to use it from anywhere.
It’s basically a clean up/transformation of String into something human-readable.
2) Introduce a UIXP inside createinline.vm to allow extenders to contribute some sections
in the Create UI. Actually the current “Location” section could even be refactored to be
implemented using a UIX for this UIXP. Several UIX could be contributed with an order and
they’d appear in the defined order.
For more on UIXP, see
3) You could then implement an optional UIX to introduce a new URL section that would use
1) to display what URL would be used for example. It could also let the user modify the
last part of the URL.
What I haven’t thought about yet is how this UIX will pass back the document name to
createinline.vm. Maybe these UIX would be allowed to modify variables in the
Velocity/Script context and that would be enough.
It probably needs to be brainstormed a bit more but this is the idea I have so far. I’d
also like to have @Caty’s POV on the UI aspect/Layout of such a UIXP concept.
WDYT Miroslav?
Thanks
-Vincent
On 21 April 2017 at 16:00, Vincent Massol <vincent(a)massol.net> wrote:
>
>> On 21 Apr 2017, at 15:36, Miroslav Galajda <miroslav.galajda(a)gmail.com>
> wrote:
>>
>> Hi,
>> the solution I've described is javascript based and runs on client-side.
>> From what I know, the component-based solution, which you propose, would
>> require to have url-friendly conversion component usable in java and not
> as
>> javascript code. Am I right?
>
> Yes you’re right but:
>
> 1) There’s also a Java API, see
https://github.com/slugify/slugify
> 2) If we also offer a UIX then it can be implemented in a wiki page for
> example and you can use JS.
>
> Thanks
> -Vincent
>
>> On 21 April 2017 at 15:28, Vincent Massol <vincent(a)massol.net> wrote:
>>
>>> Hi Miroslav,
>>>
>>>> On 21 Apr 2017, at 15:05, Miroslav Galajda
<miroslav.galajda(a)gmail.com
>>
>>> wrote:
>>>>
>>>> Hi, let me enter into this conversion.
>>>> Some time ago I've asked for help how to solve problem with
diacritics
>>> (or
>>>> accents) in page names when creating new pages so that the have
>>>> url-friendly names. You can search for "strip accents from page
name
> used
>>>> in url" in xwiki users mailing list. I've got no hint or
solution from
>>>> xwiki community till today.
>>>>
>>>> I've come with solution that ensures for simple users, creating
>>>> url-friendly names without requiring them to think about the concept of
>>> the
>>>> page name or page title. They simple enter the desired human readably
>>> page
>>>> name, and in the code behind of the page creation, I have made some
>>>> modifications in createinline.vm to hook into page creation process.
> The
>>>> modifications are mainly javascript based, where I've attache to
submit
>>>> event of the "form#create", where I replace the entered
"title" with
> the
>>>> one for url-friendly. And for url-friendly name I've used this
> javascript
>>>> based solution on
https://pid.github.io/speakingurl/.
>>>> I've integrated this principle also into page creation process of
FAQ
> and
>>>> Blog applications, which we are using in our xwiki installation.
>>>>
>>>> It would be nice if you could integrate this principle into xwiki so
> that
>>>> everyone can have nice url-friendly urls without worring about it. It
> is
>>>> also suitable for english speaking users. You don't have to worry
about
>>>> entering spaces or other non-url allowed characters, which make url
> look
>>>> ugly.
>>>
>>> That looks very nice!
>>>
>>> One way forward I could think about:
>>> * We provide some Create script service to return a URL-friendly string.
>>> We introduce a component role for this. We refactor createinline.vm to
> use
>>> it and to display the URL.
>>> * You could then contribute your code as an extension that we make
>>> available on
extensions.xwiki.org for users to install
>>> * We decide later on if we want to bundle it by default
>>>
>>> If we don’t agree about displaying the URL by default all the time then
> an
>>> option is to introduce a UIX in createinline.vm for that. And this
> could be
>>> implemented in your extension too for example or by default in XWiki
>>> (possibly with an Admin setting).
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
>>>
>>>>
>>>> Thank you
>>>>
>>>> Best regards
>>>> Miroslav Galajda
>>>>
>>>> On 21 April 2017 at 14:02, Vincent Massol <vincent(a)massol.net>
wrote:
>>>>
>>>>>
>>>>>> On 21 Apr 2017, at 13:52, Marius Dumitru Florea <
>>>>> mariusdumitru.florea(a)xwiki.com> wrote:
>>>>>>
>>>>>> On Fri, Apr 21, 2017 at 2:16 PM, Vincent Massol
<vincent(a)massol.net>
>>>>> wrote:
>>>>>>
>>>>>>> Hi Caty,
>>>>>>>
>>>>>>>> On 21 Apr 2017, at 12:44, Ecaterina Moraru (Valica) <
>>> valicac(a)gmail.com
>>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Let's see what variants we have:
>>>>>>>>
>>>>>>>> 1. Instead of displaying "Title", display the
"Name" instead.
>>>>>>>> This won't solve anything. There is no difference
between Page Name
>>> and
>>>>>>>> Page Title for the normal users. Seeing "Name"
instead of "Title",
>>> will
>>>>>>> not
>>>>>>>> stop the users to enter spaces if they want, so the URL
will still
>>> have
>>>>>>>> those spaces. We don't force the Page Names to trim
spaces.
>>>>>>>>
>>>>>>>> One quick solution here is indeed to use "URL"
label instead of
>>> "Name".
>>>>>>> For
>>>>>>>> the reasons Vincent mentioned this might not end up in
the product
>>> for
>>>>>>> now,
>>>>>>>
>>>>>>> What did I mention? :) What’s preventing us from having it in
the
>>>>> product
>>>>>>> rather soon than later (except workload ofc)?
>>>>>>>
>>>>>>>> so you will need to do some custom development (changing
some
>>>>>>> translations)
>>>>>>>> to have this change. If you want to be
"hackish" you can even
> change
>>>>> the
>>>>>>>> translation for "Title" to "URL"
instead and hope that your users
>>> will
>>>>>>>> enter shorter URLs (since we generate the name from the
title).
>>>>>>>>
>>>>>>>> Displaying just Name / URL, means users will still have
to go and
>>>>> change
>>>>>>>> the title manually.
>>>>>>>
>>>>>>> This could be better (with URL name) since when you create a
page
>>> you’re
>>>>>>> offered the ability to change the title after you click
Create.
>>>>>>>
>>>>>>>> The only way to cut a step in the flow is to
>>>>>>>> autogenerate the page names (which we currently do). But
for your
> use
>>>>>>> case
>>>>>>>> you shoyld write a shorting/trimming algorithm, but this
is custom,
>>>>> since
>>>>>>>> you mentioned you want just the initials and no spaces,
etc.
>>>>>>>>
>>>>>>>> 2. Displaying both "Title" and
"Name". This will create confusion
> and
>>>>>>> need
>>>>>>>> for explanations.
>>>>>>>
>>>>>>> This is not exactly what is suggested either by Vishal nor by
me :)
>>> What
>>>>>>> we suggested is to let the user enter the URL name and
title.
>>>>>>>
>>>>>>> Actually and to be more precise what I was suggesting was to
> continue
>>> to
>>>>>>> let the user enter the title but to show the generated URL as
it’s
>>> done
>>>>> in
>>>>>>> AWM. And, importantly to allow the user to change the last
part of
> the
>>>>> URL
>>>>>>> (it would change the page name).
>>>>>>>
>>>>>>>> That's why we display these options just for advanced
and
>>>>>>>> long-time users of XWiki, since they are used to the
concepts.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>> Yes but URLs don't need an advanced user to understand
the concept
>>> and I
>>>>>>> agree with Vishal that we’re now causing a very large number
of
> pages
>>> to
>>>>>>> have %25 in their URLs by default which is quite bad… Of
course
>>> someone
>>>>> can
>>>>>>> spend their time monitoring what users are doing and renaming
pages
>>>>>>> thereafter or educate their users to do that but we’re not
helping
> and
>>>>>>> we’re making it difficult.
>>>>>>>
>>>>>>
>>>>>> If your web site is not in English then you're forced to use
special
>>>>>> characters like diacritics which makes it hard to avoid URL
encoded
>>>>>> characters (the browser location bar displays the URL nicely but
if
> you
>>>>>> copy the URL the result is not nice).
>>>>>
>>>>> Agreed. So I’d say it’s even more important to allow the user to be
> able
>>>>> to easily view and change the resulting URL when they’re not in
> English.
>>>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> -----
>>>>>>>>
>>>>>>>> IMO what you are describing is advanced user behavior.
Normal users
>>>>> don't
>>>>>>>> generally care about their URLs and SEO.
>>>>>>>
>>>>>>> I don’t fully agree with you. I have the feeling (can’t prove
it)
>>> that a
>>>>>>> good number of our users care about the generated URLs.
>>>>>>>
>>>>>>
>>>>>>> Also I think that simple users may care about URL without
being
>>> advanced
>>>>>>> users. Making them advanced users will expose them to a lot
more
>>>>> complexity
>>>>>>> than they need to know.
>>>>>>>
>>>>>>>> But the beauty of XWiki is that
>>>>>>>> you can customize it locally to perfectly match your
needs.
>>>>>>>
>>>>>>> That’s not exactly true (and it’s far from being easy, just
check
>>>>>>> createinline.vm): It means overriding large portions of vm
code and
>>>>> having
>>>>>>> to do manual merges whenever you upgrade. A major PITA.
>>>>>>>
>>>>>>>> Vincent mentioned something about AWM. I don't see
much difference
>>> from
>>>>>>> the
>>>>>>>> Create Page. We generate the names from title here too.
We display
>>> them
>>>>>>> in
>>>>>>>> the breadcrumb, but in a more simple way. Displaying the
>>>>>>> "localhost"/server
>>>>>>>> part is not simple user behavior. AWM is more complex.
>>>>>>>>
>>>>>>>> -----
>>>>>>>>
>>>>>>>> So I would not change anything on the product side, since
I believe
>>>>> these
>>>>>>>> should be solved as custom changes for your instance.
>>>>>>>> We want to encourage users to use page titles (with
spaces in them
>>>>> since
>>>>>>>> they are more readable and supported), while we are
preserving the
>>> page
>>>>>>>> name behavior for advances users (but we don't
enforce it).
>>>>>>>
>>>>>>> I don’t agree with this sentence: We definitely don’t want
to
>>> encourage
>>>>>>> users to use titles in URLs.
>>>>>>>
>>>>>>>> If users made
>>>>>>>> mistakes they can always change the title or rename the
page.
>>>>>>>> On the product side the only change I would like us to do
is using
>>> the
>>>>>>> URL
>>>>>>>> naming, but this was debated in the past and dropped for
Vincent's
>>>>>>> reasons.
>>>>>>>
>>>>>>> What reasons, I don’t remember a discussion about using URL
name
>>> instead
>>>>>>> of page name?
>>>>>>>
>>>>>>> So our main disagreement is that I consider that favouring
encoded
>>>>>>> characters in URLs is not a good thing while you think it’s
not a
>>> large
>>>>>>> enough problem to do something about it.
>>>>>>>
>>>>>>> Would it make our UI too complex to use for simple users if
we were
>>>>>>> showing a URL and the ability to change the last part of it?
IMO
>>> what’s
>>>>>>> complex is when we have Page name and Page Title. But I don’t
feel
>>>>> there’d
>>>>>>> be confusion between URL and Page title.
>>>>>>>
>>>>>>> What do others think?
>>>>>>>
>>>>>>> Thanks
>>>>>>> -Vincent
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Caty
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Apr 20, 2017 at 11:57 PM, Vincent Massol <
> vincent(a)massol.net
>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 20 Apr 2017, at 22:51, Vincent Massol
<vincent(a)massol.net>
>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Vishal,
>>>>>>>>>>
>>>>>>>>>> Ok, I misunderstood you in your first email. I
understood the
>>>>> opposite.
>>>>>>>>> I thought you were complaining that have 2 notions
(page name +
> page
>>>>>>> title)
>>>>>>>>> was confusing but it’s actually the opposite! What
you find
>>> confusing
>>>>> is
>>>>>>>>> the fact that it’s not easy for your users to set
both the page
> name
>>>>> and
>>>>>>>>> page titles!
>>>>>>>>>>
>>>>>>>>>> It’s funny (or not :)) since this is exactly what
we had in past
>>>>>>>>> versions of XWiki and we had several complaints that
it was
>>> confusing
>>>>> to
>>>>>>>>> have the 2 notions and this is why he hid the page
name only for
>>>>>>> advanced
>>>>>>>>> users.
>>>>>>>>>
>>>>>>>>> Actually, if I remember well, what we were doing was
to ask for
> the
>>>>> page
>>>>>>>>> name and we were setting the title to the same as the
page name by
>>>>>>> default
>>>>>>>>> and then the user could edit the title before saving
the page.
>>>>>>>>>
>>>>>>>>> We’ve now done the opposite (user deciding on the
title and page
>>> name
>>>>>>>>> being derived from it) but leading to the issue
you’re raising
> about
>>>>> URL
>>>>>>>>> SEO…
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> -Vincent
>>>>>>>>>
>>>>>>>>>> See below.
>>>>>>>>>>
>>>>>>>>>>> On 20 Apr 2017, at 14:20, Vishal
<thewikinoteorg(a)gmail.com>
>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks Vincent for your thorough reply..
>>>>>>>>>>> You guessed it right. We intend to have clean
and short urls for
>>> SEO
>>>>>>>>>>> reasons.
>>>>>>>>>>> Current scheme creates two problems:
>>>>>>>>>>>
>>>>>>>>>>> 1) The Page name is fetched automatically
from the Title. Often
>>> the
>>>>>>>>> titles
>>>>>>>>>>> have spaces which translate as *percent
characters *in url which
>>>>> makes
>>>>>>>>> it
>>>>>>>>>>> somewhat unclean :)
>>>>>>>>>>
>>>>>>>>>> Indeed you’re right. By hiding the page name
we’re now incitating
>>> to
>>>>>>>>> have longer URLs and encoded characters showing up in
URLs which
> is
>>>>> not
>>>>>>>>> nice I agree.
>>>>>>>>>>
>>>>>>>>>> Maybe one solution is to do something similar to
what we do in
> AWM,
>>>>>>> i.e.
>>>>>>>>> generate automatically the URL from the title entered
by the user
>>> and
>>>>>>> show
>>>>>>>>> the resulting URL to the user and give the user the
opportunity to
>>>>>>> change
>>>>>>>>> the URL.
>>>>>>>>>>
>>>>>>>>>> See
http://extensions.xwiki.org/xwiki/bin/download/Extension/
>>>>>>>>>
App%20Within%20Minutes%20Application/AppWithinMinutes-Step1.png
>>>>>>>>>>
>>>>>>>>>>> 2) Secondly, to have the shorter url, we use
only the short
> forms
>>> of
>>>>>>>>>>> complete title.
>>>>>>>>>>> Ex. For title 'Pune University' we
use name PU.
>>>>>>>>>>
>>>>>>>>>> Hey, you’re from Pune? :) I’ve been there about
15 times! That
> was
>>>>> in a
>>>>>>>>> previous job where my company and KPIT Cummins were
partners.
>>>>>>>>>>
>>>>>>>>>>> Otherwise in this hierarchy of pages, the url
would be much
>>> longer.
>>>>>>>>>>> Ex. We have page 'Electronics and
Telecommunications' branch
> under
>>>>>>> page
>>>>>>>>>>> 'Pune University'. We should not have
such a long url. Instead
>>> here
>>>>> we
>>>>>>>>> need
>>>>>>>>>>> PU/ENTC or Pune-University/ENTC
>>>>>>>>>>>
>>>>>>>>>>> To avoid all this, what we currently do:
>>>>>>>>>>> 1) On create page dialog, use PU as title..
This will create url
>>> as
>>>>>>> PU.
>>>>>>>>>>> If full name is used here as title, we need
to use - instead of
>>>>> spaces
>>>>>>>>> to
>>>>>>>>>>> avoid percent characters in url.
>>>>>>>>>>> 2) While in edit mode, change the title back
to Pune University.
>>>>>>> Remove
>>>>>>>>> any
>>>>>>>>>>> - characters to make title clean.
>>>>>>>>>>> This is where confusion creeps in.
>>>>>>>>>>>
>>>>>>>>>>> If these two terms create confusion, why I
need to show them
> both:
>>>>>>>>>>> I guess the *confusion is due to term Name*.
It doesn't reflect
>>>>> actual
>>>>>>>>> usage
>>>>>>>>>>> of the term. URL or weblink or link or web
address would be more
>>> apt
>>>>>>>>> terms
>>>>>>>>>>> to use to instead of Name.
>>>>>>>>>>
>>>>>>>>>> Regarding Page name vs Page URL.
>>>>>>>>>>
>>>>>>>>>> A bit of history: The reason we used page name
and not page URL
>>>>>>>>> originally is because what the user is creating is a
document in
> the
>>>>>>>>> database and initially it was called Document Name.
Since that
> was a
>>>>> bit
>>>>>>>>> confusing for users, we had decided to call it Page
Name. It just
>>>>>>> happened
>>>>>>>>> that the URL used was directly derived from the
document/page
> name.
>>>>>>>>>>
>>>>>>>>>> In practice the 3 concepts could have different
values:
>>>>>>>>>> * a value for the document’s name in the DB
>>>>>>>>>> * another value for the document’s title
>>>>>>>>>> * yet another value used in the URL.
>>>>>>>>>>
>>>>>>>>>> We’ve had discussions so that we could let the
user provide
> shorter
>>>>>>> URLs
>>>>>>>>> for pages in the future.
>>>>>>>>>>
>>>>>>>>>> Now for the time being and since we don’t have
this ATM, I think
> I
>>>>>>> agree
>>>>>>>>> with you that we could decide to display to the user
the URL that
>>> will
>>>>>>> be
>>>>>>>>> generated (the encoded URL) and allow the user to
change it.
>>>>> Internally
>>>>>>> the
>>>>>>>>> user would change the document name.
>>>>>>>>>>
>>>>>>>>>>> My users can differentiate between Title and
URL. But the whole
>>>>>>>>> procedure we
>>>>>>>>>>> follow is certainly not understandable by
all. And we definitely
>>>>> need
>>>>>>> to
>>>>>>>>>>> follow this whole long procedure, just to
have short and clean
>>> urls.
>>>>>>>>>>
>>>>>>>>>> Yes, if you’re asking your users to care about
the URLs that get
>>>>>>>>> generated, right now they need to be advanced users
to be able to
>>> edit
>>>>>>> the
>>>>>>>>> page name in the Create Page UI (since changing the
title
> afterwards
>>>>> is
>>>>>>> too
>>>>>>>>> cumbersome).
>>>>>>>>>>
>>>>>>>>>>> So, by showing both fields at the first place
itself, I would
> like
>>>>> to
>>>>>>>>>>> shorten the procedure and url length.
>>>>>>>>>>
>>>>>>>>>> I’m in agreement with you. Let’s see what others
think.
>>>>>>>>>>
>>>>>>>>>> Thanks for this interesting discussion!
>>>>>>>>>> -Vincent
>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> View this message in context:
http://xwiki.475771.n2.nabble.
>>>>>>>>>
com/Page-Title-and-Name-confusion-tp7603546p7603551.html
>>>>>>>>>>> Sent from the XWiki- Users mailing list
archive at
Nabble.com.
>>>>>
>>>>>
>>>
>>>
>
>