On Jul 13, 2006, at 8:22 AM, Syscrusher wrote:
As the maintainer of the Links package, I'd be happy to work with you to get this functionality integrated into Links. Please take a look at what we have so far, in contributions/modules/links (CVS HEAD branch), and let me know if and how you think your feature could integrate in.
Thanks, Scott. I'll warn you up front that this e-mail widens the scope beyond the initial discussion, which was limited to a simple input filter that could properly handle the base_url issues for internal references in content. I'm interested in moving toward a consistent best-practices approach to handling all of my links in drupal, including the internal links, and I believe having all of them handled by the Links API [1] seems like the way to go. However, for me there are several missing pieces, some probably at the API level and others at a higher level. Here is a summary of what I think is needed: (1) link API handling of internal references as well as external URLs [2] (2) from within content (body or other filtered text field), ability to (a) reference existing link entries, and (b) create new link entries [3] (3) link field for CCK [4], [5] More details: (1) I assume there are two types of entries that can be given for the URL, a fully qualified URL like http://www.google.com/ (which I believe works just fine) and an internal reference (e.g. node/99, admin/views, or some url alias defined in admin/path). I don't believe the latter currently works (see [2]). To be clear I'm suggesting that the Links API should treat URLs without the http:// as internal references that need to be prepended with the appropriate base_url. This may require another field in the database to indicate whether a link is internal or external. Another minor detail is that we should make sure the two types of links can always be themed differently. (2) Currently the weblink.module includes a [weblink:*] filter that handles (a) for external links. I believe that filter functionality should be split out from the weblink module so that it can be used for any links handled by the Links API [6] independently of the weblink node type. For (b) I envision a filter syntax something like [newlink:http://www.google.com/] [newlink:http://www.google.com/|Google] [newlink:node/33] [newlink:node/33|Best Practices for Links] that creates a corresponding related link entry upon saving the node *and* replaces the [newlink:*] with the corresponding [weblink:node_id/link_id]. It would also be nice to have an option to do the same with raw HTML links in the content, though I'd probably prefer to use the explicit filter syntax. With the raw HTML option, it would be useful to have some some sort of linkharvester.module as suggested by Bèr in #7 of [3] that scans for links in pre-existing content (assuming that's what he was referring to). (3) CCK's existing weburl field does not utilize the Links API. I know you can attach related links to CCK node types, but you can't specify the names of the fields, whether/how many are required, etc. I think I may be able to rustle up some funds to help sponsor these missing features (or better alternatives you and others may suggest), but I should probably let you know that I'm an experienced Perl programmer (/me ducks ;-) with minimal PHP experience and more importantly, very little time to dedicate to learning what I need to implement this stuff myself. - Ray References: [1] http://drupal.org/node/24719 [2] http://drupal.org/node/72459 [3] http://drupal.org/node/3776 [4] http://drupal.org/node/55208 [5] http://drupal.org/node/55210 [6] http://drupal.org/node/72454