In a multi-site install, if I want separate 'files' directories, I have to put up with paths like this for my links:

http://example.com/sites/example.com/files/filename.ext

instead of the much preferred

http://example.com/files/filename.ext

This results in unnecessarily long, redundant and odd looking paths. It also forces us to have to manually enter a file system path for each different site, which hampers site portability, setup automation, and synchronization.

Surely there is a way to use mod_rewrite to shorten these paths. Something like:

RewriteRule ^/files/(.*)$ /sites/%{SERVER_NAME}/files/$1 [NC]

That way we could just leave 'files' as the default File system path in settings, and everything would work.

Comments

Tresler’s picture

Been meaning to look into this for a while. If a solution doesn't post soon I'd be interested in helping to find one.

Sam Tresler
http://www.treslerdesigns.com

pobster’s picture

If you just set up your multisites to share the 'main' themes and modules directories instead of all being hidden up inside the sites folder with loads of duplicate files everywhere then yes, you can simply have each multisites files folder sat neatly in your base directory; accessible via http://www.yoursite.com/files

Pobster

schwa’s picture

It's not that simple, Pobster - in the multisites I work with we need the ability to port one site discretely, which is impossible if all content files are mixed up together in a main 'files' folder. I'm also interested in a solution for easier multisite filepath setup.

pobster’s picture

Erm, *cough* you do know that you don't have to call your files folder "files" don't you? If you call each of them something different then you won't mix up your files!

Pobster

Tresler’s picture

I use multisite capability for a number of things. Inside my sites folder I keep 3 folders. files/ themes/ modules/

I use this to dev many sites at a time and control seeral teams of developers. So by keeping them completely seperate I maintain a level of security. Team A only has FTP access to site A. Granted it isn't a huge level of security, but it keeps devs from accidentally writing over someone else's stylesheet and not being able to fix it.

2 other issues. First When a site is done I create a CD backup or it and port it to the clients server. This is much easier if I can download Drupal 4.7.3 and add the sites/ folder, backup the DB and tar it all. As opposed to picking and choosing which modules I want, pulling the right theme, etc, etc.

Also, CSS paths are absolute. And the big isue to me is that the domain name needs t be written out twice. I actually have a URL that looks like this in several locations in a stylesheet.

http://xxxx.treslerdesigns.com/sites/xxx.treslerdesigns.com/files/images...

That's a little silly.

Sam Tresler
http://www.treslerdesigns.com

Tresler’s picture

Its apparently too long for drupal.org

Sam Tresler
http://www.treslerdesigns.com

pobster’s picture

I assume you're a Windoze user then? In this new os called 'Linux' we have an *amazing* new thing called symbolic links ;o)

Heh sorry couldn't resist! So... to reiterate - your users modify themes and such as well as their own files? Just trying to think of other options open to you...

Pobster

Tresler’s picture

I'm am both a windows and Slackware user, plus my current server is on RH. I know ln -s It's how I get my subdomains to point at drupal root.

Maybe I'm being dense but how does that help in this situation. At the very least, please elucidate the forum so people who aren't as smart as you ;) can know.

At any rate... symbolic links for 100+ sites is an extra step I'd rather have drupal take care of if we can rethink this a little. Also, it prevents porting sites developed on a Linux OS to Windows (not that I would EVER want to do that, but I can't acount for all my client's absurdities) Its good to keep things portable acros platforms with just APAHE, PHP, and MySQL - without too much in the way of server dependencies.

Sam Tresler
http://www.treslerdesigns.com

Tresler’s picture

More seperate Dev teams working on the same drupal codebase.

Sam Tresler
http://www.treslerdesigns.com

pobster’s picture

Well with the symbolic links I'm thinking that you can simply have a linked folder in the Drupal root which points to your actual files folder located within your sites folder. Then you can still sandbox your users into their 'home' directories.

So for instance, if you have:

http://xxxx.treslerdesigns.com/sites/xxx.treslerdesigns.com/files/images...

Then create a symbolic link like treslerdesigns in the root, pointing at that files directory so you can access that jpg via:

http://xxxx.treslerdesigns.com/treslerdesigns/images/background_front.jpg

That's what I'm thinking... Else... I'm thinking it'd be dead easy to pick up 'files' from the url and have a module 'serve' up files... Depends on your requirements really...

Pobster

Tresler’s picture

I'll think on the module idea. Problem is it's not just the files directory that needs to be routed. As someone pointed out it doesn't need to be named 'files' that folder is set under settings. Also, a solution should take into account the themes and modules directories too.

Also, absolute URL's in CSS aren't parsed through drupal so it might be harder(?) to catch a URL coming from a stylesheet (I have no idea?)

Sam Tresler
http://www.treslerdesigns.com

schwa’s picture

Hi Sam,

