Relative Image Path

imce does return relative paths. however if you use the path to create an image on the fly and then read its src, then it will give you the absolute path. are you doing something like that?

Hi ufku.

I'm not really sure what you mean. I just call the IMCE over the TinyMCE. Choose an Image and click on "add". Than it gives me the absolute path. I add you a screenshot.

Ok, the path /svn/xx/drupal3/files/x.jpg is not the "real" absolute path which is of course sth. like http://localhost/svn..
But it's also not the real relative path, which is /files/x.jpg.

thanks for every hint.

You are aware that ANY path beginning with a / is not a 'real' relative path at all?
That always means "from the root of the server" .. not the subdirectory you happen to have Drupal in.

But IMGE, and the browser, have to know what the real path to the image is, and in this case it is that deep in your subdirectories.

There is a bigger issue, that I've not yet seen resolved about linking to files this way, so I know what you want, but AFAIK, there are no WYSIWYG editors that can do the 'right' thing here.
You are probably finding it makes it a pain to develop test sites in subdirectories :-). Yup. Explore making some subdomains or alternative http ports if this is a problem for you.

Maybe img_assist will do it, as it has the ability to repair links on the outgoing filter, rather than embedding them as HTML like your wysiwyg does.

Ok, sorry for my bad knowledge about real and unreal relative paths :-)

And you're right. Developing in subdirectories might be not the best practice, but I think most of us do it..without setting a subdomain for every project. And it's definitely worst case, if the "unreal" relative path is written in the database.

In my CCK-module I fixed that problem with the following code:

Do you see any disadvantages of this code? If not, maybe that's something to improve IMCE?

I agree that saving the full path (server-relative) in the DB is a problem. Even an annoying design decision.
I wish it didn't, but the work-arounds to 'correct' the problem for embedded links and src in the text are messy. CCK etc is OK to do that to because the file path sits on its own and can be tweaked. For IMCE however, you'd need regular expressions etc - to put the full path in on edit, take it out on save, and put it in again on view. Ick.

I agree you should be able to safely develop in subdirectories, it's a bit of a problem.

now it's clear.
Considering IMCE as a file browser used by WSYIWYG editors, yes there is only one choice for IMCE, which is to return the server-relative path. The real relative path may work but only in the main page of the site(i mean the path "file/x.jpg" works in http://domain but not in http://domain/node/1).
and mhuebl, while handling file paths you should consider the private download method which converts file paths to /system/files/(path relative to the file system path). And if clean urls is not enabled the file path will be something like /?q=system/files...
as a result the returning path would start with url('system/files') OR basepath().file_directory_path() depending on the file download method, and the rest is safe to save in db for reversing this process to create the file URL.

I have a similar problem when I converted my test site from Drupal 5.3 to 5.7. See http://drupal.org/node/227800

Maybe I am not understanding the above thread, but I don't see a solution for this. What should one do? thanks for your attention to this.

Hi ufku, are you sure about this:

"Considering IMCE as a file browser used by WSYIWYG editors, yes there is only one choice for IMCE, which is to return the server-relative path"

If you use TinyMCE, say on a page like http://domain/?q=node/1/edit, and upload/add an image with IMCE, it returns the server-relative path into the "Image URL" input field as you would expect. If you then manually edit this path, removing everything up until "files/", and then press the "Insert" button, TinyMCE still inserts and displays the image correctly. So that seems to suggest that there is no problem returning a real relative path to TinyMCE.

There is no problem using a real relative path on other Drupal pages as well. For example, if you use the theme_image() function in a template, which is generally good practice anyway, the real relative path works fine because of this line in that function:

$url = (url($path) == $path) ? $path : (base_path() . $path);

This is why I have been modifying the output from IMCE to create real relative paths from the server-relative paths because they are far more useful to me in this format. It seems this is the case with others too.

By the way, thanks for all your work on this module. It's really very useful and I'm sure a lot of people appreciate your work.

yes, you are right only if the clean urls is not active.

what if you decide to use clean urls in future?

"files/foo.jpg" works in "/?q=node/1/edit" but not in "/node/1". on the other hand,
"/files/foo.jpg" works in both pages.

That's why IMCE must return a server-relative path in order to keep consistency between clean and non-clean urls.

The future is here now ;) I just tested it with clean urls activated and it works fine with TinyMCE. Tested in both Drupal 5.3 and 5.7.

The reason being that TinyMCE automatically converts the real relative path into a server-relative path when you click the "Insert" button on the "Insert/edit image" popup. You don't need IMCE installed to test this - just type a valid relative image path like "files/foo.jpg" into the "Image URL" text input field of the "Insert/edit image" popup and click "Insert". As far as I can see there's no problem with the IMCE module returning a relative path to TinyMCE. As I mentioned before, theme_image() automatically adds base_path() to relative paths when necessary as well. Doesn't seem to work with FCKEditor though but I've just submitted a feature request with them to add this behaviour as I think it's a good idea regardless - it's very confusing to new Drupal users to know when to write "files/" or "/files/".

Hi, not sure if this is relevant but when I select a photo from the server I would like to IMCE to return /images/xyz.jpg instead of what it currently does: /sites/all/files/images/xyz.jpg (using D6).

I have created a symbolic link on my filesystem so that /images links to the above directory.

Is there any way I could set this up?

Thanks

Symlink sounds like a good first half of a solution.

Did try adjusting the imce browse root to point at your new symlinked path? You may need to apply this to the /files dir, not just /files/images

Thanks but where do I adjust the imce browse root?

I think I'm sort of hijacking this thread with something that is not sufficiently related. So I created a new issue for my query instead: http://drupal.org/node/269250

Hi. I'm also facing the same issue than Michael (mhuebl). Moving the site from a development configuration (in a subdirectory) to the hosting server breaks the images links.

Is there any work around for this issue?
Thank you.

Same here...

I also find this very irritating, now I have to edit the path returned frpn IMCE and remove everything above "sites/default/files..." (in my case I get "/~userfolder/sitefolder/sites/default/files..."). If I do not edit the URL, the server-specific path will be saved and that makes picture links fail when moving the site to an other server with a different server-specific site path.

"This is why I have been modifying the output from IMCE to create real relative paths from the server-relative paths".

Can you explain how you have done that, of have you just done it by hand for each image path?

More discussions and closures in http://drupal.org/node/448240

Please test this patch (http://drupal.org/node/540694) if you want relative path (and use pathologic module to avoid any paths problem in content)

With Pathologic, the problem with not being able to properly resolve true relative file paths goes away. Then I believe the case we have made about IMCE is still valid, and the above patch provides an excellent solution which I think should be made part of the official IMCE.

Hi,

Could someone explain why I get absolute URLs when using FCKeditor with IMCE in Drupal 6? Where is the problem -- in FCKeditor? I have chosen not to use absolute paths in IMCE.

FCKeditor seems like the best working companion for IMCE, but the absolute URLs are really an issue, and using Pathologic module just for reinterpreting them seems pointless if there is another way.

Thanks.