IMCE can actually return file URLS into two manners:
1. root-relative: drupal_root + a_public_path (ie. /drupal/sites/default/files/)
2. absolute: protocol + host + drupal_root + a_public_path (ie. http://localhost/drupal/sites/default/files/)

Then it can happen that some contents in db hold some of those paths which is perhaps something someone don't want if you change the site host or drupal_root.

By adding the the following file URLS type it would be possible to avoid having 'host' or 'drupal_root' path elements returned by IMCE:
3. base-relative: ./ + a_public_path (ie. ./sites/default/files/) which require the use of the tag " />.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drikc’s picture

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

Oups, the last line of the description issue should be:
3. base-relative: ./ + a_public_path (ie. ./sites/default/files/) which require the use of the tag:

<base href="http://<host><drupal_root>" />
ufku’s picture

If you define base href how do you think all other relative URLs be affected in your site?

drikc’s picture

I will know that relative URLs will be against the base href which will be set to the drupal installation path.

Well, it was just a proposition to have the possibility to allow IMCE to return file URLs free of host or drupal_base elements.

Mark_L6n’s picture

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

This is very important. Currently, when a Drupal installation is migrated from development/staging to production, the file paths provided by IMCE don't work (when, as often, there are different paths to the drupal installations.)
One thing to note above in the description: both of those paths are absolute--1) is for the file system (it begins with a / and so is absolute), and 2) is for http protocol.
For migrating Drupal installations (which pretty much every non-trivial site needs to do, so I changed Priority to 'major'), we need relative paths.
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)

ufku’s picture

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

This is not specific to IMCE. It's a general issue with using hard-coded file paths in content.
The common workaround is to prefer a sub-domain instead of a sub-folder for development environment.

drikc’s picture

It's just about adding an option beside the two existing which then would permit to fill more use cases (the sub-folder development environment is not the only one).

Mark_L6n’s picture

So ufku, you're saying we need to provide the exact same file paths in development and production environments?
What about local development systems (on MAMP, XAMP, DAMP)?
Why would you not want to add as an option something simple such as drikc is proposing for relative paths?

ufku’s picture

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

The URL pattern that IMCE uses is the correct one. You can always override imce.getURL js method to change this pattern for any purpose. It can even be done in script.js of the active theme.

What about local development systems (on MAMP, XAMP, DAMP)?

You may have a look at virtual host definitions. You can define http://example locally for developing http://www.example.com

Mark_L6n’s picture

Thanks for the pointer, ufku.
I assume that the reason you don't like relative paths is what I alluded to above--that paths are relative to the page being viewed, so a relative path would point to different places from a drupal-node-number path (e.g. drupal/node/8), a URL-alias path (e.g. drupal/info-about-us), or the front page, if the article were promoted to the front page. Is that correct?
A solution one would think of is to concatenate a drupal path variable to the file path. For ex. $drupal_base_path = /path/to/drupal could be concatenated with /sites/default/files/image.jpg.
I'm guessing you can't do that because of the modular setup--IMCE may need to return HTML to the editor, and can't include a variable. Is that a good guess? Have you ever discussed with the Wysiwyg module people a way of passing a drupal-path-variable + file-path structure back, so that a correct local path could be generated when page data is pulled out of the drupal db?

ufku’s picture

A special token(e.g [root]) for the directory root can be prepended to the returned filepath, but this is not about WYSIWYG integration. You'll need an input filter that replaces the token with the root path while viewing the content. You'll need a custom module to do this. And with that custom module you can also hook into IMCE to change the imce.getURL function to make it return the filepath prefixed with root token.
Note that previewing won't work for the filepaths with the root token.

drikc’s picture

... so a relative path would point to different places from a drupal-node-number path (e.g. drupal/node/8), a URL-alias path (e.g. drupal/info-about-us), or the front page, if the article were promoted to the front page. Is that correct?

This is resolved by using the <base href="http://<host><drupal_root>" /> tag that tell any relative paths to use that base regardless of where you are in the URL-path and also previewing work with that setup.

Anonymous’s picture

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

subscribing

molnitza’s picture

Is there a currently working version of the patch?

palamida’s picture

"sites/default/files/" public file system path is stored in fild_data_body table with every image uploaded in the body field...
when moving the site to a multisite localhost environment I find impossible to get the images

the public file system path is not considered!

dankoB’s picture

subscribe

Zorkoff’s picture

"Pathologic is an input filter which can correct paths in links and images in your Drupal content in situations which would otherwise cause them to “break;” for example, if the URL of the site changes, or the content was moved to a different server."

dpl’s picture

I subscribe.

My "workaround" is to change every path after uploading and insert the [site:url] token before the sites/all/... path.
This works so far (together with the module token filter) but obviously is not comfortable at all. But still better than having all the paths hardcoded as I work on localhost and will have to migrate the website soon.

A future possibility to do something like this automatically would be important and appreciated!

(I might try Pathologic, thanks Zorkoff!)