rename 'path alias' to 'custom url'

-1 from me. The purist in me would see "custom URL" and would enter the full URL: http://something.com/blah/, not the actual, um, "path alias" that the thing is looking for. URL actually *means* something, and that's "http://something/blah/" not "blah".

-1 from me as well, "Custom URL" just doesn't make as much sense. Then again, I do see the issues with the word "Path" but "alias" should make sense to most people.

So what about "URL alias" ? That would combine the best of both worlds, IMO :)

I have to agree with Morbus and -1 this one for the same reason. I'd say that if anything, the help text below the path alias text box should be improved. The lone example of "about" doesn't help much. A better example would be:

For example, enter "mypages/about" if you want a page to appear at http://yoursite.com/mypages/about.

Something like that would make it much clearer what part of the URL one is entering. It could even be customized to use $base_url there, so that it's site specific. :-)

I think I'd be fine with "URL path", in as much as a path is not a URL (or a shaving is not a pencil, for equivalence). "URL alias" I'd still be concerned about - there's nothing in those two words that would dissuade me from using an entire URL (unlike "URL path"). "Alternative URL path"?

Well building upon that don't we get run full circle to "URL Path Alias" ? Maybe that makes the *most* sense :)

custom link? custom address?

I agree the current label is confusing.

"Custom address" doesn't work for me - I think of address as a complete street address, or a complete web site address, not just "Concord, NH" or "blah". As for user vs. hardcore, I've no problem with that, but I will not stand for using terms improperly - that's just making users dumber, and our lives more difficult in the future.

With that said, I'd be fine with "custom address", assuming the help text gets improved per #3.

In general changing words will not help a lot. Especially if you change something into an easier, yet incorrect (or not fully covering) term.
taxonomy is just that: taxonomy. taxonomyes are not categories! A path alias is just that: an alias for a path. It is not a custom URL.
So I agre with morbus: we should not use incorrect terminology.

How about adding $base_url in front of the textfield (but not editable) ? I think we can then leave the description as custom url.

hm, I like that. It becomes a "fill in the blank" form. We'd have to size the text field properly, but that should clear up any confusion, especially if the base url also has a / after it so make it clearer that one shouldn't include that.

I agree that the current wording is confusing. I have people on one of my sites (non techies) who enter the URL of their own site in the alias field.

Custom URL is fine by me. It is a step better than the current wording, but still "URL" may be confusing.

I like the idea of preceeding it with the $base_url, but that can be very long in some cases (imagine a subdomain, a longish domain, and a directory). It can be too wide on the screen. It is still the best idea so far though, since it is a fill the blanks approach.

IMO the phrase 'custom url' is a big step up from 'path alias', so +1 from me. Back in the dark ages, when I hadn't yet discovered Drupal and was still searching for the CMS of my dreams [:-)], I was looking specifically for a CMS that supported fully configurable URLs. I remember googling for such phrases as 'url rewriting', 'clean urls', and (possibly) 'custom urls'. When I finally stumbled upon Drupal (through SpreadFirefox, just by chance), I learned that round here, my dream feature was called 'path aliasing'.

I never thought to search for 'path aliasing'. It is Drupal-specific jargon, rather than jargon that's common to many CMS's or to the web in general. Had the feature been called 'custom urls' instead, I probably would have found Drupal much sooner than I did. So I can say from personal experience that this change in woridng is long overdue.

However, the points raised are valid: 'custom url' may mislead people into thinking that they have to type in the full URL. So if this change goes through, the help text must be very explicit about what the user needs to type in. E.g.:

Enter a custom URL+ for a page on your site. Do not enter the full URL: only enter the part that comes after your site's root address. E.g. for http://www.mysite.com/drupal/node/3, only enter 'aboutme', not http://www.../aboutme'.

+1 here, too. It's such a minor change, and t's not as if reading 'custom url' will confuse people with some sort of subtle technical miscommunication.

I have to say -1, only because there's no strong consensus. A transient interface is more of a usability burden than the occasional mis-labeled field. There's enough of an existing userbase for Drupal that we should be considerate of both future users *and* existing ones.

Mind you, I'm not opposed to progress. If someone came up with the most appropriate name ever invented by a human being, everyone would wholeheartedly agree to set things straight post haste. I also look forward to other improvements down the line. But when nobody seems to feel strongly one way or the other it's a lukewarm fix to a lukewarm problem. What if someone suggests something better three months from now and it's yet another confusing UI change?

Each new release seems to introduce a whole bunch of menu moves, label changes and other weird tweaks. Half of the time I understand the intent and accept the change, but other times the cost of making everyone re-learn where something is outweighs the benefits of having put it there.

-1 because of the ambiguous use of URL.

"custom relative URL"

