internal link filter & master filter list
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: 1. Is there an official master list of input filter syntax somewhere that I can consult to make sure I don't use syntax that tromps on somebody else's existing filters? I was thinking of using something like [ilink:<internal_path>] (for internal link). 2. Can anyone suggest an alternate solution to the problem I'm trying to solve [1]? On a related note, I believe ideally, the Links package [2] should handle internal links as well as external ... not sure if that's the intention ... Scott? Thanks, Ray [1] There seems to be no supported solution for including robust internal links in your content (please educate me if I'm wrong here). The problem is to find a way to create an internal link in my content that will continue to work correctly without modification (e.g. like menu paths do) when I move the site to a new path. See this thread on the support list for a bit more background: http://lists.drupal.org/ archives/support/2006-07/msg00058.html [2] http://drupal.org/node/72459
Hello, 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:
I wrote such a simple filter [1] for a project of mine. But since it is a bit hackish, I hesitated to contribute it. It also does some SPAM protecting e-mail address rewriting too. It should be the very last filter in an input filter chain. Valid Syntax is one of the following: {internal URL} {link text|internal URL} {e-mail address} {link text|e-mail address} Hope that helps. Or might even get in shape to become a contributed Drupal module.
2. Can anyone suggest an alternate solution to the problem I'm trying to solve [1]? On a related note, I believe ideally, the Links package [2] should handle internal links as well as external ... not sure if that's the intention ... Scott?
I know of no (elegant) solution, either. Regards, Martin [1] http://misc.afanasjew.de/drupal/linkrewrite.module
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:
On Jul 7, 2006, at 1:11 PM, Dave Cohen wrote:
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".
The problem with this approach is that it is limited to simple node/ nid links. I want something that could be used for any internal path (e.g. think, anything that can be entered in the "path" field for a menu item). Ray
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
Good idea. 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. Bèr Op vrijdag 7 juli 2006 15:21, schreef Ray Zimmerman:
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:
1. Is there an official master list of input filter syntax somewhere that I can consult to make sure I don't use syntax that tromps on somebody else's existing filters? I was thinking of using something like [ilink:<internal_path>] (for internal link).
2. Can anyone suggest an alternate solution to the problem I'm trying to solve [1]? On a related note, I believe ideally, the Links package [2] should handle internal links as well as external ... not sure if that's the intention ... Scott?
Thanks,
Ray
[1] There seems to be no supported solution for including robust internal links in your content (please educate me if I'm wrong here). The problem is to find a way to create an internal link in my content that will continue to work correctly without modification (e.g. like menu paths do) when I move the site to a new path. See this thread on the support list for a bit more background: http://lists.drupal.org/ archives/support/2006-07/msg00058.html
[2] ttp://drupal.org/node/72459
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 Thursday 13 July 2006 08:22, Syscrusher wrote:
As the maintainer of the Links package, I'd be happy to work with you to get this functionality integrated into Links.
Bonk....I'm sorry, "you" is ambiguous here. The "you" was meant to be Ray, not Ber. Apologies for being unclear. 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 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. 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 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
On Jul 13, 2006, at 1:20 PM, Syscrusher wrote:
I'll respond separately to the rest of the post (excellent discussion, btw),
Thanks, I'm looking forward to your response. Btw, I just noticed now in the links_related.module that if you turn on the links tabs, it looks like some work has already been done toward handling embedded links. Somehow, I'd missed that before. How do you envision this working? 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
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>
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
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 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
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
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 Aug 2, 2006, at 2:46 PM, Rob Barreca wrote:
I renamed my module to pathfilter and just ported all your code over.
OK, I suppose this is fine ... I was kinda waiting a bit for some other opinions before jumping, but that's fine. The docs on the project page and in the README should also be updated to reflect the fact that this filtering happens anywhere it finds an internal://some/path style URL, not just in the href attribute of an <a> tag. E.g. I often use it in the src attribute of an <img> tag. 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.
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
On Wednesday 02 August 2006 16:51, Greg Knaddison - GVS wrote:
I prefer the idea of internal:// over Drupal.
+1 from me also, for reasons others have already stated well. Syscrusher -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
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 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.
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. -- Morbus Iff ( take this ming! i'm sick of your dynasty! ) 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
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 ...
On Aug 4, 2006, at 8:33 PM, Khalid B wrote:
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. Btw, were you agreeing about using internal:node/4, or just about *not* using internal://node/4? Ray
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
On Aug 4, 2006, at 7:30 PM, Morbus Iff wrote:
In fact, I have a feeling that we should put an effort behind foo:// patterns as defacto standard for Drupal over [foo:] patterns.
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.
Aww man ... that's exactly what I was concerned about when I asked last week if there was "any standard or convention for choosing the label we use for such a URL". The only docs I found in some quick googling were way out of date, so I wasn't sure what the current standards permit. I guess for a filter, maybe I'd better limit the regex to searching for internal: after an href=" or a src=" With internal:// I felt it was relatively safe to search for it anywhere. Ray
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
Just correcting myself: On 8/5/06, Alberto Lusiani <alusiani@gmail.com> 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 just realize that what I write makes little sense, and it's equivalent to using "internal:node/1". If there is a separate wiki filter, then something like [[node label | internal:node/1]] will also work, provided that internal:node/1 is turned into a valid link. 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
You are right, URNs suit this problem a lot better than URI-style strings. For all of you who want to test that: If you have iTunes installed, type "itms:" into your browser's adress bar and hit return. 2006/8/5, Morbus Iff <morbus@disobey.com>:
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.
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.
-- Morbus Iff ( take this ming! i'm sick of your dynasty! ) 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
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
I made a small urlaliasfilter module http://drupal.org/node/58520 to do this in a cleaner way IMO (with no brackets, just a simple HTML A tag). I'd like any sort of critiques, patches, suggestions, but I had a need for this and it does the job okay enough. I know regex is not a proper way to parse HTML as it can run into trouble so I think if the HTML is complex at all a [link:node/99|link title] would be better, but I like being able to use pure HTML. Also, if this is a duplication of code at all, I'd like to know so I can combine efforts with another module. Let me know if this helps at all. Rob Roy Barreca Electronic Insight Corporation 12526 High Bluff Drive, Suite 300 San Diego, CA 92130 http://www.electronicinsight.com rob@electronicinsight.com 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:
1. Is there an official master list of input filter syntax somewhere that I can consult to make sure I don't use syntax that tromps on somebody else's existing filters? I was thinking of using something like [ilink:<internal_path>] (for internal link).
2. Can anyone suggest an alternate solution to the problem I'm trying to solve [1]? On a related note, I believe ideally, the Links package [2] should handle internal links as well as external ... not sure if that's the intention ... Scott?
Thanks,
Ray
[1] There seems to be no supported solution for including robust internal links in your content (please educate me if I'm wrong here). The problem is to find a way to create an internal link in my content that will continue to work correctly without modification (e.g. like menu paths do) when I move the site to a new path. See this thread on the support list for a bit more background: http://lists.drupal.org/archives/support/2006-07/msg00058.html
participants (13)
-
Alberto Lusiani -
Bèr Kessels -
Dave Cohen -
eric Farris -
Greg Knaddison - GVS -
Khalid B -
Konstantin Käfer -
Larry Garfield -
Martin Afanasjew -
Morbus Iff -
Ray Zimmerman -
Rob Barreca -
Syscrusher