I add the "$conf['insert_absolute_paths'] = FALSE;" in the settings.php
but it still absolute path saved in the body.

help me thx!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

luisgic’s picture

I want the path is relative paths

dman’s picture

Looking at insert_create_url() in http://drupalcode.org/project/insert.git/blob/refs/heads/7.x-1.x:/insert...
- that option seems to have no effect at all.
http://drupal.org/node/622964#comment-4092644 says that something about it is hard in D7.

quicksketch’s picture

Yes, so the problem is in Drupal 7 there is no general ability get relative URLs because Drupal 7 uses "stream wrappers", for file locations, which you could think of a aliases.

For example files in the public files directory (usually at /sites/default/files) are referenced like this: public://subdirectory/example.png, to which the full relative path is /sites/default/files/subdirectory/example.png. Unfortunately Drupal 7 provides no support to actually find this relative URL, because not all stream wrappers (like this example for "public://") are for local files. For example you could have a Flickr module that stores the path flickr://username/picture-id.jpg. When actually printed to the page, Drupal would make this a into a full URL such as http://www.flickr.com/photo-id.jpg. There is no restriction as far as Drupal is concerned about whether you use remote files or local ones. Because not all files have a local URL, Drupal doesn't provide any way to get the local URL for any files.

Now these problems aren't surmountable, but I thought I'd at least give an explanation of why this isn't implemented.

nico059’s picture

For your information, I modified the function insert_create_url($uri)
I don't know if there is "border effect" with stream wrapper ... but in my case (juste public file) it works.

function insert_create_url($uri) {
  // This variable has no configuration location. It may be set by placing
  // $conf['insert_absolute_paths'] = FALSE;
  // in the site settings.php file, or by manually running variable_set().
  // For reasons why this might not do what you want and why there's no UI
  // see http://drupal.org/node/640352.
  $absolute = variable_get('insert_absolute_paths', TRUE);

  // TODO: Rewrite this function to support relative paths? Tricky because
  // not all stream wrappers support local paths at all.
  if ($absolute) {
    return file_create_url($uri);
  }
  else {
    return str_replace($GLOBALS['base_url'],'',file_create_url($uri));
  }
}

Perhaps the str_replace could be more "robust" by checking with a substr before that the string begin at char 0.

davidwhthomas’s picture

Status: Active » Needs review
FileSize
629 bytes

+1 to the above solution, works well for me.

In my case, content loading is occurring on staging which will move to a new production domain, so relative URLs are v.useful

patch attached.

quicksketch’s picture

Status: Needs review » Needs work

Thanks guys, looks like a pretty simple solution but it needs to at least:
- Work with private files.
- Work when Drupal is installed in a subdirectory.

davidwhthomas’s picture

Would it not already work with private files? did you test that?
As all the patch does is strip the base_url / domain from the url /system/files.. should be preserved.

On point 2, would stripping out the base_path and keeping a leading slash suffice for when installed in subdirectory?

cheers,

DT

JGO’s picture

Need this urgently, inserting full path is absolutely BAD! My site runs on multiple domains and this really sucks.
Imagepicker does this indeed very good without any issues, so I guess this module must be able to do as well !

davidwhthomas’s picture

@JGO, just use the patch in #5
it works.

JGO’s picture

Indeed thx, it looks like it works very well. I hope this gets into the D7 version soon !!

hdcoder’s picture

quicksketch I join the request. Better relative path! You can add a normal setting, if you do not want to do relative paths for all. Parameter $conf['insert_absolute_paths'] = FALSE in settings.php not work!

PS: Another quick and correct solution. Please add hook for function insert_create_url($uri), for add patches without correcting code of your module.

fasdalf@fasdalf.ru’s picture

Works for me too. Thnx!

fasdalf@fasdalf.ru’s picture

Colorbox enabled inserts are not affected by this hack. I'm not sure, if it's insert or colorbox feature...

hass’s picture

Major issue if you run a site with SSL and content can be accessed from both URLs.

