Merge Links Package with CCK Link field

On my sites I've defined a 'Website' node type and using CCK added a Link field. The field is enabled to have multiple values and this lets me enter lots of links. I also reuse the same field definition on other node types, allowing every node to have lots of links from it. This seems similar to the 'Links Related' module but more general. Except it lacks the 'Weight' aspect to 'Links Related'.

The weight attribute is important to me because I run a large web site with nodes that have one or more related links, in which one of the links is considered the "primary" link and needs to be at the top of the list. As is so often the case in Open Source — and with good reason — I scratched my own itch and then shared the code with others. :-)

The main thing I'm lacking is centralized management of the links scattered among the many nodes. Obviously links go dead from time to time and it would be great to have a module which regularly checks links to see if they're still alive.

This feature is definitely in my plans for the Links package. Originally someone had volunteered to contribute this code, but that never happened. I've got some code that I wrote for a non-Drupal open source project several years ago that I plan to port to the Drupal environment. It already has the features to do the heavy lifting of link validation, but lacks the UI for the Drupal administrator to control the process and respond to the detected problems. This past 18 months I undertook a very large volunteer position (not software related) for a nonprofit organization, and didn't have much time at all for Drupal coding. That position ended about a month ago, and as you can see I'm back at work in Drupal. I hope this coming few months shows better progress in Links than the past year did.

To get to a concrete request:-
a) Rather than a 'weblink' module to support the content type, why not require CCK and define a content type that way?
b) Rather than 'links related' module, why not require CCK and define an appropriate field?
c) Support incorporating links from CCK Link fields into the database

We are thinking along very much the same lines. When I created Links originally, it was built as an enhancement to Ber Kessels' excellent Weblink module, and Ber contributed to the original code base and then deprecated his own module in favor of Links. At that time, CCK was either not yet in existence or was at a very early stage (I forget which), and so I didn't have the option of going to that approach.

There has been some early work contributed by another developer for CCK to support the Links API, but it's not quite cooked yet, to the best of my knowledge. There are certain parts of the CCK code that seem (at least, last time I looked at it) to want to insist that the CCK fields go into a table within CCK's own schema. That may have changed, and I need to re-investigate this now that I have some time to actually work on it.

On the other hand, the Links Package has some features for display of links in the title area, in a block, and in a node page tab, that as far as I know don't exist in CCK. So at least for now, I view CCK/Links integration as an option I want to provide to the community, not a replacement for links_related and links_weblink as they now exist. I am open minded about this, though, and it might be possible to convince me otherwise if CCK can actually do the other things. I'll admit that while I'm familiar with CCK I'm not an expert on it.

My intention in the coming months is to work on the following tasks:

1. Provide a CCK field type that is a related link but stores its URL in the Links API instead of locally to CCK. At least in the first version, this would be an alternative to links_related rather than a replacement. But I would provide a migration script in case people who used links_related wanted to migrate to CCK.
2. Figure out how to do a "weblink" node type in CCK such that it has one link that stands out from the others. This may be accomplished by making a links_cck module that not only can add a "links field" to CCK, but which can add an arbitrary number of "links field types" to CCK under admin control. In other words, perhaps I just need to abstract up one more level in the conceptual design.
3. Find out what Drupal Core in D6 and D7 are doing with regard to dynamic creation of node types. There was at one time a discussion of integrating CCK into Drupal Core, but if I recall there was also a competitive solution favored by some of the core developers. Before I commit too heavily to CCK, I want to know what Drupal core is doing in D7.
4. Implement the links checking algorithm and links management UI, the pieces that are still missing from the current Links implementation.

Thanks for your comments. I welcome further discussion of these issues by any interested developers or users of Links.

—Syscrusher

How does this stand now on D7?
The old Weblinks module is currently unusable (and redundant?) in its early 7.x-dev version.
What about merging that one with this, and with the links field module?
See: http://drupal.org/node/971418