On 7/7/06, Dave Cohen <drupal@dave-cohen.com> wrote:

Ray,

I think this is a good idea and an input filter is the way to do it. I had a similar thought, but never did anything about it. I'd be interested to use your filter when its done.

My idea was to filter "#99" to be "node/99" at the current site. And "drupal.org#99" would become "http://www.drupal.org/node/99".

-Dave

On Friday 07 July 2006 06:21, Ray Zimmerman wrote:

...

I'm considering writing a simple input filter module to handle internal links [1]. It would take paths like node/99 and prefix them with the appropriate base_path. I have two questions:

You can also use the freelinking.module to link content by it's title, ie., [[this is another node]]. http://drupal.org/project/freelinking -- e www.eafarris.com

On Sunday 09 July 2006 05:44, Bèr Kessels wrote:

Maybe it is a good idea to collaborate with the "links bundle" team?

They have all sorts of modules and apis to handle links. The best about them, is that these modules are consistent and coöperative. Adding a module to that for inline links sounds like a very good plan, to me.

Thanks for the plug, Ber! 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. I'm willing to entertain the idea of a separate module that's part of the Links package, or added functions in the Links API, or some combination of the above. Kind regards, Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/

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

On Jul 13, 2006, at 1:20 PM, Syscrusher wrote:

On Thursday 13 July 2006 12:59, Ray Zimmerman wrote:

...

(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.

I'll respond separately to the rest of the post (excellent discussion, btw), but wanted to treat this separately.

I've already ported the weblink filter into the base functionality of the new Links Package. It works fairly similarly to what you describe. Check the README, online help documentation, and source code comments for details.

Oops ... I see I was careless (and incorrect) with my references to the weblink module. I was actually referring to the links_weblink.module that is part of the new Links Package. I actually never used the old weblinks.module at all. So my suggestion still stands, to move the filtering functionality out of the links_weblink.module so that it can be used without enabling the weblink node type. Sorry for the confusion, Ray

An update ... On Jul 13, 2006, at 12:59 PM, Ray Zimmerman wrote:

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.

For this simple case (no Links API integration), I whipped together a filter that you can download from ... http://www.pserc.cornell.edu/temp/ilink_filter.module It replaces [ipath] and [ilink] tokens as follows, for a site whose base_url is "http://example.com/drupal": [ipath:node/99] --> http://example.com/drupal/node/99 [ilink:node/99] --> <a href="http://example.com/base_url/node/ 99">http://example.com/drupal/node/99</a> [ilink:node/99:My Text] --> <a href="http://example.com/drupal/node/ 99">My Text</a> If the drupal path has an alias, the alias is used instead of the original path. Comments are welcome, and I'll be happy to apply for CVS access and create a project for it, if others would find it useful.

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]

Check. I realize now this was not a missing feature. There was a simple bug, now fixed, that prevented it from working 100% for me. Ray

On Jul 29, 2006, at 11:20 AM, Konstantin Käfer wrote:

Just a quick thought: what about using drupal://node/64 or internal://admin/settings style URLs?

Personally, I find that kind of URLs rather pleasing and easy to remember: <a href="internal://node/54">Get there!</a>

I like this idea. Is there any standard or convention for choosing the label we use for such a URL? Another thing, related to the Links API ... this would allow it to distinguish between an internal drupal path and an actual relative URL. As is, anything without an http:// (or ftp:// or mailto: , etc.) is considered a drupal path, so there is no way to use an actual relative URL. Syscrusher, what do you think? If we can agree on the label to use, I'll create an input filter that runs these through url(). I might even be able to come up with a patch for the Links package of Syscrusher likes the idea. Ray

I like this idea better than my urlaliasfilter.module, so maybe we could use this module instead of the one I have there (which just replaces any link to "node/5" or "admin/settings" with it's appropriate alias). Ray, let me know when you get a CVS account and if you'd like to post a patch/combine efforts to urlaliasfilter. IMO internal://node/5 is better so if someone wants to create a white label installation for a client who doesn't want anything labeled "Drupal"-specific. Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Ray Zimmerman wrote:

On Jul 29, 2006, at 11:20 AM, Konstantin Käfer wrote:

...

Just a quick thought: what about using drupal://node/64 or internal://admin/settings style URLs?

Ok, I created a filter that converts drupal://... style URLs using url(). While waiting for my CVS account you can grab it from ...

http://www.pserc.cornell.edu/temp/drupal_path_filter.module

Any suggested improvements? Morbus? ;-)

It doesn't currently split out the query string or fragment portion before passing to url(), and I'm sure the regex could probably be improved, but it seems to work for the simple things I've tried so far, so I thought I'd throw it up here for any feedback.

Ray

I renamed my module to pathfilter and just ported all your code over. http://drupal.org/project/pathfilter Thanks! Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Ray Zimmerman wrote:

On Aug 2, 2006, at 1:56 PM, Rob Barreca wrote:

...