JGO’s picture

Indeed major issue, please fix! :|

graytoby’s picture

It's probably colorbox. There's a template file in colorbox module folder, colorbox-insert-image.tpl.php. It prints out $link_path and $image_path. I don't know what variables it should print to get relatives paths, but if someone knows, at least colorbox issue would be easily solved.

Edit: Actually, there is a patch for colorbox module at http://drupal.org/node/1207372#comment-4687002

phonographstudio’s picture

Status: Needs work » Needs review
FileSize
1.86 KB

Following the work on patch at #5. Here is a patch that add support for relative file path for local files.

Furthermore, it implement hook_variable_info so if one install the variable module, a UI is provided to interact with the insert_absolute_paths variable.

As per quicksketch comment #6, this patch works if Drupal is installed in a subdirectory and supports both public and private files.

Works fine for me. Maybe the regular expression needs rework for path using special characters.

Hope this helps ;)

healycn’s picture

subscribe

mrmeech’s picture

Patch in #17 seems to work well over here so far! Neat!!

texas-bronius’s picture

Two cents: @phonograhstudio's patch in #17 works for me for public files. Did not test private. THANKS for contributing!

dankobiaka’s picture

I have developed a simple module to resolve this issue - http://drupal.org/sandbox/dankobiaka/1308084

(my first attempt at committing code back to Drupal.org)

pianomansam’s picture

Priority: Normal » Major

I also want to put in my support for the resolution of this issue.

I have a client who entered thousands of nodes on a review subdomain, only to have all the links inserted by this module be invalidated because absolute paths. It was not fun writing the PHP/SQL to go through and correct all these paths.

Everything about Drupal makes it host/domain agnostic. This isn't the case with many CMSes out there, including WordPress. This is one of the draws of Drupal, and I use this fact when I talk about the pros of Drupal. In order to keep with the "Drupal way", this module should have the same host/domain agnosticism. For this purpose, I am bumping this bug report to "major."

carn1x’s picture

@pianomansam have you looked at the Pathologic module? It is an input filter you can apply to specific text formats which will rewrite paths based on various patterns you provide it with. For instance if you gave it the patterns:

http://development.host.com
http://www.host.com

Then whenever you clear the site cache, it would alter any URLs in the body from the patterns you provide, and update them to whatever the current URL should be relatively. For the example I provided, you could swap the site happily between www. and development..

I'm not suggesting this issue for relative paths is not a good idea, but Pathologic provides a great workaround.

EDIT: Just realised that I may have misread your problem entirely :) But still my recent confusion with Insert modules absolute paths were cured with the above!

JGO’s picture

The fix is here, we are several months further, is it implemented ?

simon_s’s picture

Please implement this patch!

It also would great to have checkbox for using relative paths in the admin area of the insert module.

Thanks so much!

rhawkins’s picture

Bump. I also lost all photos after migrating from a development site (dev.domain.com) to production (domain.com). I was shocked to see the hardcoded domains from this module. This should really use relative paths by default or at least expose the option. The point is to give users a simple way to insert images so that they do not accidentally use a hardcoded domain.

Todd Young’s picture

Indubitably! Would like to see it rolled into a new release, very much a drag when you move a site and all links break.

quiptime’s picture

To use relative paths for multi-sites it is possible to use mod_rewrite. Take a look at this discusion: http://drupal.org/node/84895

I think to use relative paths it is not a good idea implement a partial solution in contrib modules as a solution for this modules.

rhawkins’s picture

quiptime - That issue is not really relevant. For one thing, I am not talking about multisites, I am talking about development vs production which do not share any code like a multisite environment would; for another, using mod_rewrite for fixing paths like this is like using an axe to split a toothpick.

Again I can't believe this module, which is supposed to help users work faster and make them less likely to make errors, inserts hardcoded domains. It's ironic

JGO’s picture

