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 " />.
Comment | File | Size | Author |
---|---|---|---|
Add-base-relative-path-for-file-URLS.patch | 6.3 KB | drikc | |
imce_base-relative.jpg | 27.46 KB | drikc |
Comments
Comment #1
drikc CreditAttribution: drikc commentedOups, 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:
Comment #2
ufku CreditAttribution: ufku commentedIf you define base href how do you think all other relative URLs be affected in your site?
Comment #3
drikc CreditAttribution: drikc commentedI 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.
Comment #4
Mark_L6n CreditAttribution: Mark_L6n commentedThis 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)
Comment #5
ufku CreditAttribution: ufku commentedThis 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.
Comment #6
drikc CreditAttribution: drikc commentedIt'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).
Comment #7
Mark_L6n CreditAttribution: Mark_L6n commentedSo 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?
Comment #8
ufku CreditAttribution: ufku commentedThe 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.
You may have a look at virtual host definitions. You can define http://example locally for developing http://www.example.com
Comment #9
Mark_L6n CreditAttribution: Mark_L6n commentedThanks 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?
Comment #10
ufku CreditAttribution: ufku commentedA 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.
Comment #11
drikc CreditAttribution: drikc commented... 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.Comment #12
Anonymous (not verified) CreditAttribution: Anonymous commentedsubscribing
Comment #13
molnitza CreditAttribution: molnitza commentedIs there a currently working version of the patch?
Comment #14
palamida CreditAttribution: palamida commented"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!
Comment #15
dankoB CreditAttribution: dankoB commentedsubscribe
Comment #16
Zorkoff CreditAttribution: Zorkoff commented"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."
Comment #17
dpl CreditAttribution: dpl commentedI 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!)