I noticed IMCE uses a path like img src="/mysubdirectory/sites/files..."

This brakes images when I move the site (for example to a live site from test).

Any ideas for a solution?


ufku’s picture

Category:bug» support

This the default behavior for inline paths in nodes. You should have used a subdomain for development.
path for domain.com => /path/to/file
path for domain.com/sub => /sub/path/to/file
path for sub.domain.com => /path/to/file

lejonsson’s picture


I do not buy this! One should be able to develop in a sub domain folder without having to keep that file structure when moving to a different server. It works fine to have file references in nodes just referring from within the sub folder, then IMCE should be able not to return the whole server-specific path either. The prefix should be removed from the returned URL, IMO (at least this should be configurable).

lejonsson’s picture

Version:6.x-1.x-dev» 6.x-1.2
Category:support» bug

I still think this should be considered a bug, too many people have expressed similar concerns and I have not seen a solution presented to resolve the issue. To say that you should not develop in a sub directory is not an answer as everything works fine doing so and using short relative urls in nodes, the problem is simply that you will have to manually edit what IMCE returns, which is not very practical.

ufku’s picture

Status:Active» Closed (duplicate)

You have already seen #199484: Relative Image Path [SOLUTION]
Please pay attention to comment#10

To summarize, the image <img src="files/name.jpg">
points to http://yourdomain/files/name.jpg at your front page
but points to http://yourdomain/node/1/files/name.jpg at your node/1 page.

lejonsson’s picture

Status:Closed (duplicate)» Active


I have seen 199484 and I have read comment #10. From my point of view, that comment just says TinyMCE does the same mistake as IMCE, it makes a server-specific path being saved in the database, which I claim is clearly an undesirable outcome. In realtime, a relative path will be appended with a proper prefix for the server, so one should never save anything but a server-independent relative path in the database, as I see it. Please explain why a server-specific path makes sense to save in the database, as that may (in my case it does) makes the path fail if the site is moved to a different server setup.

I guess we are both failing to understand eachothers arguments, personally I do not understand the point you are trying to make in "To summarize" above. Would you like to elaborate some more? I get the feeling we are seeing two different problems and neither of us are able to understand "the other problem".

Running the site in a subdirectory is supposed to work, that is what the base_url handles, e.g. by setting...
$base_url = 'http://www.example.com/drupal';
...when www.example.com points to the folder above the drupal folder of the site.

If I would move this site so that www.example.com actually points to the drupal folder, I would just remove the $base_url setting and everything would be fine, but not if image paths are saved as "/drupal/sites/default/files..." instead of "sites/default/files...". That is my problem with IMCE returning the former instead of the latter.

ufku’s picture

Your paths are not working because they are hard-coded as html in your content.
The solution was! to use a special syntax such as [root]/filename.jpg in your content and implement a filter that converts the [root] strings to your current file directory before printing the content.

Unfortunately IMCE can't help you with this. It's just a file browser providing file-paths to various tools on request. It has to provide the correct full path and is not into what is done afterwards.

ufku’s picture

Please post new ones instead of editing your previous comments.

