I've checked this issue as good as I can. It seems that the WYSIWYG Image Upload module inserts absolute paths for the img src attribute in the form of http://example.com/sites/default/files...

I can't definitely say if the issue can be traced back directly to this module but I've checked the TinyMCE WYSIWYG module configuration and it seems TinyMCE isn't modifying the inserted path.

modules/wysiwyg/editors/tinymce.inc - line 154

    // TinyMCE's URL conversion magic breaks Drupal modules that use a special
    // syntax for paths. This makes 'relative_urls' obsolete.
    'convert_urls' => FALSE,

Documentation can be found in the TinyMCE FAQ

Also the ImageCache config doesn't seem to have any setting to control the behavior.

My file system path (admin/settings/file-system) in Drupal is set to "sites/default/files", so this shouldn't be an issue either.

CommentFileSizeAuthor
#14 relative_path.patch859 byteskndr

Comments

eugenmayer’s picture

eugenmayer commented
Category: support » bug

Will look into that. Thank you a lot for the investigation!

eugenmayer’s picture

eugenmayer commented
Project: WYSIWYG image upload - Inline images for your WYSIWYG » ImageCache
Version: 6.x-1.0-rc1 » 6.x-2.0-beta10
Status: Active » Needs review

Well thats actually something imagecache related, so moving over.

imagecache.module

function imagecache_create_url($presetname, $filepath, $bypass_browser_cache = FALSE) ...

return url($GLOBALS['base_url'] . '/' . file_directory_path() .'/imagecache/'. $presetname .'/'. $path, $args);

$GLOBALS['base_url'] is the cause of all this. No idea why this is actually done at all, seems like a bug to me.

troyer’s picture

troyer commented
Title: absolute paths in returend img src with TinyMCE » function imagecache_create_url - absolute path returned with base_url

I think I need to rephrase this bug.

Why does imagecache return an absolute path with the base_url included? This poses a problem in the case that I move the installation from a local domain to a live domain, in which case all images created in a WYSIWYG editor with TinyMCE (WYSIWYG-module + TinyMCE + WYSIWYG Image Upload module in my case) are hardcoded to http://server-localdev.local/.... If it would have been just the absolute url starting with "/" this wouldn't be a problem to move the site to live domain.

Please help me to get more insight on this issue.

imagecache.module - line 321 "return url($GLOBALS['base_url']....."

function imagecache_create_url($presetname, $filepath, $bypass_browser_cache = FALSE) {
  $path = _imagecache_strip_file_directory($filepath);
  if (module_exists('transliteration')) {
    $path = transliteration_get($path);
  }

  $args = array('absolute' => TRUE, 'query' => empty($bypass_browser_cache) ? NULL : time());
  switch (variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC)) {
    case FILE_DOWNLOADS_PUBLIC:
      return url($GLOBALS['base_url'] . '/' . file_directory_path() .'/imagecache/'. $presetname .'/'. $path, $args);
    case FILE_DOWNLOADS_PRIVATE:
      return url('system/files/imagecache/'. $presetname .'/'. $path, $args);
  }
}
troyer’s picture

troyer commented

Here's my solution to the problem. This fix alters the returned URL from http://somedomain.local/sites/files/... to /sites/files/....

Probably not perfect, but still better than a hardcoded domain.

I changed "$args = array('absolute' => FALSE,..." to FALSE and removed the base_url from the return.

function imagecache_create_url($presetname, $filepath, $bypass_browser_cache = FALSE) {
  $path = _imagecache_strip_file_directory($filepath);
  if (module_exists('transliteration')) {
    $path = transliteration_get($path);
  }

  $args = array('absolute' => FALSE, 'query' => empty($bypass_browser_cache) ? NULL : time());
  switch (variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC)) {
    case FILE_DOWNLOADS_PUBLIC:
      return url(file_directory_path() .'/imagecache/'. $presetname .'/'. $path, $args);
    case FILE_DOWNLOADS_PRIVATE:
      return url('system/files/imagecache/'. $presetname .'/'. $path, $args);
  }
}
garretg’s picture

garretg commented

Drupidoo's patch worked to solve a vexing problem with my site, which involves the Boost Module.

I won't detail the Boost misbehavior here (I will eventually file a bug report after further testing).... but it has to do with Boost generating a cache page that contains image tags which are absolutely qualified with https://servername. (Boost is designed for non-secure requests only.) The mixture of http page with https content causes browser warning messages and/or missing content (depending on if the cert if valid, and depending on the browser settings.)

Changing the imagecache_create_url() function, as Drupidoo suggests, fixed the problem perfectly. Image tags in the page start with / instead of (https:// or http://) and are valid for either the http or https server.

eugenmayer’s picture

eugenmayer commented
Priority: Normal » Critical
Status: Needs review » Reviewed & tested by the community

Bump!

this module is quier heavy spreaded and that issue is pretty critical. Can some maintainers have a look?

eugenmayer’s picture

eugenmayer commented

Guys, its a one-line trivial fix. Why is this issue ignored? It is critical to a lot of applocations.

darklight’s picture

darklight commented

BUMP!! Any DEVs out there?

pmonjo’s picture

pmonjo commented

Looks like those few lines are critical and need to be polished. I am having another problem with them in something completely unrelated. See http://drupal.org/node/776248.

markgukov’s picture

markgukov commented

Anyone looking into it?

eugenmayer’s picture

eugenmayer commented

Seems like those devs are not even interested. Very dissapointed.

drewish’s picture

drewish commented
Priority: Critical » Normal
Status: Reviewed & tested by the community » Active

Don't mark something as RTBC when there's not even a patch.

eugenmayer’s picture

eugenmayer commented

no comment.

kndr’s picture

kndr
he/him
Primary language Polish
Location Rybnik, Poland
commented
Status: Active » Reviewed & tested by the community
StatusFileSize
new relative_path.patch859 bytes

I confirm the problem with absolute paths generated inside imagecache_create_url. I've made a little research in past versions of this function and stumbled across drewish patch http://drupal.org/node/366177#comment-1471334 (I know what has happend here). After all I think, that drupidoo #4 is good proposal since core url() function recognizes Clean-url settings and properly generate relative url in both situations (with and withouth enabled clean urls). I've tested #4 with public downloads (enabled and disabled clean-urls) and everything looks good (Drupal 6.16, Linux Debian, Apache). I am attaching #4 patch and change issue status. Drewish, please consider this changes since it looks reasonable.

kndr’s picture

kndr
he/him
Primary language Polish
Location Rybnik, Poland
commented
Status: Reviewed & tested by the community » Closed (duplicate)

Look at http://drupal.org/node/241541