Sounds like I have a similar developmental set-up as you. Is there any reason your CSS paths have to be written as absolute? I've found it much easier, for portability, to use relative paths with an images folder (if necessary for the theme) right there in the subsite's theme folder. That might eliminate that problem for you?

Tresler’s picture

Opera, at least last I checked, renders relative paths from the location of the CSS file. Others rener it from the location of the calling file. I don't have a full list of all browsers but I was always under the impression that unless index.php and your css were in the same directory you should always use absolute paths when calling images into a CSS file.

See: http://gallery.menalto.com/node/32853

also w3C says it should be off of the style sheet "For CSS style sheets, the base URI is that of the style sheet, not that of the source document." here: http://www.w3.org/TR/CSS21/syndata.html#uri

But here: http://lists.evolt.org/archive/Week-of-Mon-20020304/105595.html
is this "As you (should) know, relative paths in a globally LINKed stylesheet are
normally relative to the location of the css file, however are taken as
relative to the document location in NN4."

Now, I could eliminate the http://_ treslerdesigns off the front(as I just learned) by writing this. Iintentional '_ ' to prevent linking)

/sites/treslerdesigns.com/files etc, etc. which helps, alot and is still an absolute path with the beginning slash.

Perhaps it is just NN4 that does this? In truth I was taught to always use absolute paths in CSS image referencing and have never really questioned it.

Sam Tresler
http://www.treslerdesigns.com

schwa’s picture

Erm, *cough* you do know that you don't have to call your files folder "files" don't you? If you call each of them something different then you won't mix up your files!

Yep, but that just returns to the main point of the OP: how to automate the creation of all those separate file directories (whatever their names) & corresponding filepaths for each of dozens of discrete subsite installs.

Tresler’s picture

Credit to the Dev list.

My theme is in sites/example.com/themes/themename/

The style.css file will automatically be picked up by the
phptemplate theme engine if it is in the themename directory.

Images referenced from the style.css will be picked up if
they are relative too:

list-style-image:url(images/menu-leaf.gif);

and

If you really want to embed images, css, or js files in your tpl.php
file (which I try to stay away from) then use you can use the
path_to_theme() function which will make it portable.

and for the original post about the files directory That indeed can be located at the root level, symlinked to, or shortened by eliminating the first http: //webroot.com/sites/example.com/files to /sites/example.com/files - which isn't nearly so bad.

Hope that helps people, it helped me.

Sam Tresler
http://www.treslerdesigns.com

KMNL’s picture

anyone get this to work as the op requested, using mod_rewrite?

Zach Harkey’s picture

SIgh.

I was searching for the answer to this exact problem when I ran across my own thread from a year ago that I forgot I even wrote. SInce it's been over a year, and the original question remains unanswered, I figured I'd fire off a hail mary............................... bump.

-zach
--
harkey design

: z

pobster’s picture

Why don't you make your filesystem private (even if it is viewable, doesn't matter) then Drupal will always serve up files with .../system/files/... no matter which site you're on. It makes things run a bit slow if your server is pants, but it works fine.

Pobster

Zach Harkey’s picture

Performance and compatibility. I have had a lot of trouble in the past with the private filesystem. Can't remember which, but several modules balked at it, and with large galleries and several hundreds of thousands of images on a high traffic site, it really did cause a performance issue. See my earlier thread re: 'private' download method being more CPU / database intensive than public (especially for pages with many images).

But you do have a good point in that it can — and is — being done. I wonder if there is a way to borrow part of the 'private filesystem''s method of rewriting the paths without incurring the extra overhead.

-zach
--
harkey design

: z

pobster’s picture

Absolutely yes! But you'll have to be very careful with things like that to not leave security holes.

As another example (on perhaps a speedier way to do it with a file serving files) check out my logotool module. It only serves images, but it's fairly secure and quite easy to follow.

Pobster

SeanBannister’s picture

I agree this is something that is greatly needed! I also need to use public but have shorter paths to the files.

charmer’s picture

Is this issue resolved yet? I also think paths to files in multisite installation are awkwardly and redundantly long. Or is the only way to use rewrite rules?

Christopher Herberte’s picture

Does anyone have a working solution for this?

Subscribe

kmillecam’s picture

I, too, am looking for a solution to this problem.

My clients don't understand the logic behind having to add /sites/www.theirdomain.com/files into the paths of images they want to link to.

Subscribing.

http://www.webwiseone.com
It's all about community.

https://bkjdigital.com
We make magic.

starlilyth’s picture

From http://drupal.org/node/53705 :

Files Directory
The following user-submitted code may be useful in redirecting URLs for the /files directory to the /sites/example.com/files directory. The following code is added to the [drupal_root]/files/.htaccess file:

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /sites/%{HTTP_HOST}/files/$1 [L]

