It would be nice to have the ability to split the 'files' directory for different subdomains.

However, the issues reported at http://drupal.org/node/197692 made me drop this feature from the first release.

Comments

hi, ken, thanks for posting on this.. it was nice to find that you guys are trying to make this work.. is there any motion on it lately? Especially for version 6.x? (I see this issue is for 5.x currently).. or is this a feature now of 6.x (though if so I can't find it :P )?

i believe skizzo's original post (at #197692: File system cross references ) looks similar to the configuration i use, but just in case it's not, here's another use-case:

we are a multi-department school which uses Drupal for several Domains/sites (anthropology, sociology, economics, etc.), and we use FlashNode (http://drupal.org/project/flashnode) and IMCE (http://drupal.org/project/imce) to store flash objects and images respectively for each separate site (we have one common/shared database, of course) .. and it would be nice if

a. the Domain module itself kept track of different file root locations ("file_directory_path" variable?) for each site, and

b. content-types -- images, flash objects, pdfs, etc. -- could be registered with the Domain module as being stored in specific sub-directories of the above-mentioned root, also stored as variables on a site/domain basis. for instance:

DRUPAL/files/
     site1/
          images/
          flash/
          pdf/
     site2/
          images/
          flash/
          pdf/
     ...

so, when the site1 author wants to upload an image, the IMCE window shows "files/site1/images" as the starting point in the IMCE file browser window. (because IMCE would be aware of the Domains-Configuration setting for this content type). Or, if they wanted to upload a flash file, the IMCE window would show them, "files/site1/flash" as their starting point.

c. alternatively, if they wanted to, admins could decide to organize their files by content type, rather than file type. for instance: working-papers, biographies, published-articles, resumes. such as:

DRUPAL/files
     site1/
          working-papers/
          biographies/
          published-articles/
          resumes/
          ...
     site2/
          working-papers/
          biographies/
          published-articles/
          resumes/
          ...

so in this case, the sub-directory variables for images, flash, pdfs (b., above) would be allowed to be set to empty, so that, for instance, when the site1 author pulls up an IMCE upload window to upload an image, the IMCE window shows just the basic "files/site1/" starting point, and still allows the author to navigate down and put the image into any subdirectory of the root file_directory_path. (but in this case, the author has to be more intelligent, and not put stuff where it shouldn't be.)

d. other modules (Flash, IMCE, others) could be made to be Domains-Access and Domains-Configuration aware, and by that I mean that they could both set and get the values for these root file_directory_path (a.) and content subdirectory (b.) variables.

---

is this anywhere near along the lines of what you were planning? ..and if so, i was just wondering what the status was (for 6.x)?

thanks!

(oh, FYI, i filed earlier today, a feature request for FlashNode (#305585: IMCE or Domains support? for better folder organization) before I realized that the ball might be more in Domain-Access's court right now..)

Version:5.x-1.0beta7» 6.x-1.1

I do not believe that Drupal's current core file handling will support what you need.

I am also not working on new features until #298696: * ROADMAP * Please read this first is finished.

All new features are for D6, and then may be backported to D5.

thanks ken. appreciate the fast response.

okay, my wishlist for D7 (in the File13 department :P )

1) Domains built in to the CORE, so that by default all installations of drupal are *assumed* to be able to be multi-site/domain. and all variables (including any variables set by modules) must be set per Domain.

2) oh yeah -- and better core file-handling. :P

yeah, baby, yeah. :P

Yeah, wish #1 is not going to happen. Domain Conf already handles variables set per domain.

Core file handling, see http://groups.drupal.org/file-api

Yeah, wish #1 is not going to happen. Domain Conf already handles variables set per domain.

yeah, bummer. but, as far as i can tell, Domain Conf only splits out some variables:

  - Name [of site]
  - E-mail address
  - Slogan
  - Mission
  - Footer message
  - Default front page [untested]
  - Anonymous user
  - Default time zone
  - Site status
  - Site off-line message

But this is not a complete list of variables used by each site. And this list is not extensible by an end-user/drupal-admin, right? I mean, i cannot see how i would "add" a variable to Domain Conf, such as file_directory_path (the problems with Core file-handling notwithstanding). I mean, to add variables, that has to be done at the developer level, right? or am i missing something?

This list is extensible through code, using hook_domainconf(). See the API.php file in the download.

Doing that through the UI would be extremely difficult, because of how variables are set.

You can integrate with IMCE, by creating a new IMCE profile and assigning it to the roles with 'edit domain nodes' permission

Then in the settings for that profile, in the 'directory path' column in the Directories table, you can enter php code that will get the permissions from the domain

Example 1:

php: global $_domain; return $_domain['subdomain'];

This basically just gives you permissions over files/{subdomain name}

Example 2:

php: global $_domain;
           if(strpos($_domain['subdomain'],'.')<=2){
                    return substr($_domain['subdomain'], 0, strpos($_domain['subdomain'],'.') );  }
           else {   return 'Members/'.substr($_domain['subdomain'], 0, strpos($_domain['subdomain'],'.') );  }

This is just to show how you can play around with it - here we have a usecase of 2 kinds of domains - country domains where the third level is the 2 letter code (e.g ie.domain.tld) and user domains (e.g nirbhasa.domain.tld). Here, the code checks if the first part of the domain is 2 characters (i.e. if it is a country domain), if not it puts the user folder under a 'Members' folder. So if I am editing the country domain ie.domain.tld I have permissions over files/ie, but if I am entering content for my own personal domain nirbhasa.domain.tld then I have permissions over files/Members/nirbhasa (In this case, obviously you would have to do more to deal with fourth level domains)

One advantage of integrating with IMCE is that you can have browse permissions over the entire filesystem, but upload and delete permissions only on the domain directory.

It does mean that you have to be on the domain you are posting content for, but you can work around the 'Create content' links on your site to ensure that happens.

Any idea about when it could be planned in future and if on D6, D7 or over?
Waiting for it, the best way will be to prefix or postfix filename with name of domains, right? Or which other ways could be better to not have caos mixing many files uploaded for many domains?
I see that logo is stored in different folders, giving the id number per folder, example: sites/default/files/domain-6/ so in the same way of logo, we cold simly upload also other images per domain, or it is then more hard way?

File names are not the problem. File paths are the problem.

Drupal 6 stores the path in the {files} table, so you cannot switch active $files paths on the fly. Using tokens for filefield is the only real solution for D6.

With the D7 revamp of the file system, this may be possible.

Maybe this module could be useful in some way? http://drupal.org/project/uploadedfilesmover

If there was a token provided, then FileField Paths would be able to do this no problem. If there isn't a token provided, you could probably use Custom Tokens to define your own.

Token is a required module for FileField paths , it mean that it would be able to solve this problem?
Plus Recommended Modules:

* ImageField Tokens
* File Aliases
* Pathauto
* Transliteration

There are domain tokens provided in 6.x.2. See section 7.6 of README.txt

Was missing subject in your message and I was readng readme.txt of al modules, now I know!
From yesterday wit domain access module is possible to do what this issue was asking for, super!
I run now to upgrade, I hope now we can close this issue ticket.

yeah, the token way sounds like a great way of doing it, although we ended up using nirbhasa's method and IMCE (as i also mention in post #7 of #305585: IMCE or Domains support? for better folder organization). in our variation, we made nirbhasa's PHP code into a function called get_folder() included in the Directory Path from an external location:

php: include ("local_includes/get_folder.php"); return get_folder();

where the function get_folder just strips off any ".com" or "www." and returns only the "core" of the domain name (e.g., "example1") so we get file directory names of "files/example1" instead of "files/www.example1.com".

also, having the "get_folder()" function in an external place makes it useable in other places in drupal where we needed the "core" domain name.

On one of our sites we also needed domain name based file paths. We solved the issue by implementing hook_domainupdate with $op = create calling a custom function (see blow). This way whenever a new domain is added it's also created in the filesystem. In our case the dependencies were imce and imce_mkdir.

function _helper_domain_directory($domain) {
  $subdomain = explode('.', $domain['subdomain']);
  $folder_name = $subdomain[0];
  $dirpath = file_directory_path() .'/images/'. $folder_name;
  $error = FALSE;
  if (file_exists($dirpath)) {
    drupal_set_message(t('Subdirectory %dir already exists.', array('%dir' => $dirpath)), 'error');
    $error = TRUE;
  }
  if (!file_check_directory($dirpath, FILE_CREATE_DIRECTORY)) {
    drupal_set_message(t('Subdirectory %dir could not be created.', array('%dir' => $dirpath)), 'error');
    $error = TRUE;
  }
  if ($error == FALSE) {
    drupal_set_message(t('Subdirectory %dir has been added.', array('%dir' => $dirpath)));
    // Grant permissions to this newly created directory if imce is enabled
    if (module_exists('imce') && module_exists('imce_mkdir')) {
      $profiles = variable_get('imce_profiles', array());
      // Only has two profiles - user 1 and producers
      $producer_profile = $profiles[2];
      array_push($producer_profile['directories'], array('name' => 'images/'. $folder_name, 'subnav' => 1, 'browse' => 1, 'upload' => 1, 'thumb' => 0, 'resize' => 0, 'delete' => 1, 'mkdir' => 1, 'rmdir' => 1));
      $profiles[2] = $producer_profile;
      variable_set('imce_profiles', $profiles);
      // IMCE uses caching so we need to clean the cache
     cache_clear_all();
   }
  }
}

Status:Postponed» Closed (won't fix)

Version:6.x-1.1» 7.x-3.x-dev
Status:Closed (won't fix)» Needs review

With the improved way that Drupal 7 handles files, I've created a module that allows for better organization of site files in a multidomain setting: http://drupal.org/sandbox/markwk/1715824 or https://github.com/markwk/domain_files. I'm not sure if this is something that could be incorporated into the Domain module suite or as a separate module. Posting here for discussion and review...

Likely separate. I'll want to review.

I see. That module just works with private file downloads? I don't know if that's the use-case most people are after. They want separate files per domain in the admin UI.

Not per se. It's using Drupal 7 file structure so essentially you can use it for either. It might be currently hard coded for that (I'll need to check) but the functionality is aimed at something more general as in a path token.