[drupal-docs] [bug] Inconsistent behavior of URL aliases in user-specified paths

[killes]

Issue status update for 
http://drupal.org/node/9477
Post a follow up: 
http://drupal.org/project/comments/add/9477

-Project:      Drupal
+Project:      Documentation
 Version:      <none>
-Component:    base system
+Component:    Developer Guide
 Category:     bug reports
-Priority:     normal
+Priority:     critical
 Assigned to:  JonBob
 Reported by:  JonBob
 Updated by:   killes at www.drop.org
 Status:       active

Moving as suggested and setting to critical. The menu system isn't
understood by everyone and we sure need up to date docs on it.




killes at www.drop.org



Previous comments:
------------------------------------------------------------------------

Fri, 23 Jul 2004 13:14:37 +0000 : JonBob

Currently Drupal is rather schizophrenic when it comes to handling
user-specified paths. We don't require the user to type in paths often,
which is good, but there are a few situations where this is unavoidable.
Examples are menu administration, settings for 403/404 pages, the front
page selection, and block path regular expressions. In these locations,
there is no clear policy for whether the user is expected to enter an
aliased or real Drupal path, and we certainly don't tell the user in
the help text. We should decide on a policy, document it in the code
and/or user help, and enforce it in the modules.


The possible policies I can imagine are:
1) Require the user to enter a real Drupal path.
2) Require the user to enter an aliased path.
3) Allow the user to enter either, but always store a real Drupal path.
4) Allow the user to enter either, but always store an aliased path.
5) Allow the user to enter either, store what the user entered, and
convert at read time.


Now 1 and 3 have the advantage that if the alias for a page changes,
links to that page in the various settings pages do not break. 2 and 4,
on the other hand, allow the administrator to affect what page a setting
refers to by simply changing a path alias, which could be construed as
good behavior. 3 and 4 have the downside of possibly presenting the
admin with different information than she entered when she goes back to
edit it later. 5 is the most permissive, but is the hardest policy to
enforce because the value could be read in many different places in the
code. Also, with 5 the behavior is like 1 and 3 if the user enters a
real path or 2 and 4 if the user enters an alias. This is good because
it allows the administrator to have the behavior she wants, but bad
because it is inconsistent.


What policy should we go with? I'm leaning toward either 3 or 5. Once
we decide, I will:
- Add documentation about the decision in the code
- Change existing usage to match the decision
- Update user documentation on the administration pages (probably only
necessary with approach 1 or 2)




------------------------------------------------------------------------

Fri, 23 Jul 2004 15:11:49 +0000 : JonBob

Another note: policies 3 and 4 will not work with block paths, as we
cannot reliably convert the regex to the appropriate form. With these,
we must perform any necessary conversion on the path that is being
matched against the regex instead of on the regex itself.




------------------------------------------------------------------------

Tue, 27 Jul 2004 16:15:20 +0000 : JonBob

The issue Xtemplate mission does not work with an alias [1] is really a
part of this one.
[1] http://drupal.org/node/view/7685




------------------------------------------------------------------------

Wed, 19 Jan 2005 19:42:00 +0000 : JonBob

Attachment: http://drupal.org/files/issues/menu_17.patch (781 bytes)

Here's a patch to bring the menu system in line with #5, which seems to
be the user expectation.


Any advice on where to document the appropriate behavior for modules?
Perhaps the PHPdoc for drupal_get_path_alias()?




------------------------------------------------------------------------

Thu, 27 Jan 2005 17:22:52 +0000 : JonBob

The patch here has been applied, but I still need to know where to add
documentation. Anyone? Anyone? Bueller?




------------------------------------------------------------------------

Tue, 26 Jul 2005 13:35:48 +0000 : wulff

The current documentation documents policy #1.


Since the patch has been applied, should this be moved to the
Documentation project?