Zen,

was thinking about your question from last month on how we might enhance the related links module. Here's some thoughts:

1) Being able to choose the target for the URL i.e. _blank, parent etc.
2) Ability to pull an image from the related link and display it with the title (Facebook and Linked in do this sort of thing)

Let me know what else you've been thinking about for the module's future :-)

-Joe

Comments

dman’s picture

Feature idea: (pure blue-sky thought from me today)
Use the CCK link field in D7 for data storage, instead of a hand-rolled database table?

Yeah it would be significant refactoring I guess, but would open up the theming and views and things in a really standard way. Maybe.
Could be awesomesauce if it could blend with nodereference also ... but right now even getting a hybrid between nodereference and link fields isn't quite all there AFAIK.

I've so far, as normal, constructed related links support out of CCK rather than this module as - although I love (and have used) the auto-parser, the data isn't really stored in the right place for me, and I'd rather layer an auto-parser onto nodereference than patch this module.
So ... convergence would be a nice thing in the future, if at all possible.

Zen’s picture

Thank you for your thoughts. My own immediate goals are:

  1. Making the parsed links feature a filter rather than a node body field processor.
  2. Using the Link module for manual links.
  3. Supporting Views.
  4. Improving the parser to support image links better.
  5. Improving discovered links as IMO, that is this module's best feature.
  6. Adding simpletest support.

I have set aside time in the next few weeks to work on this. If either of you (or any of the lurkers out there) have some time and energy to expend on this module, that'll be great!

Cheers,
-K
Edit: Added simpletest to the wishlist :)

dman’s picture

If you use CCK link field, then views (and full theme) support is free.

Zen’s picture

Are you suggesting that the Link module should be used for *all* link types and not just manual links? If not, then parsed and discovered links will need to be handled too.

-K

dman’s picture

Yeah, that's how I would model it - if continuing to emulate the current architecture.
Seeing as right now it creates individual database records for each link - however it was detected, extracted, added or parsed, I think it may as well use the same, consistent storage mechanism.