Indeed rhwakins, it's terrible! It's still not fixed and the fix is easy :(

pianomansam’s picture

Knowing the MO of the maintainer, quicksketch, we need to demonstrate the patch in #17 is tested and working. I haven't had a use case yet to test it out, but who has? If we demonstrate it's thoroughly tested, we can mark this as review and tested by the community.

JGO’s picture

It's tested with great succes on my site for months. And a few others have this successfully tested as well as far as I can see in the replies.

pianomansam’s picture

JGO, is your site using private files or operating in a subdirectory?

ralphb’s picture

subscribe

W.M.’s picture

Correct me if I am wrong, but it seems that the patch at #17 does not work with Filefield paths module

I am very sorry. I did not pay attention to the fact that this line needs to be added to settings.php first for all that to work:

$conf['insert_absolute_paths'] = FALSE;

Patch at #17 works perfectly

Michael-IDA’s picture

Hi quicksketch,

Have you abandoned Insert?

We need private files for user uploads, and were going to use Media, but it doesn't do them well, so wanted to use Insert, but absolute paths fubar Insert for us as well.

"Yes, so the problem is in Drupal 7 there is no general ability get relative URLs..."

I do notice that the image on the node/add form is being displayed with the proper (re-formated) URL, http://{server.com}/system/files/content/..., and not the private://... internal representation. So, is your comment #3, from May 7, 2011, it still an issue?

Even a kludge of an extra "Insert w/o Domain Name" button next to the existing "Insert" button would work.

If you're going to continue w/ Insert, we'll apply the patch and do further testing, but if not, we'll head back over to Media and see if we can help straighten out it's private file issues.

Best,
Sam

Edit:
Although I think I like dankobiaka's idea in #21 better:

function _utslib_insert_absolute_to_relative($path) {
  global $base_url;
  
  if (isset($base_url)) {
    $path = str_replace($base_url, '', $path);
  }
  
  return $path;
}

Don't have to sort out if it's an offsite url or not...

quicksketch’s picture

Have you abandoned Insert?

No, I'm just extremely busy. It happens to all of us. You can help move this forward (as can everyone) by reviewing the existing patches and marking them RTBC. #17 looks pretty good to me, though it does include an unnecessary feature request at the same time. I don't think it'd do any harm though.

Michael-IDA’s picture

Thanks for the quick answer, so here's a quick test review :)

Patch #17 works to make my domain's URLs relative. Tested by uploading under https, and image displays properly from both http and https in full node, and picks up proper thumbnail in summary/teaser views.

I don't have the variable module installed, so can't test that.

I'm still not excited about the preg_match, and (famous last words) I'll do up a tighter patch tomorrow w/ just relative and str_replace.

quicksketch’s picture

I'm still not excited about the preg_match, and (famous last words) I'll do up a tighter patch tomorrow w/ just relative and str_replace.

Yeah I'm actually not sure what the purpose of the preg_match() is either. Seems like you could just do str_replace() like you suggested, but we should keep in mind that not all Drupal sites are at the root domain. So for example if you had your site installed under "/drupal", your site URL would be "http://example.com/drupal". If you str_replace()'d the whole $base_url, you'd end up with a broken path.

Example base path: http://example.com/drupal
Example URL: http://example.com/drupal/files/sample.png
Example relative URL with basepath removed: /files/sample.png (this is incorrect, should be /drupal/files/sample.png).

I'm not sure if the patch in #17 addresses this, but I know the code described in #36 would not work in this situation.

dankobiaka’s picture

I have modified my module code to support sites served from sub-directories.

http://drupalcode.org/sandbox/dankobiaka/1308084.git/commitdiff/b1a48465...

Michael-IDA’s picture

@ #39 & #40,

Hi quicksketch and dankobiaka,

What an ugly can of worms.

In the use case where one moves from "Example base path: http://example.com/drupal" to "Example base path: http://example.com/" then the relative paths are hosed, again.

I'm going to use dankobiaka base_root, because we will always be on a root domain.

Long term, I'd like to see dankobiaka's sandbox made a full module, with an exposed API call for other modules. But it probably needs to use tokens? to resolve the installed in a sub-directory / root domain. (So it would insert something like src="[site:url]/system/files/..." and then the filter would expand it on output.)

That said, I don't think any of the patches in this thread are viable.

Best,
Sam

PS: dankobiaka, thanks for the base_root, so many variable/APIs in drupal I never know about...
PSS: quicksketch, because I can't cut and paste, I ended up with this valid error:

Notice: Undefined variable: path in insert_create_url() (line 386 of /var/www/html/sites/all/modules/insert/insert.module).

while inserting one image. But it occurred 46 times! Should Insert be looping through insert_create_url 46 times?

Code I'm using:

Works with root domain, WYSIWYG, CKEditor 3.6.2.7275

function insert_create_url($uri) {
  // This variable has no configuration location. It may be set by placing
  // $conf['insert_absolute_paths'] = FALSE;
  // in the site settings.php file, or by manually running variable_set().
  // For reasons why this might not do what you want and why there's no UI
  // see http://drupal.org/node/640352.

  global $base_root;
  $absolute = variable_get('insert_absolute_paths', TRUE);

  // TODO: Rewrite this function to support relative paths? Tricky because
  // not all stream wrappers support local paths at all.
  $scheme = file_uri_scheme($uri);
  if (!$absolute && ($scheme == 'public' || $scheme == 'private')) {
    if (isset($base_root)) {
      $path = str_replace($base_root, '', file_create_url($uri));
      return $path;
    }
  }

  return file_create_url($uri);
}
quicksketch’s picture

In the use case where one moves from "Example base path: http://example.com/drupal" to "Example base path: http://example.com/" then the relative paths are hosed, again.

Yes I think that's merely something people will need to live with. If it's a problem then you can install Pathologic, though that won't help with the path in the editing interface.

That said, I don't think any of the patches in this thread are viable.

I think enough people have voiced their opinion that they don't really care if the relative URL will break under certain conditions. In their situations relative URLs will break *less* than absolute ones. There is no solution that Insert can provide using only basic HTML to make it so URLs won't break, and I don't think it's the responsibility of Insert to solve that problem anyway.

while inserting one image. But it occurred 46 times! Should Insert be looping through insert_create_url 46 times?

Let's keep focused on the task at hand, this sounds like a separate bug report or support request.

I think dankobiaka's approach should work fine, though of course it's not actually in a patch form to make it suitable for actually applying to the project.

HongPong’s picture

subscribing, thanks for dealing with this!

ressa’s picture

You can click the "Follow" button at the top to follow issues now :-)

