This patch disallows the use of the # character in path aliases created by path.module.

Allowing this character in custom paths, while not explicitly disallowed by the relevant RFCs as far as I can tell, can cause ambiguity which is making it difficult to move forward on the issues #123103: Retain #anchors during path alias -> normal path saving and #325533: Allow <current>#fragment as a menu path, both of which aim to make it possible to create menu items with anchor fragments in Drupal's standard menu system. In other words, if someone enters a path of "foo#bar," are they referring to the path "foo#bar," or the "bar" anchor on the page at path "foo?" The latter is far more useful and likely, so let's disallow the former and remove the ambiguity.

The patch currently doesn't try to correct any current aliases with a # character in them. I'm not sure if that's a good idea, and if it is, how it should be done.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Garrett Albright’s picture

FileSize
7.14 KB

Hai de hee, hai de ho, where oh where did my patch go? I could have sworn I had attached it…

jpmckinney’s picture

Patch works as described.

I would change the error message to "The alias you have entered, %alias, is invalid. The alias cannot contain the # character."

Garrett Albright’s picture

FileSize
7.56 KB

I AM COMMITTING A PATCH FROM DCSF DURING DRIES' KEYNOTE I AM SO HARD CORE

I didn't use exactly your terminology, but I did add the path to the error message.

Georg’s picture

Seems to work.

I also created nodes with paths including # (before applying the patch). With the applied patch the nodes could still be accessed, but the next time you edit the node, you'll have to change the path to not have the # in it.

I think it's good. Just needs someone to look over the coding.

Garrett Albright’s picture

Georg, out of curiosity, why did you create paths with #? Just curious as to what "legit" reasons someone may have for doing so.

Georg’s picture

Ah, very good question. I wanted to try what happens, when this patch is applied. In real live I never did user # in paths and I don't think it a good idea to do so. But out of curiosity I had to try it anyway.
I normally don't have a "legit" reason to do so.

jcarrig’s picture

Garrett,

One reason I can think of creating a path including a # is for ajax content.

I have implemented sites with ajax content loads and deep-linking thru Asual's jQuery Address library. If you could include a # in the url alias then it would be the same as the deep-linking url.

Just a thought...

Garrett Albright’s picture

jcarrig, if this and #123103: Retain #anchors during path alias -> normal path saving can both make it in, then nothing will break in that regard. Either way, you weren't creating nodes with that path anyway.

RedTop’s picture

subscribe

JeremyFrench’s picture

I have a real issue where I would like to have a # in the menu path.

Even if it is slightly convoluted.

I have two content types with a node reference from container node -> child node. The container node has the full body of the child node in it and there can be many child nodes per parent.

The child nodes, can be tagged and treated as normal nodes in the system, but should only be viewed from the parent node. So when parent or child is saved it updates path to having something like Parent-nid#child-nid.

Another case would be if the preferred way to view a node was through a view.

normal_orphan’s picture

When I want to use jQuery UI Tabs (http://jqueryui.com/demos/tabs/) I have to use a relative link starting with '#'.

#bar1
#bar2

i cannot use

foo#bar1
foo#bar2

I can if course write it all from scratch in jQuery but then I cannot utilize the UI tabs code. Just sayin.

dynamicdan’s picture

Surely #social should be allowed in a menu? Jump the user down the page to the footer with social links/news? I don't see anything wrong with encouraging the use of relative hash links (or in page linking).