I'm building a site that is currently in a sub-directory of my web server document root, but when it is finally deployed it will be in the document root. So currently node 99 is at, e.g. http://example.com/dev/node/99 ... but when I deploy the site it will be at ... http://example.com/node/99 My question is, what is the best way to link to node/99 from the body of another node, and have it work on my dev server as well as the production server? Is there an input filter that converts a URL that is relative to drupal's root into an absolute URL? Ray
In Drupal 4.7, you would link to <a href="/node/99">now here I have linked to node 99</a> (with the leading slash, which references the root of the install, I believe). Laura On Jul 4, 2006, at 10:10 AM, Ray Zimmerman wrote:
I'm building a site that is currently in a sub-directory of my web server document root, but when it is finally deployed it will be in the document root. So currently node 99 is at, e.g.
http://example.com/dev/node/99
... but when I deploy the site it will be at ...
My question is, what is the best way to link to node/99 from the body of another node, and have it work on my dev server as well as the production server? Is there an input filter that converts a URL that is relative to drupal's root into an absolute URL?
Ray -- [ Drupal support list | http://lists.drupal.org/ ]
Unfortunately, the link you suggest would be broken on my dev server (drupal doesn't modify the link). It only works on a server that has drupal installed at the web server's document root. I need something that converts "/node/99" to "/dev/node/99" on my dev server and "/node/99" on my production server, based on where my drupal install happens to be in the web server document root. Btw, menus do work properly no matter where the server is installed. A menu that points to node/99 will point to /dev/node/99 on my dev server and /node/99 on the production server. I'm just looking for a way to do that same translation for internal links embedded in content. Isn't this an issue for lots of people? I find I'm always making copies of my site (throw my whole installation in a new directory and point it to a duplicate of the database) to play around with new features. Doesn't everyone do this? :-) How can I do it without it breaking all the internal links in my content? Ray On Jul 4, 2006, at 2:17 PM, Laura Scott wrote:
In Drupal 4.7, you would link to <a href="/node/99">now here I have linked to node 99</a> (with the leading slash, which references the root of the install, I believe).
Laura
On Jul 4, 2006, at 10:10 AM, Ray Zimmerman wrote:
I'm building a site that is currently in a sub-directory of my web server document root, but when it is finally deployed it will be in the document root. So currently node 99 is at, e.g.
http://example.com/dev/node/99
... but when I deploy the site it will be at ...
My question is, what is the best way to link to node/99 from the body of another node, and have it work on my dev server as well as the production server? Is there an input filter that converts a URL that is relative to drupal's root into an absolute URL?
Ray -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
On Tuesday 04 July 2006 12:22, Ray Zimmerman wrote:
Unfortunately, the link you suggest would be broken on my dev server (drupal doesn't modify the link). It only works on a server that has drupal installed at the web server's document root.
I need something that converts "/node/99" to "/dev/node/99" on my dev server and "/node/99" on my production server, based on where my drupal install happens to be in the web server document root. Btw, menus do work properly no matter where the server is installed. A menu that points to node/99 will point to /dev/node/99 on my dev server and /node/99 on the production server. I'm just looking for a way to do that same translation for internal links embedded in content.
Try it w/o the leading slash. If your $base_url is setup correctly (and 4.7 is supposed to handle that for you), it should work with either path. If that still doesn't work, try setting and uncommenting the $base_url variable in your sites/default/settings.php file.
Isn't this an issue for lots of people? I find I'm always making copies of my site (throw my whole installation in a new directory and point it to a duplicate of the database) to play around with new features. Doesn't everyone do this? :-) How can I do it without it breaking all the internal links in my content?
Ray
-- Jason Flatt http://www.oadae.net/ Father of Six: http://www.flattfamily.com/ (Joseph, 13; Cramer, 11; Travis, 9; Angela; Harry, 5; and William, 12:04 am, 12-29-2005) Linux User: http://www.sourcemage.org/ Drupal Fanatic: http://drupal.org/
On Jul 4, 2006, at 3:40 PM, Jason Flatt wrote:
Try it w/o the leading slash. If your $base_url is setup correctly (and 4.7 is supposed to handle that for you), it should work with either path. If that still doesn't work, try setting and uncommenting the $base_url variable in your sites/default/settings.php file.
That doesn't work either. I do have $base_url set correctly, and I assume that is why, for example, menus that point to "node/99" work fine when moved to a site with a different $base_url. However, I don't think links in content are affected in any way by $base_url. In fact, they can't be unless Drupal is doing filtering of <a href="..."> tags by default (which would be a surprise to me). Suppose I have content in, say, node 10 that contains the following link <a href="node/99">link</a>. These are simple relative URLs that are turned into absolute URLs by the browser, resulting in the following: Dev site: $base_url = "http://example.com/dev"; node 10 at: http://example.com/dev/node/10 link points to: http://example.com/dev/node/node/99 Production site: $base_url = "http://example.com/"; node 10 at: http://example.com/node/10 link points to: http://example.com/node/node/99 In both cases, the link is obviously broken. To be fair, it appears that these relative URLs *did* work in Drupal 4.6, because it (ab)used a base tag that was added to every page pointing to the root URL of your site. Since this (ab)use of base was fixed in 4.7, relative URLs no longer work. [1] I'm coming to the conclusion that it requires an input filter to convert relative internal links into absolute URLs by using $base_url. Any other possibilities? Ray [1] According to http://drupaltutorials.com/ drupal_theme_development#differences_between_drupal_4.6_and_4.7
On Jul 4, 2006, at 5:14 PM, Ray Zimmerman wrote:
I'm coming to the conclusion that it requires an input filter to convert relative internal links into absolute URLs by using $base_url.
Aha ... Base Path Filter ... http://drupal.org/node/58777 Ray
Op dinsdag 4 juli 2006 23:14, schreef Ray Zimmerman:
Any other possibilities?
I advice you to not use "hardcoded" links at all. Look at some filters like title-filter, interwiki or so. The links package (links module) has other nice links handling tools for you. That way you only store references to links (reference to the data) and not the links themselves (embedded data). IMO it is a bad practice to hardcode "stuff" like links, images, quotes, etc inside a node. These are 'metadata' things. Hence should live in a separate place. More pragmatic: If you have references to the data, that gets turned into real links (like [link:134]) and you choose to change your internal url scheme (pathauto) or you move your server (I recently moved from www.foobar/ to foobar/ and had to preg-replace thousands of entries) your code will take care of that change. Bèr
On Jul 5, 2006, at 6:27 AM, Bèr Kessels wrote:
I advice you to not use "hardcoded" links at all. Look at some filters like title-filter, interwiki or so. The links package (links module) has other nice links handling tools for you.
That way you only store references to links (reference to the data) and not the links themselves (embedded data).
Thanks for the pointers. I agree with you in general, especially in the case of external links. But, I would argue (though not very strongly) that for internal data, node/99 *is* a reference to the data that I want to be translated into a link (which depends on my server's $base_url, path aliasing, etc). In fact, these internal references (paths) are used all over drupal, esp. in the menu system. However, I can't find any solutions for using these internal references in content that appear to be supported. title.module (http://drupal.org/project/title) - appears to be abandoned interwiki (http://drupal.org/project/interwiki) - good for links to specific external resources, but not internal links links package (http://drupal.org/node/24719) - does not appear to handle internal links, like node/99 Base Path Filter (http://drupal.org/node/58777) - does not appear to be in contrib cvs (plus I prefer an explicit filter syntax for internal links)
IMO it is a bad practice to hardcode "stuff" like links, images, quotes, etc inside a node. These are 'metadata' things. Hence should live in a separate place.
More pragmatic: If you have references to the data, that gets turned into real links (like [link:134]) and you choose to change your internal url scheme (pathauto) or you move your server (I recently moved from www.foobar/ to foobar/ and had to preg-replace thousands of entries) your code will take care of that change.
My point exactly. Is there an existing module that actually does this? Ideally, I think the links package should handle this, but if it does I missed it. Did the old weblink module support internal links? Maybe I'll file a feature request with the links package. Still looking for the right solution ... Ray
Op woensdag 5 juli 2006 15:58, schreef Ray Zimmerman:
My point exactly. Is there an existing module that actually does this? Ideally, I think the links package should handle this, but if it does I missed it. Did the old weblink module support internal links? Maybe I'll file a feature request with the links package.
There was none in weblinks. But it sounds like a simple feature for the links bundle. Something in lines of [node:123] should do, imo. But otherwise a filter module (I don't know how module develop savvy you are) that filters all 'node/123' that inserts a link for that node/123 is not hard at all. This is the regexp: \bnode/[0-9]+\b And here is a great filter example module: http://cvs.drupal.org/viewcvs/drupal/contributions/docs/developer/examples/f... Bèr
On Jul 7, 2006, at 2:35 AM, Bèr Kessels wrote:
Something in lines of [node:123] should do, imo.
But otherwise a filter module (I don't know how module develop savvy you are) that filters all 'node/123' that inserts a link for that node/123 is not hard at all. This is the regexp:
\bnode/[0-9]+\b
And here is a great filter example module:
http://cvs.drupal.org/viewcvs/drupal/contributions/docs/developer/ examples/filter_example.module?view=markup
OK, I whipped together a filter for internal paths and internal links 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. I'll be happy to apply for CVS access and create a project for it, if others would find it useful. Ray
On 7/4/06, Ray Zimmerman <rz10@cornell.edu> wrote:
Isn't this an issue for lots of people? I find I'm always making copies of my site (throw my whole installation in a new directory and point it to a duplicate of the database) to play around with new features. Doesn't everyone do this? :-) How can I do it without it breaking all the internal links in my content?
I frequently make new subdomains for these temporary purposes instead of new folders live site: example.com test site: test.example.com That way the site stays relative in test and production. I agree with Ber that a filter solution is a good idea, but the subdomain works quickly for me since it's just as easy for me to add a subdomain as a new directory. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
participants (5)
-
Bèr Kessels -
Greg Knaddison - GVS -
Jason Flatt -
Laura Scott -
Ray Zimmerman