More flexible menu items

Earnie mistakenly snapped the wrong link up above. It's http://drupal.org/project/pathauto.
______
Senpai

I realIy appreciate your help here, but I don't think that solves the problem. The trouble is in the menu item code. No matter what you type as the URL in menu items, the core system replaces it with a hard-coded node/x. No matter how convenient you make the process of allocating nice names to nodes, the menu item will not have the name in there, even if you enter a name when you make the menu item. It will have a node number, and changing names around will just make the menu show the wrong name, it will not make it redirect to the new location of the same name. The point is, yes, I can change my own hard-coded links in page content to names (in fact I never put hard-coded links in my content in the first place) but I can't stop the core replacing my names in menu items with hard-coded links. It does do this and it is IMHO clearly an incorrect usability decision.

I think this is not a problem of making allocation of node names convenient. Unless the pathauto module goes through the database looking for node/x - type entries that referred to an old page for a name and replaces them with node/y where y is the new node for the same name (which I very much doubt it does), I cannot see how it solves the problem at all. And even if it did, surely expecting a third-party extension to correct a core problem is ignoring the usability issue?

Thanks again for your help!
Ron.

Thanks Eigentor, but no it's NOT about what I put into my content. To say it again, it is specifically and ONLY about making menu items with the core menu system. Go to any menu and click "add item". Now in the path field, type, say "contents" (assuming you have a page called contents). Click Save. Now click Edit next to the freshly created item. The path field will not show "contents", it will show something like "node/351". That is replacing logical information with physical information, and that is a bad design decision. No talk about how I name my nodes will fix that flaw. If I have links to "contents" in every menu and I replace my contents page with another under a different node number, I have to locate every menu item that referred to the old contents page and make it point to the new one.

In any context I can think of, this is a bad design decision, your comments about node names changing when the title changes notwithstanding, because that presumes I use some system of automatically assigning node names. I need not do so. I can assign them manually when and only when I want a fixed symbolic reference to a conceptual page as opposed to a physical page. Think of a corresponding situation in programming: I name a constant symbolically, but when I compile my program the compiler runs an editing job on my source code replacing the name with the actual integer value. Would anyone seriously argue that such a thing is other than intolerable? How is this any different?

If the menu code did not do this, I could use a physical reference like node/351 when I want to refer to a specific node, and I could use a logical reference like "contents" when I want to refer to a conceptual target. I cannot make sense of your final two paragraphs. The first talks about unchangeable references. So? Use node/xxx. I don't. When I write a URL, I expect that it should point to the page I want to have that name, not to a page that used to have that name in antiquity. You have node/xxx to do what you want, I want symbolic names to do what I want. Seems fair. Then you say someone making a second about page can't expect links to remain intact. Why on earth not?? If they were left as they were written instead of being forcibly tinkered with, they would ALL remain intact, just as the links in my main content all continue to work because I use symbolic names when appropriate.

Cheers,
Ron.