hass’s picture

Status: Needs review » Needs work

Paths should be relative by default for SSL and non-SSL pages. Using full qualified URLs should always avoided. An interface is also required for people who don't like it. I believe the RSS issue can be solved by altering the URLs if an RSS feed is fetched. In this case we can use full qualified URLs. If this is not possible (like in D6 if I remember correctly), core need to change.

We could also make more if pathologic is installed and use the drupal internal paths only and leave the alias lookups to pathologic. This would allow moving a live site to DEV and vice versa.

hass’s picture

There seems to be one more bug in the patch.

If you attach an image to a taxonomy term and insert it into the description the patch is still full qualified and not relative to the webroot.

nixter’s picture

I think this module ( http://drupal.org/project/portable_path ) might solve the issue. It uses a stream wrapper to replace the sites url so it is never actually stored as an absolute path.

Input/output filter to store/restore paths using public and private stream wrapper notation. This module does two things:
- when content is saved, it will store URLs in text fields in a portable fashion.
- when content is rendered, the input filter will replace the stream wrapper URL with a relative path URL.

This can be easily used with the Insert module which inserts an absolute path by default. On save of the content, this module will replace the absolute path with a path using stream wrapper notation.

quicksketch’s picture

Priority: Major » Normal
Status: Needs work » Fixed

This has been fixed in #640352: Linking with relative paths.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.