Media Browser tokens do not work for uploading private files (to directories specified by tokens that don't exist yet)

there's a file_entity patch that allows token configuration for upload directory
#1997208-32: Specify a fixed custom file directory for use with the /file/add form

FIRST, apply the above mentioned patch to the file_entity module, then, in the file_entity configuration for the default upload directory configuration /admin/config/media/file-settingsyou can add something like
[current-date:custom:Y]/[current-date:custom:m]/[current-date:custom:d]

I believe I tested this recently and it worked for me but I will have another look

adding some possibly related issues.

For my clients I've set up some custom glue modules to handle organizing which folders to upload files to (depending on type of file and where they're used.

This would be for 'out of the box' type configuration.

WayneDyck is pretty happy with this token solution but not exactly the same requirement.
#1997208-36: Specify a fixed custom file directory for use with the /file/add form

Hard to say if this is a bug report or not, it may just be server configuration. Also, it's not clear if this functionality ever worked for any version for the use case scenario described by Chrisgross. For now it's a support request.

Generally, to configure private folders it's important to know that a private folder usually means that it would be outside of the webroot but still writeable by the webserver, read permissions processed by the web application according to the permissions configured. A lot of things can go wrong if one doesn't configure the filesystem permissions correctly. Also, details about operating system, filesystem version, web server version and type would be helpful.

also, TO expedite a possible solution a clear concise explanation of the configuration details written to a targetted audience being developers would very much be appreciated.

Hi Chris, it appears that this is not a media issue, but rather a core issue.

You're in luck, there is a patch available.
#2211657-7: file_unmanaged_copy not working properly when the destination directory does not exist.

Apply this patch to core and see if it helps. Meanwhile I am going to test it myself, I believe patch #7 is for D7.

Should the core patch not work for you, check these issues about folder permissions.
#1588056-16: The specified file temporary://filet8OKMQ could not be copied, because the destination directory is not properly configured
https://www.drupal.org/node/2180519#comment-12158888
https://www.drupal.org/node/2546328#comment-12034390
#2546328-3: The specified file temporary://file could not be copied, because the destination directory is not properly configured. Thi
#1910564-3: File temporary://name could not be copied, because the destination directory public://js//wysiwyg is not configured correctly

Hi Chrisgross , please post the details about your successful test results in the related core issue #2211657: file_unmanaged_copy not working properly when the destination directory does not exist.

The only way the core issue will get fixed is if it gets enough attention , basically a simpletest has to be written for the test case , but at least if you could post your results saying that the core patch is good (patch 7 #2211657-7: file_unmanaged_copy not working properly when the destination directory does not exist.
)
then perhaps it'll get some additional attention. Also, your feedback will bump the issue back to the top of the queue.

Hi Chris, thanks for the detailed summary. If possible, could you please debug the code and indicate if the actual code making a new fid is either a) the core patch , b) file_entity , or c) media
and which function is doing this.

here's how to make a backtrace, (which functions are called , in the order of which they were called)

backtrace code comes in handy. The file should be created in the web root.

if ($fp = fopen('backtrace.log', 'w')) {
  $bt = debug_backtrace();
  fwrite($fp, 'debug='.print_r($bt, true));
  fclose($fp);
}

Another approach if you want it in your browser:

$bt = debug_backtrace();
echo "<pre>" . print_r($bt, true) . "</pre>\n";

Here is an example of some output:

[4] => Array (
  [file] => /var/www/d7/sites/all/modules/contrib/path_breadcrumbs/path_breadcrumbs.module
  [line] => 135
  [function] => ctools_access
  [args] => Array (
    [0] => Array (
      [plugins] => Array (
        [0] => Array (
          [name] => entity_field_value:node:feed_item:field_category

Debugging core errors that might not really be core errors

https://www.drupal.org/node/2487462#comment-11872110

Keeping a log

Using a function like this, you can keep appending a log. (usually written to the root folder of your site) The log is best viewed using an editor where you will be prompted automatically to reload. When you're wanting to see a fresh log, then just select-all, delete and save.

function imgoingtosaythis($what_im_sayin) {
  if ($fp = fopen('saythis.txt', 'a')) {
    fwrite($fp, "$what_im_sayin\r\n");
    fclose($fp);
  }
}

then in some module, you'll put this line in:

imgoingtosaythis($any_variable);

Quick debugging with watchdog.

Sometimes all you need is this.
//When you want to debug something, and dpm isn't doing it for you, then you should use this:

  watchdog('a_debug_test', '<pre>@print_r</pre>', array('@print_r' => print_r( $variables, TRUE)));

Assuming the silence means the issue is resolved.
should you experience this issue, please try the available core patch.
https://www.drupal.org/files/issues/create-directory-on-file-copy-221165...

update for this, there's an RTBC patch for D7 that you should use in place of the above patch.

see this patch description
#2789723-1: [D7 backport] drupal_mkdir does not set permissions to directories it created recursively

the actual patch:
https://www.drupal.org/files/issues/2789723-1.patch

There's hope that this patch could get into drupal core 7.60 or 7.57 ?

updating issue title

workaround /fix is to apply the RTBC core patch

marking as postponed on D7 core patch commit.

Recent versions of media have resolved most of peoples concerns and is compatible with entity translation, multilingual and various advanced configurations. Due to the high volume of inactive and most often irrelevant issues we are Closing this as (outdated). If for whatever reason this issue is important to you AND you still have issues after checking the media recipe documentation, then let us know and we will review your concerns.

Otherwise, see the recipe documentation for how to configure media and for troubleshooting tips OR refer to the media_dev distribution if you want to see a working media setup.

As mentioned, feel free to make some noise in this issue if you still feel it is important to you or someone else.

Thanks,

Media team