not sure if this has something to do with Imageapi or Imagecache.

After upgraded to imagecache2.0, when I render node the first time everything works fine (correctly scaled and cropped). The problem occurs when revisiting the node.

for example:
the wrong url is: http://mysite.com/en/files/imagecache/thumbnail/images/don+muang.jpg

instead of: http://mysite.com/files/imagecache/thumbnail/images/don+muang.jpg

refresh will temporary solve the problem.

Comments

jeff h’s picture

I have the same problem. In my case I'm printing an image in my node body using PHP as follows:

<img src="'.$base_path.path_to_theme().'/images/book.jpg">

This works for the default language, but not when i18n inserts the language code. ie

mysite.com/sites/all/themes/mytheme/images/book.jpg

but in German, the url becomes:

mysite.com/de/sites/all/themes/mytheme/images/book.jpg

...which imagecache seemingly cannot handle.

dopry’s picture

Version: 5.x-2.0 » 5.x-2.x-dev
Status: Active » Postponed (maintainer needs more info)

Is i18n a part of core? Is translating images like this normal? The way i18n works, does it allow you to upload a unique file per language centric node?

drewish’s picture

no, i18n is contrib. it rewrites the URLs so that they have a language code in them.

you could have separate images on each node or you could synchronize the files between the nodes in a translation set... but i don't really think that's the problem.

mnlund’s picture

Status: Postponed (maintainer needs more info) » Needs review

The problem is that i18n_url_rewrite isn't returning the original path. The alias with lang_prefix/... is created, but no file can be found when no valid path is returned. custom(i18n)_url_rewrite is called through drupal_get_alias which again is called from url(). Some implementation has to be done in i18n to overcome this, but my suggestion is to go the same way with imagecache_create_url as file_create_url in drupal core. There is no point in having an alias for an image file.

Change line 202 to:

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

This is at least working with the i18n module enabled.

dopry’s picture

Status: Needs review » Closed (won't fix)

sorry can't switch that it will break imagecace + public files w/o clean urls.

i18n just needs to be more cautious in its rewriting in this case.

owen barton’s picture

For anyone still running into this, you can fix this by adding something like:

    // Don't rewrite URLs for imagecache images
    if (strpos($path, file_directory_path() .'/imagecache/') !== FALSE) {
      return $path;
    }

- to the beginning of your active custom_url_rewrite() function (which could be in i18n module or in a custom module. I am not sure if there is an elegant way of fixing this (in Drupal 5 at least) - i18n would have to add code specifically for imagecache, or implement a hook so that imagecache can suppress rewriting on these URLs.

keesje’s picture

I think this applies for everything inside the /files directory (or wherever your "File system path" is set to.)

Who's problem is this? Are modules like imagecache using the wrong API for generating file URL's? Or should i18n be more careful not to rewrite "File system path" URL's?

drewish’s picture

i'm guessing it's i18n since imagecache seems to work for the majority of people.