Answers.Body: <p>The file system path has to be an absolute path from the root of your filesystem, like /Users/myuser/webserver/myproject/public/assets/images. </p>
  
  <p>For portability between different environments, it's a good idea to make an environment variable that holds the path to your project, which you can then use in the assets file system path. This is described very nicely in the <a href="http://buildwithcraft.com/docs/multi-environment-configs#environment-specific-variables" rel="nofollow">"Environment-Specific Variables" section of the "Multi-Environment Config" part of the docs</a>.  </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-08T17:22:09.567Z
Answers.Text: Thanks! I read that page multiple times, but thought I didn't need it as I don't work in a multi-environment. Is it correct that I can add a custom variable in the general.php file and access it through {{ craft.config.customVariable }} in templates (that works for certain). But I can't use { customVariable } in an asset source setting? I can only use { customVariable } when it's in an environmentVariable in my general.php. Is that correct? It seems so as everyhting works now, but the idea behind it seems strange.
Answers.UserDisplayName: Tom De Smet
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-08T17:53:12.340Z
Answers.Text: That is correct. I think the reason why not all config variables can be used this way has to do with performance, I think I remember Brandon mentioning that in some other thread.
Answers.UserDisplayName: André Elvan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-08T14:55:36.983Z
Answers.LastActivityDate: 2014-11-08T14:55:36.983Z
Answers.UserDisplayName: André Elvan
Body: <p>I have a multi-lingual site with a folder structure set up like this:</p>
  
  <pre><code>/craft
  /assets
    -/images
  /nl
    -index.php
  /fr
    -index.php
  index.php
  </code></pre>
  
  <p>I have an asset source set up like this:</p>
  
  <pre><code>File system path: assets/images/
  File URL: http://krycer.be/assets/images/
  </code></pre>
  
  <p>This allows me to upload images without any problems and they are uploaded in the correct folder on the server.</p>
  
  <p>I use image transforms in my templates by using the <code>{{ asset.getUrl('imageTransformHandle') }}</code> but this gives me errors. The images are not generated (there is no redirect to the generated image, the URL is linking to the cpResources/transform/ID).</p>
  
  <p>When I try this code in devMode <code>'generateTransformsBeforePageLoad' =&gt; true</code> it gives me an error that it cannot find the file (allthough it is definitely on the server).</p>
  
  <p>I tracked this issue back to the fact that I have sub folders for my languages (nl/fr) and probably the image transform module searches a path from the local index.php file.
  So when I adjust the asset source to <code>../assets/images/</code> the transforms are generated and I can see the images.
  But then I have the problem that I can no longer upload any images because the path is not correct (because the asset source is probably looking in relation to the top index.php file, being the one above the nl/fr folders).</p>
  
  <p>How do I fix this and is this a bug or is there an easy idea behind it I do not grasp?</p>
  
Tags: <image-transforms>
Title: Image Transform path issue
ThreadText: # Image Transform path issue
  
  (Asked by: username_0 on 2014-11-08)
  
  I have a multi-lingual site with a folder structure set up like this:
  
  ```
  /craft
  /assets
    -/images
  /nl
    -index.php
  /fr
    -index.php
  index.php
  
  ```
  
  I have an asset source set up like this:
  
  ```
  File system path: assets/images/
  File URL: http://krycer.be/assets/images/
  
  ```
  
  This allows me to upload images without any problems and they are uploaded in the correct folder on the server.
  
  I use image transforms in my templates by using the `{{ asset.getUrl('imageTransformHandle') }}` but this gives me errors. The images are not generated (there is no redirect to the generated image, the URL is linking to the cpResources/transform/ID).
  
  When I try this code in devMode `'generateTransformsBeforePageLoad' => true` it gives me an error that it cannot find the file (allthough it is definitely on the server).
  
  I tracked this issue back to the fact that I have sub folders for my languages (nl/fr) and probably the image transform module searches a path from the local index.php file.
  So when I adjust the asset source to `../assets/images/` the transforms are generated and I can see the images.
  But then I have the problem that I can no longer upload any images because the path is not correct (because the asset source is probably looking in relation to the top index.php file, being the one above the nl/fr folders).
  
  How do I fix this and is this a bug or is there an easy idea behind it I do not grasp?
  
  **Tags:** image-transforms
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2014-11-08. Score: 3 | Accepted answer
  
  The file system path has to be an absolute path from the root of your filesystem, like /Users/myuser/webserver/myproject/public/assets/images.
  
  For portability between different environments, it's a good idea to make an environment variable that holds the path to your project, which you can then use in the assets file system path. This is described very nicely in the ["Environment-Specific Variables" section of the "Multi-Environment Config" part of the docs](http://buildwithcraft.com/docs/multi-environment-configs#environment-specific-variables).
  
  > **Comments:**
  > **username_0**: Thanks! I read that page multiple times, but thought I didn't need it as I don't work in a multi-environment. Is it correct that I can add a custom variable in the general.php file and access it through {{ craft.config.customVariable }} in templates (that works for certain). But I can't use { customVariable } in an asset source setting? I can only use { customVariable } when it's in an environmentVariable in my general.php. Is that correct? It seems so as everyhting works now, but the idea behind it seems strange.  
  > **username_1**: That is correct. I think the reason why not all config variables can be used this way has to do with performance, I think I remember Brandon mentioning that in some other thread.  
  
  ---
  
  