blogroll not functional for internal links

[thomask]

if you try to add e.g.

#menu

as a link address, or some internal page, it saves it as http:/#menu (add http:/ - http with one dash)

Can you try this with the latest SVN? I believe it was fixed.

Never mind. It doesn't try to see if there's a # at the beginning.

Which brings me to the next question. Why would you want to put a page-specific, internal link into the blogroll?

Replying to rob1n:

Which brings me to the next question. Why would you want to put a page-specific, internal link into the blogroll?

Well, #anchor does not mean page specific. The anchor could be in a header or footer. Seems like a very edge case.

Quick question: Why is the blogroll trying to verify the links at all? I would prefer it to not try to check http: or ftp: or mailto: or anything else. Is there any easy way to disable this functionality, to let people put anything that they like in there? Maybe they want to make links to other edge cases, like itms: links or something...

Replying to Otto42:

I would prefer it to not try to check http: or ftp: or mailto: or anything else.

+1

Replying to foolswisdom:

Replying to Otto42:

I would prefer it to not try to check http: or ftp: or mailto: or anything else.

+1

Changed my mind already. Should validate, but should support other protocols. People are most likely to expect ​http:// and only enter www.example.com .

Note for anybody else who wants to know:

The fix for this is in bookmark-template.php. Remove this code from the _walk_bookmarks() function:

if ( !empty($bookmark->link_url) )
	$the_link = clean_url($bookmark->link_url);

And all your Bookmark URLs will then go unmolested.

Replace clean_url in _walk_bookmarks with a default filter.

Attached a patch that will replace the clean_url call in _walk_bookmarks with a filter. Also added a default filter to hook that to clean_url. By itself, this patch changes nothing. However, it allows plugins to disable it entirely (my preference) or to just modify that filter and thus replace the $protocols parameter of the call to clean_url. Thus a plugin can add allowed protocols and such as well as simply disabling it. Allows for both choices.

Or change clean_url to accept anchors (#whatever). It's a valid URL, after all.

refreshed against 10289

Changed clean_url to accept anchors when it is the first character (which is should be). Added a note in the edit form to show an anchor is acceptable. This could be used in combination with the above patch.

This seems weird:

<code>&#35anchor</code>

I agree it doesn't look great, not sure what the best alternative is. Felt like something needed to be added there otherwise it wouldn't make much sense.

oh, I was meaning, isn't it missing a ; at the end of the entity?

Duh, of course.

Replying to rob1n:

Or change clean_url to accept anchors (#whatever). It's a valid URL, after all.

clean_url not really cares about valid urls, clean_urls define which URLs are valid for the function.

Replying to scohoust:

Changed clean_url to accept anchors when it is the first character (which is should be). Added a note in the edit form to show an anchor is acceptable. This could be used in combination with the above patch.

Not in 2.8 Trunk. clean_url() does not check for # aka anchors there.

clean_url() acccepts # against 2.8 trunk

+1 to commit either of the last two patches.

(In [11126]) Don't prepend http to fragments. Props scohoust. fixes #4051