[development] links best practices (was Re: internal link filter ...)

[Ray Zimmerman]

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