(retrying to explain your post's edited part):

let's assume IMCE provided "sites/all/files.." instead of "/drupal/sites/all/files..."

Then the image with src="sites/all/files/image.jpg" would resolve to

www.example.com/sites/all/files/image.jpg at your front page (no problem.path resolves correctly)

and it will resolve to

www.example.com/about-us/sites/all/files/image.jpg at your about-us page.(the path resolves incorrectly since it is a hard-coded relative path.)

As you see the only solution to this is to use a special syntax and a filter for that syntax.
You may have a look at inline module to see what i mean.

lejonsson’s picture


This is where I fail to understand your argumentation. You claim that the paths will not resolve correctly, but I have been doing like this for some time (editing and shortening the path given by IMCE for each picture) and it works just fine, src="sites/default/files/image.jpg" resolves just fine, independent of whether it is on the front page or in a page view. Note though; It won't work if I remove the $base_url = 'http://www.example.com/drupal'; setting.

So, what you are saying is that IMCE should give the server path because otherwise it will not resolve correctly in situations such as mine where the site is in a subfolder, but I mean that this is not IMCE's problem, it is a problem already handled by the ability to redefine the base url in case you are running in a sub folder. Modifying the settings file when moving the site is fine, but not having to modify all image paths saved in the database, IMHO.

lejonsson’s picture

To give an example:

On a site I am currently building, development site located in a subdirectory /~larsman/lejondans on the server www.ludd.ltu.se, I have an about page called "om" (swedish for about).

The picture on that page is included with a short relative path < img src="sites/default/files/pics/LEJON.JPG" width="512" height="384" alt="LEJon" / >, but it resolves correctly thanks to the base_url being set to http://www.ludd.ltu.se/~larsman/lejondans.

If you open the picture you will see it gets resolved to the correct path:

When moving the site to a deployment server, I simply remove the base url setting (making it default) and all pictures will still resolve correctly. Everything works fine, except that I have to edit all paths given by IMCE, which is a pity since IMCE otherwise works excellent (in my case in combination with BUeditor).

Is there a modification I can easily make myself to change the output from IMCE to get paths only as "sites/default/files..."?

lejonsson’s picture

Not being happy with us not understanding eachother, I have tested a bit and found that you seem to be right in principle, but the example you gave was not correct so it fooled me as it unfortunately also matched my setup (that I saw worked).

You claim that www.example.com/about-us/sites/all/files/image.jpg would be the (incorrect) resolution of the picture at the www.example.com/about-us page, which was similar to my case that I see work. The example you gave do indeed resolve correctly to www.example.com/sites/all/files/image.jpg, but not if the page had been www.example.com/pages/about-us, as the picture would then refer to www.example.com/about-us/sites/all/files/image.jpg.

So, you clearly has an unfortunate point here, although the example was invalid and fooled me (as well as my approach so far to have all pages with pictures using root paths, which works).

Thanks for your efforts to make this clear, I had probably got problems soon with picture links without knowing why things go wrong. I still do not have a good solution for the problem with developing on a server I can not control and thus can not avoid the site-in-subdirectory issue, but at least I got the point you were trying to make. Will have to think things through again then...

ufku’s picture

Status:Active» Closed (duplicate)

Good to see we made some progress.
Then, i'm marking this as duplicate of #199484: Relative Image Path [SOLUTION] as it's older.
You may post any further ideas there.

asiby’s picture

Guys, this is still a problem and it has not been solved. I have used a WYSIWYG editor on Joomla that was doing things properly. It was using the global configuration settings called $live_site_path (if my memory serves well) and remove it from any url while a content is being saved. And I believe that the same option must be made available (or is already available with all these WYSIWYG that we are using in Drupal). At least, if it can't be easily done in the WYSIWYG itself, then I will try to create a small module that can automatically add or remove the $base_path (as appropriate) in any content being saved. That should put this issue at rest.

I will come back with some updates soon enough.


Mark_L6n’s picture

Glad I found this post. When I upload a site from my local computer to my webhost, all is well except for the file paths to images within text content. The image is in the same, correct place (the directory specified by Admin->Configuration->Media->File settings 'Public file system path'), just the path is wrong. It appears that IMCE is passing the absolute path instead of a relative path to the editor.
It is possible to correct this path by hand at this point (i.e. change /drupal/sites/default/files/img.jpg to sites/default/files/img.jpg), but that is asking for errors from end users. (I haven't tested uploading to the webhost yet, though.) It would be much better to pass a relative path to the editor.
I am using Drupal 7, Wysiwyg, CKEditor, IMCE, IMCE Wysiwyg API bridge and HTML Purifier. I checked the IMCE module settings, and 'Absolute Path' is unchecked.

Mark_L6n’s picture

A little more info:

One thing to note about relative paths--they are relative to the page being viewed, which results in different relative paths being needed for a default Drupal node path (ex. drupal/node/8) and a URL-alias path (ex. drupal/info-about-us). In my 7.x setup, the following paths work in this way:

./sites/default/files/ or sites/default/files/ works for a URL-alias path and also the WYSIWYG editor
../sites/default/files/ works for a default Drupal node path (ex. drupal/node/8)

So there's another reason to always use URL-aliases.

At http://drupal.org/node/1108216 is a proposal to add a relative path option to IMCE.

akki123’s picture

The solution was! to use a special syntax such as [root]/filename.jpg in your content and implement a filter that converts the [root] strings to your current file directory before printing the content.

Though after three years. I unable to resist my self to post a comment for this.
We use CMS ( drupal ) to achieve simplicity for complex things.
You are advising a complex solution for such a simple thing which should be there from start.

It echos the absence of copy function on iPhone and then latter Apple can make such a general function a feature. Though not the good analogy but it should express my views.

johnquillen’s picture

Just in case others hit this page as I did after moving their site - be sure and clear your cache!

I thought I had this same problem - after moving my site from my desktop to my hosted site. My images were all using relative paths and I could not for the life of me figure out where the paths to my old site were in the configuration - until I looked at a dump of the database and searched for the old site path... and found that the line in the dump started with INSERT INTO `cache` VALUES ....

Bent Aarup’s picture