It is often desirable to create a menu item that links to a particular place on a page, e.g. /node/xx#name
In the menu system the # character is translated into %2523 and the link fails.
There is a hack, documented at http://drupal.org/node/106821, whereby you can specify a complete url to avoid this translation. This is an inelegant workaround and not a solution as it leads to management problems when the base url is not constant throughout the life of a site (e.g. when migrating between test/live sites or when it runs concurrently on two domains: xx.com, xx.co.uk).
I can't see any reason why the # character cannot be escaped. It doesn't pose any security threat and only users with admin privileges can define menu paths.
Comment | File | Size | Author |
---|---|---|---|
#60 | 123103-anchors-in-menu-items-2.patch | 2.4 KB | mgifford |
#49 | 123103-anchors-in-menu-items.patch | 2.4 KB | Garrett Albright |
#39 | anchors-in-paths.patch | 1.28 KB | Garrett Albright |
#1 | fragment.patch | 2.22 KB | JohnAlbin |
Comments
Comment #1
JohnAlbinNamed anchors are a standard part of the URL scheme. So not properly handling them in the menu system is a bug, IMO.
The attached patch allows admins to add custom menu items with relative URLs and anchor fragments.
(Also, I’ve updated the above handbook page to show a better workaround then having to enter full URLs.)
Comment #2
Steven CreditAttribution: Steven commentedTweaks like this will not work afaik, since normal menu paths can contain the # character.
If we want to change the menu system to support fragments and/or query strings, this needs to be added properly, without introducing forbidden characters in the menu paths.
This could mean that you enter menu paths in urlencoded form (i.e; what this patch tries to do) in the UI, but that would need to be integrated cleanly with the current unencoded, module-generated paths.
Comment #3
catchThe path_redirect module adds an extra field in for named anchors
_____________ # _____________
or similar. That makes the distinction pretty clear, not sure how it stores it though.
Comment #4
JohnAlbinFrom section 3.3 of RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax):
So the # and ? characters, according to the RFC, are already forbidden in the path. Right now, Drupal encodes all characters in the path (including the #), but I can’t think of any real-world examples of using an encoded # in the path of a URL.
Steven, the above patch doesn’t change the way Drupal handles url encoding. You would still enter URLs in unencoded form. It just splits the path at the first # and puts the parts back in $item->path and $item->fragment.
Comment #5
Steven CreditAttribution: Steven commentedI'm not talking about URL path components, but about Drupal menu paths. They are not the same.
Comment #6
Steven CreditAttribution: Steven commentedAs for a real world example... any search that includes a # in the keyword box.
Comment #7
Ryan Palmer CreditAttribution: Ryan Palmer commentedAny progress on this lately?? Was there a group consensus reached on a course of action??
Comment #8
seanrI've needed this for a very long time and am amazed it's still not possible. This is a pretty basic thing to want to do in a web site. The example I need it for right now is a political candidate's bio page with targets to each section (why I'm running, voice of the voters, etc.). I'd like to not have to break the bio up into three pages simply because the menu won;t let me use targets.
Comment #9
Hinrich CreditAttribution: Hinrich commentedAnchors are necessary. We using them to separate paragraphs in a long article. As I create my own theme, I do not have any problems to insert a simple
str_replace
, but the time I used for the search.I cannot imagine, why an url cannot have an anchor in the menu system. It is like an article without a title.
Comment #10
sumgai CreditAttribution: sumgai commentedIt's crazy not to support this.
I have lots of pages with a
<a name='top'></a>
at the top and a<a href='#top'>Top</a>
at the bottom.I can't do this in Drupal.
In v5.x, I hacked the url and menu_path_is_external functions so it worked, by just adding:
as the first line in each of the functions, but in 6.x, the changes to the menu system break that simple hack.
Comment #11
Anonymous (not verified) CreditAttribution: Anonymous commentedCan we revive this thread? There seems to be a consensus that enabling # and ? in the menu system does make sense (I just wanted to link to a Drupal page like "my/url?page=2", which is not allowed unless you specify the FQDN). Can some developer look at this, please?
Thanks,
Stephan
Comment #12
webernet CreditAttribution: webernet commentedI believe this is fixed in 6.x.
Comment #13
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #14
mikegulline CreditAttribution: mikegulline commentedi have 6 and i am having the same prob. i dont think its fixed yet. anyone figure this out yet?
mike
Comment #15
tancYeah, this seems kind of strange. What about the fairly usual case where a menu item should point to something with a url redirect after in the form of: ?destination=
At the moment in Drupal 5 (haven't tested 6) it wont work. In many other modules and situations we can specify a destination in the url, why not in a menu item?
Comment #16
Ryan Palmer CreditAttribution: Ryan Palmer commentedI don't think this was fixed in 6.
Relative paths using named anchor links in menu items do not work. The menu system won't accept them as a valid path.
Comment #17
pwolanin CreditAttribution: pwolanin commented@Ryan - if you really think this needs to be re-open, please more details of how you'd solve this. For example, we might think about a feature where a menu link could use <current> the same way it uses (at the moment) <front>
Comment #18
Ryan Palmer CreditAttribution: Ryan Palmer commentedI realize the menu navigation is attached at the hip with hook_menu and the page serving mechanisms of Drupal, and that the needs of this cannot be ignored when requesting an issue that seems to relate to only adding menu items to the tree, not defining paths in the first place. My question is, is it really practical for hash symbols to be used in paths, and should this character become a non-eligible character altogether for the purposes of Drupal?
Assuming we must have hashes in paths without them being links to anchors (ie, encoded), how about:
- another column in the menu_links table (fragment)
- another field for fragment in menu_edit_item form, or some means of denoting a fragment (eg. "node/123bottom")
This would let everything else (# symbols and the rest) be properly encoded, and fragments could be built into the links when the menus are build.
I may not have the insight to suggest such radical changes to Drupal core at this point, though.
Comment #19
pwolanin CreditAttribution: pwolanin commented@Ryan - for Drupal 6, anchors should already work for "normal" links. I thought the only issue to be addressed here was named anchors for the current page.
Comment #20
Ryan Palmer CreditAttribution: Ryan Palmer commentedTo my knowledge, with the exception of comment #17, this issue has been regarding menu items containing named anchors, WITH Drupal paths as well. Being able to leave the pre-anchor part of the path blank to have it always apply to the current page would be a bonus, IMHO.
Example: When adding a menu item with a path "buy#1", I get the following response:
The path 'buy' is either invalid or you do not have access to it.
Comment #21
pwolanin CreditAttribution: pwolanin commentedum, then I would expect you get the same error message inserting a link with the path "buy", right?
I can add a link to the path "node/4#hello" and it works fine.
Comment #22
Ryan Palmer CreditAttribution: Ryan Palmer commentedInteresting.
For me, "buy" was an alias to node/40. Normally, when entering an alias to a menu item path, it replaces it with the node/# equivalent and notifies the user of the change, but in this case it says the "buy#1" path is not valid.
The menu item accepted a path of node/40#1 and the menu item ends up being buy#1 which is great.
Does anyone know, is this by design? And if so, should something be added to the description of the menu path field specifying this feature/limitation?
Comment #23
pwolanin CreditAttribution: pwolanin commentedhmm, accepting aliases at all was added late, so this may indeeed be a bug - please investigate and refocus the issue.
Comment #24
troublehelix CreditAttribution: troublehelix commentedI can confirm I have what looks like the same issue as Ryan, where the named anchor will work only if referencing it via node name, but not the alias.
Comment #25
TheRec CreditAttribution: TheRec commentedI agree with pwolanin (#19 and #23), the only issue left 6.x is anchor for path aliases.
And while fixing this I also think there are some thought to put in path menu items consiting only of an anchor (starting with #) which should "point" to the current path. I don't think a "link" (working like ) is useful, it is possible to just check if the path starts with # and if it does just use the specified path as the link (as it would do with an external link), then for browsers the link would be a relative link to an anchor on the current page.
Comment #26
catchWhen you add a menu item for node/1#anchor - does the path get aliased when you view it in the menu?
Comment #27
TheRec CreditAttribution: TheRec commentedYes it does get aliased and the anchor is working. Then, maybe it needs to be documented, although I know that this "translation" would certainly occur it didn't come to my mind to do it this way. Thanks for the solution.
Seeing that I am not the only one who thought that using directly the alias with an anchor, and not the nid, maybe it would not be such a bad idea to offer both solution for anchors.
Lastly, that leaves us with the feature request, the "relative anchor" I talked about before, maybe we should create a feature request for this ?
Comment #28
catchOK, marking this back to active and bumping to 7.x. I can see two issues here here:
1. allowing a menu item with only a fragment, i.e. #anchor
2. When drupal_get_normal_path is called as part of the menu item validation, if the alias has an anchor appended, ignore this, then add it back to the normal path (so alias#anchor gets split to alias + #anchor which eventually gets saved as node/1#anchor).
I'm not sure how the first one should work - which use cases are there for having the same #anchor on every page a menu might show up on? #2 sounds like a decent usability improvement to me.
Comment #29
TheRec CreditAttribution: TheRec commentedAbout 1., an example would be "skip links" to improve accessibility. At the top of the page you offer links which point to named anchors like "#content" (if you have a named anchor or even an element with id called "content") and it will help people using a screenreader to skipping all the navigation links (for example). They will reach the content way more quickly. Of course this can be done directly in the page.tpl, but then you loose all the menu features. For example the ability to translate those. Well, it is possible to make this last part (transaltion) with the t() function and the interface translation system too.
If it is implemented, I doubt it would require much more efforts than it took to support external links... but with that kind of paths the "#" should not be encoded otherwise it will just not work of course.
Another problem we would run into is that the link_path field would be empty in the menu_links table since fragments (anchors) are stored in the options field, if I understood how it works, so after all the " <current>" placeholder wouldn't be such a bad idea. It could also be useful with querystring (which is stored in the same field, options) instead of anchor, the principle is the same for both (we would just need to respect the order, ?query=string#anchor (and not the opposite).
About 2., I would also see it as usability improvement more than a real "bug fix" (well, the feature is here, it just does not work as I expected, but it works), thus I changed the category. I think that your reasoning is right about how it should be done, it makes perfect sense since it basically how it works right now with not aliased paths (according to what I read this afternoon, so I might not have catched the whole picture but that's my understanding).
Comment #30
catchI left it as a bug, because usability issues are bugs ;) It either needs more documentation there, or the behaviour should be changed.
Comment #31
GBain22 CreditAttribution: GBain22 commentedHi Guys,
Just to echo a few points that people have already made, about why this is important.
In terms of accessibility, a "skip to content" link is extremely useful for blind users (using screen readers) as it gives them the ability to skip through all of your links and go straight to your main content. Here I would usually use
<a href="#maincontent">Skip to content</a>
but when this is published in a drupal menu the '#' becomes encoded as '%23' (don't quote me on that exact encode!)
The sooner this is sorted, the sooner I can stop worrying about hard coding in this skip links into my page.tpl.php file! I'm sure many of you feel the same.
Just thought I'd add a comment anyway!
Garry
Comment #32
pwolanin CreditAttribution: pwolanin commentedThis sounds like a new feature - we have a <front> special symbol now - maybe we need something like a <current> tag to make clear the intent?
Comment #33
catchAs far as I can see there's two issues:
1. If you save a normal path with a fragment, this is handled fine in the menu. When you enter a path alias, drupal_get_normal_path() doesn't validate it as an alias, so you can't save it. Since the end result would be the same, this seems like a UI inconsistency to me and it's clearly caused some confusion. (I haven't tested this, going on the reports above).
2. Being able to enter a fragment for the current path.
<current>
sounds like a reasonable way to do that. Although I can't think of a situation where you'd want to add anything other than a #fragment for the current path, so maybe just validation of the string might work?These seem like different issues to me, so I've split current path handling to a new issue #325533: Allow <current>#fragment as a menu path
Comment #34
TheRec CreditAttribution: TheRec commentedAbout 2., the only other occasion I see would be adding a querystring (as I said previously)... the use of it would also be limited but might still be useful, it can be handy to pass a parameter to the current page (i.e. like offering a link to the same page with a parameter telling the user does not have Javascript... indeed very limited, not that many other examples come to my mind right now ;)), but as I said it should not take that much more time to implement since it is done exactly the same way for #fragment and querystring (stored in options field in the menu_links table). The
<current>
would make it possible to handle both, as it is already done with<front>
.Comment #35
pwolanin CreditAttribution: pwolanin commented@catch - thanks for clarifying and splitting the 2 issues.
Comment #36
pwolanin CreditAttribution: pwolanin commentedFor those who really want to append an anchor, etc, in D6 to the current page, I suggest you'll need to implement/use a trivial module that implements hook_translated_menu_link_alter(). If I get bored I'll write it in the mini module section of the handbook.
Comment #37
sumgai CreditAttribution: sumgai commentedI would like to create a menu item (using the admin interface) in a menu, say secondary-links, with the "Menu Link Title" as "Top" and the "Path" as "#top".
It would generate
as the menu item. In this way, every page can have a "Top" link that works as expected.
But this is not possible today.
This seems to be linked to this whole discussion.
I've tried to raise this seemingly simple issue before, but have not gotten anything resembling a reasonable solution.
So, I thought I'd try posting this issue in this thread for you consideration.
Thanks,
Mitch
Comment #38
GBain22 CreditAttribution: GBain22 commentedHi Mitch,
I've been after this for a while - it's been moved to here http://drupal.org/node/325533 but the solution at the bottom of the page still doesn't work for me - kind of annoying as its really good for accessibility - hopefully it won't go unnoticed.
Garry.
Comment #39
Garrett Albright CreditAttribution: Garrett Albright commentedHere's a VERY LIGHTLY TESTED patch for D6 which fixes the alias#anchor problem mentioned in #20 and #21. As I mentioned, it's lightly tested, so do NOT put this on a live server, but please test it otherwise if you can.
It does not allow you to something like simply #top as a path - in fact, the result if you try that is rather odd - it links to the settings page for the current theme. (What the…?)
I'll try to look in to getting a D7 patch for this hacked together by tomorrow evening, if nobody else does it first. Again, please test this patch with D6 if you can so I can be sure I'm on the right track before attempting to submit a D7 patch.
Comment #40
domesticat CreditAttribution: domesticat commentedA quick test of the patch in #39 worked for me. Can't speak to the ramifications but it fixed the immediate problem.
Comment #41
Garrett Albright CreditAttribution: Garrett Albright commentedAck, I totally forgot I promised to work on this… Thanks for the bump.
Comment #43
Everett Zufelt CreditAttribution: Everett Zufelt commentedtagging
Comment #44
cburn CreditAttribution: cburn commentedI went about it the same way as #25 & #27 TheRec & #26 catch when getting a Menu item to work while including a hash #anchor tag in D6.15.
I have a parent Menu item, Computers, with two child Menu items, Classes & Lab. I wanted the page, Computers, to include Classes & Lab sections with anchors Classes & Lab. For the Menu item Classes, the alias was not accepted when entered into the Menu path like so--computers#Classes, but did work when the nid was entered like this--node/601#Classes. The nid with the hash tag was aliased and the anchor is working. Seems there needs to be documentation on this though.
Comment #45
catchPlease don't change versions, bugs are fixed in the development version first then backported.
Comment #46
AdrianB CreditAttribution: AdrianB commentedSubscribing.
Comment #47
mgiffordI'd like to see this feature. Might help address an issue where someone wanted to put in a "skip to main content" link in the primary menu too. Can't remember off hand what the issue ID for that was.
Comment #48
JohnAlbin@mgifford: #325533: Allow <current>#fragment as a menu path
Comment #49
Garrett Albright CreditAttribution: Garrett Albright commentedOver a month late, here's a D7 patch. It's pretty much equivalent to the D6 one. Seems to work.
Comment #50
Garrett Albright CreditAttribution: Garrett Albright commentedComment #52
Garrett Albright CreditAttribution: Garrett Albright commentedOkay, the tests where this is failing are basically creating a test path with "unusual" characters, including the # character, and then trying to access a page through that path. I'm not sure what to do about that - looking through relevant RFCs, it appears to not be incorrect to allow the # character in a legitimate path, so long as it's encoded. But it makes life tough for us in this case, because how do we distinguish between a # in a legit path and a # that denotes an anchor fragment?
We may not be able to solve this and #325533: Allow <current>#fragment as a menu path unless we stop allowing # in created paths. I may create an issue about that later after a bit more consideration.
Comment #53
Garrett Albright CreditAttribution: Garrett Albright commentedOkay, well, to thoroughly confuse the matter, I'm getting these same test results locally if I use a virgin core CVS pull with a virgin database. Can anyone else replicate this, or is it just me?
Comment #54
Garrett Albright CreditAttribution: Garrett Albright commentedI'm so confused. It seems to me like that if this patch were to cause tests to fail, those failing tests are likely ones to fail. Oh the other hand, I can no longer get those tests to not fail using a completely unpatched HEAD no matter what server and configuration I try it with. On the other other hand, other patches seem to be running past the testbots on the testing servers without these tests failing.
I can't believe I've wasted so much time on this. Giving this up until at least tomorrow or until someone smarter than me can step in and figure out what the hell is going on.
(Side note:
cvs co -C
should check out HEAD while overwriting all of your core hacks, right? Not that it matters in this case - I still get this problem if I baleet my repository and do a completely fresh checkout or even install the -dev tarball.)Comment #55
Garrett Albright CreditAttribution: Garrett Albright commented#759808: Disallow # character in path aliases will help us move forward on this.
Comment #56
RedTop CreditAttribution: RedTop commentedVERY interested in this. Therefore... subscribing. :)
Comment #57
kangaroobin CreditAttribution: kangaroobin commentedSubscribing
Comment #58
chris_gooley CreditAttribution: chris_gooley commentedsubscribing
Comment #59
mgiffordOk, have to look at patch in #49. Is it just a matter of changing path.test so that the tests
Changed alias works. & HTTP response expected 200, actual 404 using PathTestCase->testAdminAlias()
Comment #60
mgiffordtrying to keep up with core
Comment #62
killua99 CreditAttribution: killua99 commented#39: anchors-in-paths.patch queued for re-testing.
Comment #63
mgiffordOk, so this is the two places where this patch fails in modules/path/path.test
I'm tempted to just nix the # from the testing string, but I do wonder what happens when someone puts in a # into the title of their node. We should test for this use case, right?
Comment #64
mgiffordAdding simpletest tag. This again is waiting for fixes to the test.
Comment #65
normal_orphan CreditAttribution: normal_orphan commentedSubscribing
Comment #66
mgifford#60: 123103-anchors-in-menu-items-2.patch queued for re-testing.
Comment #68
Everett Zufelt CreditAttribution: Everett Zufelt commentedBumping to D8 and removing the accessibility tag. I don't really see where this would be any more useful from an accessibility perspective than it would be in general. Putting skip links in the page.tpl.php file is pretty standard, I don't really see any advantage at all of running these through the menu system, perhaps someone can correct me if I am wrong.
Comment #69
AdrianB CreditAttribution: AdrianB commentedPossible stupid question: Would it be possible to fix this in contrib for D6/D7 or is this something that needs to be done in core?
Comment #70
Imaaxa-Cory CreditAttribution: Imaaxa-Cory commentedI just noticed if I do an address like
node/16#gohere
the auto url will change it to be like
about-us#gohere
This is in D7.
Comment #71
StephanieFuda CreditAttribution: StephanieFuda commentedSubscribing
Comment #72
Daas CreditAttribution: Daas commentedI am struggling for more than 4 weeks with this problem, nobody is answering my question and I can not find any solution on this site nor the internet. I tried some many patches but non of them is working. Why does the url alias return a %23 instead of a #. I would like to go, from my search results, to an id (anchor) in long panel pages with lists of products. It is essential for my customers that they see the product they searched for but also the related products on that panel page. Does anyone has the final solution, if I need modules to do this please give me a hint.
Comment #73
jason@greengeckodesign.com CreditAttribution: jason@greengeckodesign.com commentedJust a quick note to hopefully save someone else the frustration I just went through. If you are creating a menu item which links to a named anchor in d7 it works if you set the path to node/nodenumber instead of the alias.
For example if you try to set the path to
about-us#gohere
and try to submit the form it will say "The path 'about-us' is either invalid or you do not have access to it.", whereas setting the path tonode/2#gohere
works fine.Comment #74
snlnz CreditAttribution: snlnz commentedI recently had to built a site for a client that required anchor links on the main menu as the whole site was on a single page.
Admittadely to organise the code better I externally linked each page, even though essentially they were all on the one node it was easier to maintain include files.
I simply added menu links with the path:
I didn't read the post but thought I'd share my experience anyway! :P
Comment #75
gynekolog CreditAttribution: gynekolog commentedBut what can i do, when # is replaced with %23
Comment #76
dmkelner CreditAttribution: dmkelner commentedHas there been any further updates on this issue for Drupal 7? I want to be able to use the alias and not the node number when linking to an anchor. Sorry for the version change - unintentional quick mouse.
Comment #77
dmkelner CreditAttribution: dmkelner commentedChanged back to 8-x-dev
Comment #78
kilrizzy CreditAttribution: kilrizzy commentedNot sure if anyone would be interested in a 'fix' using jquery but this might work also (I have all 3 linking to the same "policy" page)
Comment #79
snlnz CreditAttribution: snlnz commented@gynekolog I can only imagine that you would enable pathauto and automatic alias the node so you don't get %23.
:)
Comment #80
netsensei CreditAttribution: netsensei commentedHm. I'm going to expand on this one. I've noticed something illogical. Take a look at these 5 url's. Try to add them as a menu item. Asssume that 'test' is an URL alias for node/1
1. node/1: Works
2. test: Works. But it will convert the URL alias to an internal path
3. node/1#test Works. Oddly enough.
4. test#test Fails with a cryptic "The path 'test' is either invalid or you do not have access to it."
5. http://google.com. Works. Because this is an external URL.
The last case is peculiar as test is a valid, existing URL alias. So why is it failing?
Take a look at MenuLinkFormController->validate().
First the validation goes through
$normal_path = drupal_container()->get('path.alias_manager.cached')->getSystemPath($menu_link->link_path);
to get the normal (internal) path of the item, assuming that this is an URL alias (of course). Since test#test is considered as a whole rather then as an URL alias with a fragment, it will fail and assume that test#test is an internal path in itself and the conversion code will just return what it was fed: test#test. Then it will check if the URL is external. Of course, it isn't. Finally it arrives here:drupal_valid_path() will fail since test#test is an anchored URL alias while the system, at this point, assumes it's just another internal path. This is where the validation fails to recognize a use case. It works perfectly for paths which aren't URL aliasses or recognized as internal paths. But it doesn't take fragments into account.
It's either a problem with the validation here or rather an issue lower down the chain. Probably when the getSystemPath() method is called.
Anyhow, I stumbled into this today while working on a D7 project which deals with a lot of anchored links structured in a menu. Since anchored internal paths *do* get saved but not anchored URL aliasses, this constitutes as bad UX towards end users imho: the only way to grasp this limitation is knowing what the difference is between an alias and an internal path.
Comment #81
wikki boy 03 CreditAttribution: wikki boy 03 commentedFor D7, I used a simple solution to this. In my page.tpl.php simply put urldecode around my menu print statement.
<?php print urldecode(theme('links', array('links' => menu_navigation_links('main-menu'), 'attributes' => array('class'=> array('option-set', 'clearfix')) )));?>
Comment #86
stephen Piscura CreditAttribution: stephen Piscura commentedUntil i upgraded from Drupal 8.2.3 to 8.3.7, i had been saving anchors in my path alias. Now, all aliases with included anchors are being rewritten with "%23" (e.g. example.com/about#mission to example.com/about%23mission). This is actually breaking quite a bit of functionally. Does anyone know of a workaround, which would allow the anchors to remain in the path?
Comment #87
stephen Piscura CreditAttribution: stephen Piscura commentedJust gotta hack core, ya know?
drupal8 > core > lib > Drupal > Core > Routing > UrlGenerator.php
These two things:
and also change:
$path = str_replace($this->decodedChars[0], $this->decodedChars[1], rawurlencode($path));
to:
$path = str_replace(array($this->decodedChars[0], $this->decodedChars[2]), array($this->decodedChars[1], $this->decodedChars[3]), rawurlencode($path));
Comment #91
AnybodyThis is possible in Drupal 8.x and 9.x now. I just tried the following in the menu system:
#top
/node#top
For menu.yml you can use
Comment #92
AnybodyAs of #91 I'll close this for 8.9.x and following now. I can't say when this has been fixed, but it works.
I also added this to the documentation for .menu.yml: https://www.drupal.org/docs/drupal-apis/menu-api/providing-module-define...
Also see:
https://drupal.stackexchange.com/questions/229376/non-clickable-menu-ite...
and https://drupal.stackexchange.com/questions/280665/how-to-add-a-nolink-me...