Not grokking what it does

Hmmmmm.... In addition to asking a pretty decent new-user question, you've also come up with what might be a nice added feature. I'll take a stab at your question as the module's creator, but I invite others who've used Links to jump in here and add their own comments as well.

Links, as you've noticed, begins with a fairly comprehensive API for managing links. The API's main objective is to rationalize links, that is, to ensure that each link URL is only stored once no matter how many times it's referenced from around the site.

The add-on modules for the Links Package include:

• links.module -- controls overall behavior of Links
• links_related.module -- allows you to add zero, one, or multiple "related links" to any node. How many related links (if any) are allowed can be configured by the site administrator per-node-type.
• links_weblink.module -- defines a node type whose specific purpose is to represent a given link in a catalog of links.

The difference between links_related and links_weblink is that the former allows nodes to *have* links, while the latter creates a node that *is a* link. It is actually allowed, though possibly confusing to the user, to enable related links for the weblink node type, so that link nodes can have related links.

Node URLs are heavily "normalized" before being stored in the database, to remove extraneous GET parameters such as PHPSESSID as well as any empty parameters, then to ensure the remaining parameters are sorted. The idea is that http://foo.example.com/mypage.php?parm=Y&parm2=&parm3=blahblah&PHPSESSID... is really the same URL as http://foo.example.com/mypage.php?parm=Y&parm3=blahblah and should be cataloged as such. Session parameters should almost never be cataloged in a database, and Links tries very hard not to do that.

An additional feature of links_related.module is that it can extract embedded links from within the node content and display them in an endnotes list for convenience of users, and/or on a separate "links" tab when viewing the node. A new feature just added by a contributor allows the site administrator to actually convert these extracted embedded links into regular "related links" in the database.

Except for this last item, just about everything in Links focuses on adding new content, or adding new features to existing content. We don't yet have a way to go through all nodes on the site to extract existing links. This is the part of your question that I think suggests an interesting new feature. The actual coding would be fairly simple, but the question is, how much cruft would go into the database if it were run on a large site? I need to do some thinking about this, but you have a very interesting notion here.

We also plan to add a broad-spectrum "links management" feature to the package, which will (among other things) automatically scan for dead links and moved links, providing a convenient administrative interface so the site editor(s) can react to the changes centrally, without having to visit the individual nodes affected by the change.

I hope this helps to introduce Links. Please feel free to continue this discussion if needed.

Kind regards,
Syscrusher

Very good and interesting answer...

However, I had the same question and could only answer it by looking at the code:

The links_weblink module enables a web links directory by taxonomy term at links/weblink (eg. yoursite.com/{drupal}/links/weblink).

This link catalog is mentioned in the settings screen, but there is no mention of how to access it in the README file or the config screen.

Cheers.

Someone has written a link checking module, but it's not hosted on drupal:

http://drupal.org/node/72840#comment-260574

I've suggested that the developer (Marek) contact the team.

And as this seems to be a general discussion thread, here are some ideas that I wrote down for a summer of code idea in 2006, but which never made it to a project, partly because the other ideas I susggested were, unbeknownst to me, already implemented in links:

* When deleting nodes, alert the user to links to a node, before deleting that node.
*If a node is deleted, remove (or perhaps disable) the links to that node from other nodes
* Provide a nice interface (perhaps by analogy with "image assistant", called "link assistant") for making links. The link button in TinyMCE or FCKeditor would bring up a window that has a listing of all the node titles on the site. The node listings might be organised by taxonomy, or perhaps they could be searched for. A small preview window could be provided. An "insert link" button would insert a link to the selected node into the node being editted. I imagine AJAX could be used to good effect in the interface.

Same here. I'm still searching, though!