Hi,
the solution I've described is javascript based and runs on client-side.
require to have url-friendly conversion component usable in java
and not as
javascript code. Am I right?
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.
>
>