Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
i have had several people frown and ask what the heck we mean in the posting UI by 'path alias'. Once I explain, they adore the feature and suggest the alternative wording 'custom url'. So here is a patch which changes the user facing name of this feature. Admin area is unchanged and probably shouldn't be since the concept of an alias is more important there.
Comment | File | Size | Author |
---|---|---|---|
#49 | path.module-bh1.patch | 5.82 KB | bhagman |
#34 | custom_url_3.patch | 27.9 KB | tostinni |
#29 | custom_url_2.patch | 27.85 KB | tostinni |
#27 | custom_url_1.patch | 23.24 KB | tostinni |
#22 | custom_url_0.patch | 14.59 KB | moshe weitzman |
Comments
Comment #1
Morbus Iff-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".
Comment #2
m3avrck CreditAttribution: m3avrck commented-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 :)
Comment #3
Crell CreditAttribution: Crell commentedI 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. :-)
Comment #4
Morbus IffI 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"?
Comment #5
m3avrck CreditAttribution: m3avrck commentedWell building upon that don't we get run full circle to "URL Path Alias" ? Maybe that makes the *most* sense :)
Comment #6
nedjocustom link? custom address?
I agree the current label is confusing.
Comment #7
moshe weitzman CreditAttribution: moshe weitzman commentedcome on. our goal here is not to prevent a hard core developer from typing in 'http'. we are trying to make software that normal people can use without stressing their brains. neither 'path' nor 'alias' contribute toward this goal.
'custom' is good because joe user gets it through his head that he can control the urls. this is a mind blowing moment for many new users. they never had it so good! 'url' isn't that great, and morbus might get confused by it (cough cough). so i like 'custom address' a lot.
Comment #8
Morbus Iff"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.
Comment #9
Morbus IffWith that said, I'd be fine with "custom address", assuming the help text gets improved per #3.
Comment #10
Bèr Kessels CreditAttribution: Bèr Kessels commentedIn 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.
Comment #11
breyten CreditAttribution: breyten commentedHow about adding $base_url in front of the textfield (but not editable) ? I think we can then leave the description as custom url.
Comment #12
Crell CreditAttribution: Crell commentedhm, 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.
Comment #13
kbahey CreditAttribution: kbahey commentedI 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.
Comment #14
Jaza CreditAttribution: Jaza commentedIMO 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'.
Comment #15
eaton CreditAttribution: eaton commented+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.
Comment #16
Allie MickaI 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.
Comment #17
brdwor CreditAttribution: brdwor commented-1 because of the ambiguous use of URL.
"custom relative URL"
Comment #18
matt westgate CreditAttribution: matt westgate commentedBecause 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.
Comment #19
elichapman CreditAttribution: elichapman commented+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.
Comment #20
Dries CreditAttribution: Dries commentedI 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.
Comment #21
Uwe Hermann CreditAttribution: Uwe Hermann commentedComment #22
moshe weitzman CreditAttribution: moshe weitzman commentedthis patch changes lots of UI from alias to custom URL. I hope thats what was requested. If this isn't desired, pelase consider using my prior patch as a basis for the commit.
Comment #23
Dries CreditAttribution: Dries commentedLooks good to me. For extra points, rename the SQL table 'url_alias' to 'custom_urls'?
Comment #24
moshe weitzman CreditAttribution: moshe weitzman commentedsorry - i can't work for extra points right now. if someone undertakes this, you might also automatically migrate the old permissions to the new ones in the permissions table. the names have changed.
Comment #25
Crell CreditAttribution: Crell commentedI 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.
Comment #26
tostinni CreditAttribution: tostinni commentedOk, 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 ?
Comment #27
tostinni CreditAttribution: tostinni commentedOk 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.
Comment #28
Dries CreditAttribution: Dries commented- 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! :-)
Comment #29
tostinni CreditAttribution: tostinni commentedOk, 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
isfunction drupal_get_url
, this lead to changes in common.inc, block.module and phptemplate.engine. Contributed module should update too.Comment #30
Dries CreditAttribution: Dries commentedThe 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.Comment #31
tangent CreditAttribution: tangent commented+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.
Comment #32
tostinni CreditAttribution: tostinni commentedDone, 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 :Drop the 's' ? In "URLs" you mean ?
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.Comment #33
Dries CreditAttribution: Dries commentedYou need to use theme('placeholder') when printing dynamic/variable data; you don't need it for static URLs.
Comment #34
tostinni CreditAttribution: tostinni commentedOk thanks for the tip, here goes the new patch.
I updated the updates.inc to match current HEAD version.
Comment #35
drummAs far as I can tell this condition is already matched by the first section of the if statement and this will never be executed.
Comment #36
tostinni CreditAttribution: tostinni commentedHi 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.
Comment #37
bhagman CreditAttribution: bhagman commentedI 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.
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.
Comment #38
Dries CreditAttribution: Dries commentedI'd like to commit this. Please review/test it! Thanks.
Comment #39
ezheidtmann CreditAttribution: ezheidtmann commentedI 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.
Comment #40
eafarris CreditAttribution: eafarris commentedI 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?
Comment #41
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedeafarris: I like the idea you put forward. I think the visiual part is for more important than the actual words used.
Comment #42
kbahey CreditAttribution: kbahey commentedefarris
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?
Comment #43
kbahey CreditAttribution: kbahey commentedOh, and in case it is not explicitly stated above:
+1 for "Custom URL"
Comment #44
tostinni CreditAttribution: tostinni commentedAs 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.
Comment #45
Tobias Maier CreditAttribution: Tobias Maier commented@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
Comment #46
bhagman CreditAttribution: bhagman commentedBingo! 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.
Comment #47
kbahey CreditAttribution: kbahey commentedTobias
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 ...
Comment #48
bhagman CreditAttribution: bhagman commented#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:
Comment #49
bhagman CreditAttribution: bhagman commentedHere'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.
Comment #50
tostinni CreditAttribution: tostinni commentedI don't like adding so much base_url everywhere, basic help is usefull and clear enough to me.
Comment #51
tangent CreditAttribution: tangent commented-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
admin/modules
admin/path
admin/help/path
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.
Comment #52
ezheidtmann CreditAttribution: ezheidtmann commented@tangent: I like your text. It does a better job of briefly explaining the function of the path module. I have one grammatical correction:
Should be:
Apostrophes indicate possessives. "URL aliases" is a plural.
Comment #53
Crell CreditAttribution: Crell commented@ #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?
Comment #54
brdwor CreditAttribution: brdwor commentedI 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.
Comment #55
dfg CreditAttribution: dfg commentedThere 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
Comment #56
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedthere 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.
Comment #57
(not verified) CreditAttribution: commented