Problem/Motivation

It is not clear how to override the temporary-files directory in settings.php.

Proposed resolution

The first three of these lines are already in settings.php (commented-out examples). Add the additional temporary-files directory in front so the keys are in alphabetical order.

# $config['system.file']['path']['temporary'] = '/tmp';
# $config['system.site']['name'] = 'My Drupal site';
# $config['system.theme']['default'] = 'stark';
# $config['user.settings']['anonymous'] = 'Visitor';

In addition to documenting a common use case, this provides an example of overriding a complex setting. The existing examples are simple string variables.

Remaining tasks

Put the new config override in alphabetical order with the other example config overrides. See Comment #46.

User interface changes

None

API changes

None

Data model changes

None

Original report by britter

There may be a logical explanation, however currently I could not find documentation regarding this change.

In Drupal 7 you were able to set the public, private, and temporary files directory in the main settings.php, which made it very easy to alter the path of each directory per environment. However, in Drupal 8 this does not work/seem to be possible to change the temporary files directory path (so I wrote my first D8 module to support this)(and you can change the public and private path, but not tmp), but is there a good explanation of why this was left out or should you not make the tmp directory changeable in this way? Should the temporary files directory not be separated out by itself in D8 or put inside the private files directory (usually not a good idea)? Suggestions are welcome.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

britter created an issue. See original summary.

britter’s picture

Issue summary: View changes
chera.jaswinder’s picture

Let me start with Drupal D7 in settings.php we write

$conf['file_temporary_path'] = '/tmp'; and changes are reflected.

But D8 has a whole new configuration system to store configuration data in a consistent manner. All of your site configuration from enabled modules through fields, contact categories to views, are stored with this system. The system is designed to make it much easier than prior Drupal versions to make changes, export site configuration to files, and import those changes back into the site.