This worked perfectly for me in my multisite install, and it seems pretty painless to try to remember one (more) directory and file creation step each upgrade, compared to some other possible solutions.

Lily

Matti303’s picture

thanks starlilyth works great : )

it just took me a minute or two before realizing I had to create a "files" directory within the drupal root containing the .htaccess file

beautiful solution !!

Matti303’s picture

One little issue remains now, in FCKEditor, images linked to /files/image/image.gif appear broken. They only appear broken within the editor, pretty obvious as the editor does not use the new .htaccess file. In the browser, all images are displayed.

ariachitect’s picture

Thanks a lot! Seems to be a good solution.

I just wonder what is your file system path (in Home › Administer › Site configuration › File system)

When I set it to 'files' it doesn't work for me.

vojnar’s picture

This is the variable to files on multi site install:

echo $base_url."/".conf_path()."/files";

Keywords: multi site base url, path to multi site, path to sites

himdel’s picture

It's IMHO much easier to use mod_alias for this, just add
Alias /files /etc/drupal/6/sites/DOMAIN/files
to the virtualhost section (with DOMAIN replaced accordingly).
Plus, it works.

himdel’s picture

Plus, if you have such config and don't want IMCE to give you paths like /sites/DOMAIN/files/..., you can edit /usr/share/drupal6/modules/imce/js/imce_set_app.js, function appFinish to this:

var appFinish = function(file, win) {
  var doc = $(appWindow.document);
  for (var i in appFields) {
    var r = file[i];
    if (i == 'url') {
      r = r.replace(/^\/sites\/[^\/]+\/files\//, '/files/');
    }
    doc.find('#'+ appFields[i]).val(r);
  }
  if (appFields['url']) {
    try{doc.find('#'+ appFields['url']).blur().change().focus()}catch(e){};
    try{doc.find('#'+ appFields['url']).trigger('onblur').trigger('onchange').trigger('onfocus')}catch(e){};//inline events
  }
  appWindow.focus();
  win.close();
};

(the key is the if (i == 'url') { r = r.replace(/^\/sites\/[^\/]+\/files\//, '/files/'); })

Streamweaver’s picture

Has anyone tried using the approach along with the pathologic module? It sounds like a very good fit.

jmroth’s picture

A pity there still is no real official solution this.
None that I can find, I mean.
-.-

AshokanKid’s picture

I have to heartily agree. We have over 20 sites (and growing) in our Drupal multi-site install directory. Each unique site folder then has a (default) folder called simply "files", which would be where that specific site / domain would store it's files. We would also like to create other folder / directories that can be used by the specific site / domain for other site specific files, like JPGs, media, PDFs, etc., etc..

Most previous "solutions" are complex and convoluted (for me at least) and still do not address the fact that we want each site to operate EXCLUSIVE of any other site. In other words, NO URL info of the base site within ANY of the file access URLs. I mean, what is the point otherwise? Might as well just use a general onlline shared repository server and absolute http path then.

If anyone has a solution to this (apparently) age old Drupal issue, please let us know. Again, a REAL solution must allow simple specific site file folder access from a simple URL that could be an embedded media file in a web page to a JPG to a downloadable PDF book, etc., etc.. This should not be Rocket Surgery as Drupal Multi-site has been around for a long time now, yes?

P.S. Well, perhaps I griped too soon and I figure that this was probably suggested or mentioned earlier in this (or other) post(s) about this issue.
What I just did that at least allows me to embed doanloadable media content (my current and most pressing issue regarding my multi-site installs) is this;

For an embedded piece of media content that is stored in the (default) specific site domain "files" directory, I used this absolute URL format to access the directory;

http://SiteName.com/sites/SiteName.com/files/MediaFile.xxx Where SiteName.com is the specific site domain name in the multi-site install, "files" is the default folder name within that site directory and MediaFile.xxx is the specific media file located within that "files" folder.

Not necessarily pretty or perhaps even the most elegant solution, but if one creates a nice looking HTML link ( A HREF="http://SiteName.com/sites/SiteName.com/files/MediaFile.xxx" > Your Media File /A> Which turns into Your Media File ), this makes it at least look nicer to the end user visiting the site.
(I left off the opening

Branjawn’s picture

sub

tronathan’s picture

Subscribing, Seems like its still an issue in Drupal 7 and maybe Drupal 7.

Filefield and node content store paths relative to the root, so a module that updated these paths would be a reasonably good solution, I think.

The ideal solution would be to never store relative paths to files directory and instead store it in a single location. Files (filefield) table and node content (node, node_revisions, cck, fields etc) would store paths relative to the FILES directory, never relative to the BASE INSTALL directory.

tronathan’s picture

Just checked, fixed brilliantly in D7:

This is fixed in D7.

https://img.skitch.com/20110510-bxg1b45656aak3ji77ei1kk7ek.png