Because we use 'URL aliases' for the aliasing overview link I'd like to see 'Path alias' replaced with 'URL alias'. It's a small change, but adds coherency to the interface and nails down what we want.

When I initially wrote path.module, entering absolute URLs was fine. I just stripped off the $base_url and informed the user of the action. Perhaps this approach should be re-visited? I'd be more than happy to write it.

+1 I agree with Moshe, having been one of those that didn't understand what Path Alias was, but was ecstatic when I learned what it would let me do. I'm not a developer. I understand the semantic argument against using the word URL in the description. But for me, this is the URL, and I refer to the ability to "customize a URL." So my vote (for whatever it's worth) is "Custom URL" or "Customize the URL or Web Address." I like Customize better since it's an action verb.

I think 'custom URL' is more intuitive, which is what we should cater for IMO. For the caption of the actual textfield we could write 'Custom relative URL', 'Custom path' or whathever makes it clear that no absolute URL is expected. However, when people are looking at the navigation menu or the documentation, it does _not_ matter whether they have to enter an URL relative to the root, an URL relative to the Drupal installation, an absolute URL or some other kind of path. The task they are looking to complete is to customize their site's URLs. Let's call it that 'custom URLs' and let's worry about the technical details on the custom URL submission/edit form.

Two nits:
1. Write URL not url.
2. The menu item in the navigation menu needs updating too.
3. Double-check the documentation.

Please update this patch. Thanks.

Looks good to me. For extra points, rename the SQL table 'url_alias' to 'custom_urls'?

I still much prefer breyten's suggestion in comment #11. Simply prepend $base_url and a slash to the textfield, and suddenly the UI is fully understandable. I would submit a patch for that myself if I could figure out how do to that exactly using the 4.6 form API. :-) I've not touched the in-progress 4.7 form API yet (I'm still developing mostly to 4.6), so I don't know how easy that would be there, but I still believe that's the better solution.

Looks good to me. For extra points, rename the SQL table 'url_alias' to 'custom_urls'?

Ok, I'm on for extra points ;)
I get the db modifications, I'm modifying the documentation right now.
Just a question, should we care about renaming variables ($alias -> $custom_url) and what about function path_set_alias ?
Do you see any more modifications ?

Ok here we go with the renaming.
A few observations :
- should we change values in permissions table as the name is changed by this patch ?
- the handbook doc should be updated, how do I get the source to supply a patch ? Or a new version...
- should we confirm deletion of a custom URL ? It may be a little off topic, but I found this isn't handled.
- should I modify bootstrap.inc drupal_get_path_alias function ?
Making this would lead to modify block.module, commonc.inc, template.engine and maybe contributed module (dba, htmlarea, img_assist, navigation, pathauto, sections, tinymce...)
- the pid column, do I rename it ?

So I hope someone can review my doubts today, I won't be available to work on it during the WE, so I'll complete this on monday or later today, if not feel free to improve it.

- should we change values in permissions table as the name is changed by this patch?

Removing left-overs is always nice.

- the handbook doc should be updated, how do I get the source to supply a patch ? Or a new version...

Let's worry about that later.

- should we confirm deletion of a custom URL ? It may be a little off topic, but I found this isn't handled.

That would be nice, yes.

- should I modify bootstrap.inc drupal_get_path_alias function ?
Making this would lead to modify block.module, commonc.inc, template.engine and maybe contributed module (dba, htmlarea, img_assist, navigation, pathauto, sections, tinymce...)

Maybe drupal_get_url()?

- the pid column, do I rename it ?

Yes, call it 'cid' if the table is called 'custom_urls'.

Thanks! :-)

Ok, here the new version of the patch :
DB updates :
Rename table, column and update permission table.
There's just a little problem, it seems that PostgreSQL doesn't support REPLACE function until 7.3

module update :
- Added a check before deletion of a custom URL.
- Modified the bootstrap.inc function, now function drupal_get_path_alias is function drupal_get_url, this lead to changes in common.inc, block.module and phptemplate.engine. Contributed module should update too.

The code needs a little bit of work:

drupal_set_message(t('The custom URL "%custom_url" has been deleted.', array('%custom_url' => $edit['custom_url'])));

For security reasons, you should use theme('placeholder') (and drop the "s). There are 2 or 3 occurences of this problem in the patch.

+1 on the change for me. Custom URL refers to the URL which the node may be accessed by and not the value entered by the user.

Of course the user may become confused and enter a complete URL in the text field.

-1 from me on adding the base URL to the text field though. This should be placed above the text field (either immediately before or in the instructions as suggested) and it should be clear that the value entered will be appended to the base url.

For security reasons, you should use theme('placeholder') (and drop the "s). There are 2 or 3 occurences of this problem in the patch.

Done, I post the patch later, I wasn't used to use this, thanks to mention it.
Should I use it when I get something like this using url function :

$output = form_textfield(t('Custom URL'), 'path', $node->path, 60, 250, t('Optionally specify an alternative URL by which this node can be accessed. For example, enter %path if you want a page to appear at %url.', array('%path' => theme('placeholder', 'mypages/about'), '%url' => url('mypages/about', NULL, NULL, TRUE))));

Drop the 's' ? In "URLs" you mean ?

Of course the user may become confused and enter a complete URL in the text field.

I don't think there could have confusion there as the help texp makes it pretty clear I think : See code pasted above that display For example, enter mypages/about if you want a page to appear at http://192.168.0.180:8080/drupal_cvs/mypages/about. for my installation.

You need to use theme('placeholder') when printing dynamic/variable data; you don't need it for static URLs.

Ok thanks for the tip, here goes the new patch.
I updated the updates.inc to match current HEAD version.

+  elseif ($_POST['op'] == t('Create new custom URL')) {
+    $output = path_admin_delete($_POST['edit']);

As far as I can tell this condition is already matched by the first section of the if statement and this will never be executed.

Hi Drumm,
Thanks for your review, I don't know why I introduce it as it doesn't appear in my patch in #27 but in #29 it does.
So it's a mistake, I modify my sources.

I think that changing this to use URL is a bad, bad idea - it will just confuse matters more. A URL is a much more complicated thing, and most people think of "http://www.google.com/" when they think of URL.

I suggest "custom path" if "path alias" is too difficult to understand.

I think that all that needs to be done here is to document the field properly.

A path is the portion after the hostname in a URL. For example, in http://my.site.com/node/32 the path is 'node/32'. A custom path in Drupal allows you to identify a particular path by another path which is more easily understood. For example, to make this page $url_for_this_node appear as $base_url/mypage enter 'mypage' above.

I also think that renaming the table from url_alias to path_alias is much more congruent with the nature of things. But it really is unnecessary.

I think this comes down to educating the user/administrator. Just lumping the path alias terminology into the definition of a URL is a bad thing.

I'd like to commit this. Please review/test it! Thanks.

I think this patch is a bad idea. When I see "URL," I think of http://drupal.org/ or http://www.google.com/. I most certianly do not think of "mypage" or "about." If my friend asks me for the URL of my page, I don't say "clyde." I give him the whole thing, from http:// onward.

My objections aside, I did notice a problem in this patch. It seems to have conflicting database update code. For pgsql, column "pid" is renamed to "cid." For mysql, column "cid" is renamed to "cid." Clearly one of these is wrong.

I agree that this isn't really a "URL" that's up for modification, but rather the "path" PORTION of the URL. However, "path alias" is quite confusing for noobs and something that I always need to explain to new users.

The result of modifying this field, though, *is* a custom URL, so, depending on your point of view, its wording is satisfactory. I'm in favor of this change, now, today, but I think it can be improved upon later.

I really like the idea that we should prepend the $site_url before the text field (not editable). I think it would make it abundantly clear to everyone what is actually meant by this text field if it looked like:

Custom URL
http://www.drupal.org/ [______________]

But that's not possible to do with a form_textfield(). To actually do that would require making this field a form_element(), or changing form_textfield() to allow for text immediately preceeding the field. Thoughts on which direction is better?

eafarris: I like the idea you put forward. I think the visiual part is for more important than the actual words used.

efarris

You like your idea because it is "by example.

The problem is when you have a web site that has the url someverylongsubdomainname.alsoalongdomainnametoo.com/drupalinstalledinasubdirectory

How are we going to fit this on the web page without being too ugly?

Oh, and in case it is not explicitly stated above:

+1 for "Custom URL"

As I told to dev list, I don't understand why people want to add $base_url to the beginning of the text_field ?
I found the help below, very explicit, I don't understand why people should type full URL unless they don't read help message.

@clydefrog: thanks for the catch, I corrected it for next roll of the patch.

@kbahey:
whats about replacing it when more then... say 33 chars:
with
http://www.yourdomain.com/
or
http://www.sitesdomain.com/
http://www.example.com/

and in the title-attribute comes the real url

I thought about shorten it... but this gets too ugly and no one can guess what was meant

Bingo! eafarris got it. donuts for you!

+1 on visual cues ( hxxp://www.drupal.org/ [______________] )
-1 on changing function names from _path_ to _url_ - bad idea
-1 on changing the database table name (url_alias is ok - path_alias would be excellent)

I think the underlying functions are named correctly (based on path) because that's exactly what they do. If the functions are extended to work on URLs, then they should be renamed to reflect that functionality. Because these functions don't, then they should only be based on the path.

This problem is best addressed by changing the documentation, not the functions. "Custom URL" is ok in the documentation (using eafarris' visual aid - it works very well), but the underlying system should not be burdened by this documentation effect.

Look at this one statement:

$path = drupal_get_url($path);

So, what is $path being set to here? A URL? Very confusing, if you ask me. The original code was much more understandable:

$path = drupal_get_path_alias($path);

Ah, yes... I'm getting the alias for $path. I understand now.

This issue seems to have been brought up by UI problems - not programmatic problems. I say leave the functions/db alone. My $0.02.

Tobias

That would work.

A better approach is to use the ellipses approach.

If the site URL is too long (longer than 20 characters or so), then it is displayed as

hxxp://www.....com/ [________________]

This way the screen width is not affected ...

#42 - kbahey

If someone has a host is named: someverylongsubdomainname.alsoalongdomainnametoo.com/drupalinstalledinasubdirectory

That person has a LOT more problems to worry about than just how whether their sitename fits on an admin page.

;)

I think the eafarris concept will solve the problem for 99% of the people out there.

Abe said it best:

You can fool all the people some of the time, and some of the people all the time, but you cannot fool all the people all the time.

Here's my patch. Try it out - uses the eafarris concept and has a link to the help added.
I also updated the help to include the base url as well.

I don't like adding so much base_url everywhere, basic help is usefull and clear enough to me.

-1 on the existing patches.

Renaming functions and/or tables seems unnecessary and inappropriate. The current names are accurate. In my opinion, changing the text here and there would be sufficient to clarify this feature. Further, the text most visible to content contributors has not been clarified in my opinion.

Here are my suggestions for changes to text.

node/add and node/edit

Current
Path Alias
Optionally specify an alternative URL by which this node can be accessed. For example, type "about" when writing an about page. Use a relative path and don't add a trailing slash or the URL alias won't work.

Proposed
Custom URL (or perhaps leave as is. insufficient support for changing this?)
Optionally create a custom URL by which this content can be accessed by entering an alternative path. For example, type "mypages/about" when writing an about page. Use a relative path and don't add leading or trailing slashes.

admin/modules

Current
Allows users to rename URLs.

Proposed
Allows users to create custom URLs (URL alias') for content.

admin/path

Current
Drupal provides users complete control over URLs through aliasing. This feature is typically used to make URLs human-readable or easy to remember. For example, one could map the relative URL 'node/1' onto 'about'. Each system path can have multiple aliases.

Proposed
Drupal provides users complete control over URLs through aliasing. This feature is typically used to make URLs human-readable or easy to remember. For example, one could map the system path 'node/1' onto 'about.' Each system path can have multiple aliases.

admin/help/path

Current
A very powerful feature of Drupal is the ability to have control over all paths. The path module is the tool that provides this functionality and is part of the basic Drupal installation, although it is not enabled by default. Some examples of re-mapping paths are:

Proposed
The path module enables the user to create a custom URL (or alias) for all content. Only a relative path (i.e., custom portion of the URL) need be entered to create a custom URL. Some examples of re-mapping paths are:

I leave it to current patch contributors to use the updated text. In my opinion, the much of the existing labels are accurate and descriptive. Short of renaming the path module to 'custom_url' (which I would not promote) only prompt text should be modified to educate the user what the terms 'path' and 'alias' refer to. Note that I used both terms in the module description text so that admins will make the link between the path module and the 'url alias' menu item.

@tangent: I like your text. It does a better job of briefly explaining the function of the path module. I have one grammatical correction:

Allows users to create custom URLs (URL alias') for content.

Should be:

Allows users to create custom URLs (URL aliases) for content.

Apostrophes indicate possessives. "URL aliases" is a plural.

@ #49: Patch applies cleanly, but I don't know that it works as well with the $base_url listed above the text area. It's not as clean that way and doesn't have the same positive usability effect that putting it on the same line would. Also, it only affects the admin/path area, not node/*/edit. I'd think the latter is the bigger usability challenge, frankly.

@ #47: +1 on the ellipsis solution to the too-long-domain problem. We still need to get it down on the same line as the text area, though. Anyone know if the new form API can do that?

I would just like to add that this field is actually a path alias and not a custom url. Not only for the above reasons, but also because we are not renaming node/x to newpath, but we are aliasing newpath to node/x. The both still will work, and therefore it is an alias. Alias is in the english dictionary, and is well understood in the English speaking world.

There are internal paths and external paths.

Internal paths are rewritten with an 'outgoing' rewrite to external paths, and vice versa with an 'incoming' rewrite.

The path module is a path rewriting engine and not an url rewriting engine. It maps an internal path to an external path. An url rewriting engine could use information from the server host name and e.g. rewrite http://blog.domain.com/something to http://www.domain.com/blog/something and vice versa.

So path alias is a very nice name for the usage of the path module.

-1

there has been a lot of discussion on this with a lot of disagreement. With the forms patch, you can individually theme form elements, for example exchange the description and title of such a form element. Marking this fixed.