Earlier we made use of features and strong arm to export all the configurations but due to excellent configurations management (https://www.drupal.org/documentation/administer/config) we are able to export everything at once even settings.php configurations. So changes made in settings.php will not be reflected at administrative UI interface but will be reflected if exported and imported in some another environment (like stage) using Configuration Manager module to export settings required.

As mentioned by you that you was able to set settings.php according to environment, here you can also do the same. Let me provide you an example:

To give you a quick start, I want to share the settings.local.php that I use for my D8 development.

Copy the below code into a settings.local.php file and place it in the settings directory. Uncomment the code settings.php (below) to activate the include function.

<?php
$config['system.site']['name'] = 'Drupal 8 DEVELOPMENT';
$config['system.file']['path.temporary'] = '/tmp';
?>

This is how the code in settings.php should look now:

<?php
/**
 * Load local development override configuration, if available.
 *
 * Use settings.local.php to override variables on secondary (staging,
 * development, etc) installations of this site. Typically used to disable
 * caching, JavaScript/CSS compression, re-routing of outgoing emails, and
 * other things that should not happen on development and testing sites.
 *
 * Keep this code block at the end of this file to take full effect.
 */
if (file_exists(__DIR__ . '/settings.local.php')) {
 include __DIR__ . '/settings.local.php';
}
?>

Do note that, different from Drupal 7, these overrides are not visible in the admin interface. For that purpose I have added an overridden site name to give you some visible proof that the configuration is overridden.

For me above one is cleaner way to manage settings per environment.

Other way round and simple, you can also override by using

Configuration overrides

in settings.php, just add the provided config code in settings.php.

You would also like know how I got $config['system.file']['path.temporary'] because this $config['system.site']['name'] is already mentioned.

Answer is earlier in D7 we store configurations in variable but after D8 configuration management system everything is now stored in config table. This table contains all the variables which stores its related variables information in serialized format. So after looking into system.file variable in unserialized format I was able to track the same and put configuration in same.

Please CLEAR THE CACHE at last and its all done.

Hope it makes your every doubt clear.

chera.jaswinder’s picture

Title: Temporary Files Directory path not set-able in settings.php » Temporary Files Directory path not configurable in settings.php
Component: file system » configuration system
chera.jaswinder’s picture

Component: configuration system » documentation
Issue tags: +Needs documentation
chera.jaswinder’s picture

Documentation updates required in settings.php for configurable overrides.

chera.jaswinder’s picture

chera.jaswinder’s picture

Version: 8.1.x-dev » 8.0.3
chera.jaswinder’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 7: 2662646-configurable-temporary-file-path.patch, failed testing.

jhodgdon’s picture

Status: Needs work » Closed (won't fix)
Issue tags: -Needs documentation

Sorry, but I don't think we want to add this to the documentation. There is already a section in default.settings.php that explains how to do config overrides, and we are definitely not going to try to document every possible override there.

chera.jaswinder’s picture

Hi Jhodgdon,

As users are not aware for the temporary path configuration. I think we should include at least attached new patch to make users aware and clear for temporary path.

It is most common thing which should be added for users ease.

Regards,
Jaswinder

chera.jaswinder’s picture

Status: Closed (won't fix) » Needs review
cilefen’s picture

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

@chera.jaswinder:

Thank you for your time and attention to this.

@jhodgdon is the documentation system maintainer. Unless a strong case can be made as to why this ought to be documented in the default settings now in Drupal 8 when it is not documented in the default settings in Drupal 7, the decision is clear. There are many important issues that need attention.

Consider enhancing the drupal.org documentation with this information if it will help people.

daften’s picture

Status: Closed (won't fix) » Active

I'd say there is a strong case for documenting this.
In Drupal 7 it wasn't documented, but the temporary path could be set in the settings.php file similar to how the public and private folder were set:

$conf['file_temporary_path'] = '/tmp';

In Drupal 8 the examples in default.settings.php show that the public and private file folders can be set similarly, but with the $settings array. For the temporary path that is not the case however, and it only works by using

$config['system.file']['path.temporary'] = '/tmp';

This can cause a lot of confusion for people. Saying it shouldn't be documented because "it wasn't documented in Drupal 7" is not a proper argument IMO, since the behaviour aligned with the other folder settings. Drupal 8 changes a LOT of things, this is one of them, and those changes should be documented properly. The patch in #12 does this very decently and has no inherent risk. While I agree, there should be a limit on what can be accepted in the code, it should at least be documented here I believe: https://www.drupal.org/node/1928898

colan’s picture

Version: 8.0.3 » 8.3.x-dev
Status: Active » Reviewed & tested by the community

I agree with #15; this is a rather important configuration setting, and should be explicitly stated in one of the settings files (either settings.php or settings.local.php).

In Aegir for example, we make these temporary directories unique for each site by sticking it in sites/www.example.com/private/temp. Besides being a good security practice (by not having multiple sites access the same temporary file space), it helps keep things organized. Sites' temporary data doesn't clutter the global space, and everything related to a particular site stays within its site directory.

Site maintainers should be forced to consider these factors when they review one of the shipped settings files. But this won't be possible if they don't find it anywhere. Having said that, it doesn't need to be in the main configuration settings block. I'd be fine with moving it to its own stanza, or another appropriate one, but it should be in there somewhere.

The decision to keep this out should be reversed.

RTBCing the last patch (#12), but this can also be set to NW if someone wants to stick it elsewhere. I'm also assuming that ['path.temporary'] is as acceptable as ['path']['temporary']. If not, then this definitely needs to be set to NW.

cilefen’s picture

Title: Temporary Files Directory path not configurable in settings.php » Temporary Files Directory path is not documented in settings.php
Related issues: +#2817677: Can't remove "Temporary Directoy" path
memtkmcc’s picture

I agree that it should be documented somewhere, unless D8 core will fix this inconsistency, silently introduced. Like others explained above, in D7 all those files specific paths were bundled in the $config[] array, while in D8 two of them (along with other variables) have been moved/renamed to $settings[], so it is definitely not expected that this single path should still live in the $config[] array, unless it will be properly documented.

catch’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs issue summary update

This is configurable in the UI at admin/config/media/file-system, so I'm not sure why we'd also document it in settings.php

daften’s picture

Status: Needs review » Reviewed & tested by the community

Then why document setting the public and files directory path? That's also configurable through the UI ...
Documenting this is needed for the very simple reason: some people need it. E.g. you take a production database but on your local machine the temp path is different, but you don't want it changed in the DB. You have several environments (prod, QA, staging, ...) and you want to set these items differently per environment, but want to be able to sync your database downstream.

I honestly don't understand the question, because nearly everything is configurable in the UI, so why document anything in the settings.php file?

catch’s picture

Status: Reviewed & tested by the community » Needs review

That's also configurable through the UI ...

They're not configurable in the UI. They're shown in the UI, which points you to settings.php to change them.

Config overrides are explaining generically in settings.php, we don't need to document every one.

daften’s picture

Status: Needs review » Reviewed & tested by the community

True, but something being settable in the UI, is not an argument to NOT document it in the settings.php. The would mean nothing for $config would need to be explained because "it's all configurable in the UI"
The reason why this warrants documentation is very simple:
1/ Public, private and temp folders had similar config names to be overridden in settings.php, so for most if not almost all developers coming from drupal 7, this is just plain confusing.
2/ Public and private folders are explained because they are deemed environment specific and now need to be set in settings.php. However the temp folder can also be seen as environment specific. Especially if you consider local dev as one of the environments.

The ONLY argument i read here is: we're not going to document every config override in settings.php. Which is in itself a valid point. But i wonder if anybody that makes this argument has thought for one second about all the new developers that come to Drupal 8. Because every dev that comes from "outside" or starts from Drupal 7 needs to be considered a new dev for drupal 8.

If it's not documented in settings.php, there should be a page on Drupal docs about this at least. I can't find any page about this ATM (could be because of the documentation migration).

cilefen’s picture

Status: Reviewed & tested by the community » Needs work

The arguments on each side are:

  • Against: We have not documented this before. Why should we now?
  • For: It is difficult to discover the correct way to configure this.
  • Against: Must we document every overridable configuration?
  • For: This is a reasonable addition to the documented configuration overrides.
  • For: We document the public and private directories configurations. Why not temp?

I will add that for most site admins, the configuration system is a mystery if folks are even aware it exists. So to assume that every configuration is easily discoverable by anybody doesn't hold water. And, people seem to want this. And this issue is over one line...of documentation, which will have a maintenance cost of practically nothing.

So, I am feeling a +1 for this. However, the issue summary needs an update before this can be committed. It should outline the reasons for making this change—an effort to convince others of the worthiness of this addition. I am setting this to "Needs work" until that happens.

colan’s picture

I'm quite sure that the patch needs work as well. It has ['path.temporary'] instead of ['path']['temporary']. I don't think that'll work.

xjm’s picture

I don't think the documentation of this belongs in settings.php -- as @catch points out, it's just a config override. There is already a separate section explaining config overrides and their risks and requirements.

Maybe a compromise would be to simply add it to the config overrides examples? This bit:

# $config['system.site']['name'] = 'My Drupal site';                             
# $config['system.theme']['default'] = 'stark';                                  
# $config['user.settings']['anonymous'] = 'Visitor';  
colan’s picture

@xjm: That's what's in the patch already.

cilefen’s picture

Title: Temporary Files Directory path is not documented in settings.php » Add the temporary files directory config to the example config overrides in default.settings.php
xjm’s picture

@colan I see an entire docblock?

Edit: Sorry, somehow missed over the change of direction in the more recent patch.

daften’s picture

Status: Needs work » Needs review
FileSize
458 bytes

I've added a new patch, because my settings.php file had what @colan said.

colan’s picture

Status: Needs review » Reviewed & tested by the community

That looks better. Now we just need to update the summary.

colan’s picture

Status: Reviewed & tested by the community » Needs work

Sorry, let's keep the status until that's done.

wesleydv’s picture

Just tried this and $config['system.file']['path']['temporary'] did not work for me.
However $config['system.file']['path.temporary'] did, is this something that changed in dev?

memtkmcc’s picture

FileSize
708.52 KB

Hmm... just tested this with Drupal-8.2.4 on Aegir, where we use $config['system.file']['path']['temporary'] and it works perfectly.

path-tmp-d8

wesleydv’s picture

Please ignore my previous comment $config['system.file']['path']['temporary'] does work for me.
However it appears that a cache rebuild is necessary even after a fresh install, don't know if this is by design.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

fago’s picture

Status: Needs work » Needs review
FileSize
786 bytes

Same for me $config['system.file']['path']['temporary'] works while $config['system.file']['path.temporary'] does not. Updated patch attached.

Munavijayalakshmi’s picture

2662646-configurable-temporary-file-path_0.patch:11: trailing whitespace.
 * A local file system path where temporary files will be stored. This 
Checking patch sites/default/default.settings.php...
Hunk #1 succeeded at 648 (offset 21 lines).
Applied patch sites/default/default.settings.php cleanly.
warning: 1 line adds whitespace errors.

I have fixed it, please review.

colan’s picture

#37: You patch looks identical to #36. Please provide an interdiff to illustrate any differences when providing updated patches.

Munavijayalakshmi’s picture

Assigned: Munavijayalakshmi » Unassigned
FileSize
1.31 KB
osopolar’s picture

Overwriting the path setting in database (for below example it is /home/example.com/tmp) with $config['system.file']['path']['temporary'] = '/tmp'; gives me on the page http://localhost/admin/config/media/file-system the following error. It does not hurt, but it does not look nice:

Warning: mkdir(): Permission denied in Drupal\Core\File\FileSystem->mkdirCall() (line 237 of core/lib/Drupal/Core/File/FileSystem.php).

Drupal\Core\File\FileSystem->mkdirCall('/home/example.com', 509, , NULL) (Line: 207)
Drupal\Core\File\FileSystem->mkdir('/home/example.com/tmp', NULL, 1, NULL) (Line: 1159)
drupal_mkdir('/home/example.com/tmp', NULL, 1) (Line: 870)
...

benjifisher’s picture

Status: Needs review » Needs work

The patches in #36 and #37 add a section to settings.php. The earlier discussion rejected this approach in favor of adding a single line as in the patch from #29.

Please let's stick with the patch from #29 and please re-read the comments #30 and #31. The reason this issue is marked NW is that the issue summary needs an update. The patch (#29) is fine.

benjifisher’s picture

@osopolar, are you sure that you had /tmp and not just tmp?

osopolar’s picture

Yes I am sure, I double checked again and I changed above comment as it was misleading. The setting is /home/example.com/tmp on live. When I go to http://localhost/admin/config/media/file-system I get the error messages as drupal still thinks the tmp dir is in /home/example.com/tmp although I already set $config['system.file']['path']['temporary'] = '/tmp';. The complete backtrace error message is:

Warning: mkdir(): Permission denied in Drupal\Core\File\FileSystem->mkdirCall() (line 237 of core/lib/Drupal/Core/File/FileSystem.php).

Drupal\Core\File\FileSystem->mkdirCall('/home/example.com', 509, , NULL) (Line: 207)
Drupal\Core\File\FileSystem->mkdir('/home/example.com/tmp', NULL, 1, NULL) (Line: 1159)
drupal_mkdir('/home/example.com/tmp', NULL, 1) (Line: 870)
system_check_directory(Array, Object)
call_user_func_array('system_check_directory', Array) (Line: 1052)
Drupal\Core\Form\FormBuilder->doBuildForm('system_file_system_settings', Array, Object) (Line: 1044)
Drupal\Core\Form\FormBuilder->doBuildForm('system_file_system_settings', Array, Object) (Line: 557)
Drupal\Core\Form\FormBuilder->processForm('system_file_system_settings', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 144)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 652)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I think it should be easy to reproduce (without copying db from somewhere):

1. Create a directory on the local machine, set temp in file system settings to that directory and save
2. Delete directory and make sure that webserver-user does not have rights to create it (mkdir)
3. Set $config['system.file']['path']['temporary'] to a valid directory and call settings form again.

benjifisher’s picture

@osopolar, I tried your steps and I see the same behavior.

To clarify, in Step 1 there were no overrides in settings.php and I used the admin UI (/admin/config/media/file-system) to set the temp directory to /opt/foo. In Step 2, I removed the directory /opt/foo.

In Step 3, there was no error when I reloaded the page. At that point, the temp directory on the form was set to /opt/foo. When I submitted the form, I got the error message you describe. (I seem to have errors hidden, but I see something similar in the log.)

It seems to me that this is expected behavior: when I submit the form with an invalid temporary directory, I get an error message. If I overwrite that with a valid directory, it works fine.

It is a little confusing because Drupal is keeping track of two values: one in the database and one from settings.php. You can see each using drush cget system.file with and without the --include-overridden flag. The default value when you load /admin/config/media/file-system, and the one changed if you submit that form, is the value in the database. I am sure that has been discussed at length. After giving it a little thought, I think it makes sense.

At any rate, that behavior is not related to this issue, which concerns documentation. If you think it is still a problem, then please open a separate issue. You can add this one as a related issue so that it will be easier to follow the discussion in the future.

benjifisher’s picture

Issue summary: View changes
Status: Needs work » Reviewed & tested by the community
Issue tags: -Needs issue summary update

I have updated the issue summary, as requested in #30 and #31.

I have hidden the patches from #36 and #37 and the interdiff in #39. Please use the patch from #29. As I said in #41, most of the comments since #31 are not really relevant.

cilefen’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Novice

I updated credit. Please, based on the #29 patch, put the new config override in alphabetical order with the other example config overrides.

benjifisher’s picture

Issue summary: View changes
Issue tags: +Baltimore2017
philnguyen’s picture

I am going to write a patch for number 46 at the baltimore sprint

philnguyen’s picture

Status: Needs work » Needs review
FileSize
617 bytes

This is the new patch

dagmar’s picture

Status: Needs review » Needs work

Thanks! but system.theme should be before than user.settings.

xlin’s picture

@philnguyen Temporary directory should be /tmp instead of tmp.

philnguyen’s picture

Status: Needs work » Needs review
FileSize
541 bytes

This is the new patch

tomogden’s picture

#52 Looks good to our sprint review group.

dagmar’s picture

Status: Needs review » Reviewed & tested by the community

Thanks everyone!

tomogden’s picture

Issue summary: View changes
robertloo’s picture

Reviewed. Patch looks good

tomogden’s picture

Issue summary: View changes
robertloo’s picture

Reviewed entire ticket. There are no outstanding issues. #52 resolves the reported problem.

dhopki12’s picture

Priority: Minor » Normal

As a feature request I switched the priority to 'normal' (documentation link: https://www.drupal.org/core/issue-priority#normal )

YesCT’s picture

What is our confidence that if someone uncommented this, that it would work as we hope?

Did someone try uncommenting it and test it?
And document on this issue what they had to do besides uncommenting it?
I agree a block of inline comments is not needed, but it would be helpful to say on this issue what steps had to be done.

dagmar’s picture

I did it. It works as expected.

The only thing is you have to be sure permission are correctly set.

  • lauriii committed d708605 on 8.4.x
    Issue #2662646 by chera.jaswinder, philnguyen, Munavijayalakshmi, daften...
lauriii’s picture

Status: Reviewed & tested by the community » Fixed

Committed on stage at DrupalCon Baltimore 2017 c4c8481 and pushed to 8.4.x. Thanks everyone!

benjifisher’s picture

@YesCT, @dagmar, just to be clear: when you uncommented the line, you did that in settings.php, right? The patch applies to default.settings.php .

dagmar’s picture

Yes. Sorry I forgot to mention my tests. So I modified the settings.php file, and then played with the folder permissions to check if that settings was being picked.

If you don't have enough permissions, the case of the site breaks as expected.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.