I like this idea better than my urlaliasfilter.module, so maybe we could use this module instead of the one I have there (which just replaces any link to "node/5" or "admin/settings" with it's appropriate alias).

Ray, let me know when you get a CVS account and if you'd like to post a patch/combine efforts to urlaliasfilter.

I agree that we don't really need both modules. However, the reason I created it actually has nothing to do with URL aliasing, that was just a free bonus, so I'd prefer to use a name like "Drupal Path Filter" or "Internal Link Filter" or something. What I really needed was a way to enter internal links in content in a way that doesn't break when you move the site to a different path.

Other than that, I'm not really attached to being the owner of it. Would it make sense to set up a new project for my module and then put a note on the project page for URL Alias Filter saying that it's no longer supported and has been superceded by ... ?

...

IMO internal://node/5 is better so if someone wants to create a white label installation for a client who doesn't want anything labeled "Drupal"-specific.

I have no strong preference, but I had to pick one. Switching it to internal:// is obviously a trivial change. Any other opinions on this?

Ray

On 8/2/06, Ray Zimmerman <rz10@cornell.edu> wrote:

On Aug 2, 2006, at 2:46 PM, Rob Barreca wrote:

...

I renamed my module to pathfilter and just ported all your code over.

http://drupal.org/project/pathfilter

OK, I suppose this is fine ... I was kinda waiting a bit for some other opinions before jumping, but that's fine.

I prefer the idea of internal:// over Drupal. Much as I like Drupal, there is a clear desire to make Drupal easy to repackage. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses

Op donderdag 3 augustus 2006 04:12, schreef Syscrusher:

I prefer the idea of internal:// over Drupal.

+1 from me also, for reasons others have already stated well.

In fact, I have a feeling that we should put an effort behind foo:// patterns as defacto standard for Drupal over [foo:] patterns. I will see how easy it is to get this into inline module, to start with. inline:// is a lot better IMO then [inline:]... -- [ Bèr Kessels | Drupal services www.webschuur.com ] Layoutkeuze, de stap voordat je gaat (laten) ontwerpen.: http://help.sympal.nl/layoutkeuze_de_stap_voordat_je_gaat_laten_ontwerpen

I agree with Morbus on this .... (mark the day ...) For this very reason:

Doing so, even internally, is a creation of what appears to be a new protocol, even though it's actually not.

A new "file" format is more acceptable ...

Can you elaborate? What do you mean by a new "file" format? Sorry for my ignorance about URNs.

Heading to bed, but http://en.wikipedia.org/wiki/Uniform_Resource_Name -- Morbus Iff ( dare you overpower my stench of eeeevil? ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Hi there, On 8/5/06, Morbus Iff <morbus@disobey.com> wrote:

[...] Actually, for what it's worth, we should NOT use internal:// or *any* foo:// patterns. Doing so, even internally, is a creation of what appears to be a new protocol, even though it's actually not. We should instead create a new URN, such as internal:node/4. Apple, in the past two years or so, I think, got flamed for using webcal:// for it's iCal application, where webcal was merely a file format, and not a protocol.

I agree. I would propose to use some wiki convention, like wikipedia's [[node label | internal:node/1]]. By the way, although I am listening since some time, this is the first message I post. I am using Drupal for a web site about a conference (http://www.pi.infn.it/congressi/tau06/). I did some php coding for it, a theme and something that could become a conference module. In that web site I use the wiki module, where one can use [label | http:?q=node] for internal links. This would break if Drupal changes the ?q= notation. Greetings, -- Alberto

On Saturday 05 August 2006 00:45, Alberto Lusiani wrote:

Hi there,

On 8/5/06, Morbus Iff <morbus@disobey.com> wrote:

...

[...] Actually, for what it's worth, we should NOT use internal:// or *any* foo:// patterns. Doing so, even internally, is a creation of what appears to be a new protocol, even though it's actually not. We should instead create a new URN, such as internal:node/4. Apple, in the past two years or so, I think, got flamed for using webcal:// for it's iCal application, where webcal was merely a file format, and not a protocol.

I agree. I would propose to use some wiki convention, like wikipedia's [[node label | internal:node/1]].

I will leave the question of internal: vs. internal:// to people who are more pedantic than I (which is quite a feat, believe me <g>), but please let us not go down the wiki path. I despite wikis and everything about them, primarily due to their insistence on creating a completely new obscure markup syntax that does nothing but render down to HTML anyway. If you're going to write markup that ends up as HTML, WHY learn yet another syntax instead of just using what already works and is more self-descriptive and self-documenting anyway (HTML)?

By the way, although I am listening since some time, this is the first message I post. I am using Drupal for a web site about a conference (http://www.pi.infn.it/congressi/tau06/). I did some php coding for it, a theme and something that could become a conference module.

In that web site I use the wiki module, where one can use [label | http:?q=node] for internal links. This would break if Drupal changes the ?q= notation.

Greetings,

Welcome to Drupal, and don't mine the egos. :-) None of it's personal; we just care a great deal about what we do, and all believe we're right. It is the way of things. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

As a follow-up ... On Aug 4, 2006, at 7:30 PM, Morbus Iff wrote:

Actually, for what it's worth, we should NOT use internal:// or *any* foo:// patterns. Doing so, even internally, is a creation of what appears to be a new protocol, even though it's actually not. We should instead create a new URN, such as internal:node/4. Apple, in the past two years or so, I think, got flamed for using webcal:// for it's iCal application, where webcal was merely a file format, and not a protocol.

Path Filter (http://drupal.org/project/pathfilter) has been updated accordingly. From the README.txt ... Path Filter takes internal drupal paths in double quotes, written as e.g. "internal:node/99", and replaces them with the appropriate absolute http URL using drupal's url() function. Ray