Convert file system settings to the new configuration system

I think I have all the pieces in place, but I'm running into some confusion on how to handle default values that are defined, or partially defined by function calls or other dependencies. I called these out with TODO's in the patch.

Remaining tasks:
Converting current calls throughout the rest of core for these variables
Upgrade path

Reminder based on discussion that any changeable defaults at install time can be set in the module init don't have to be done via the file unless static. Value will be available to change after that initial set method is called.

Got a lot further along with this one. Still missing the upgrade path, but wanted to see what the testbot has to say about it so far.

Fixed the syntax errors, based on running test locally this has introduced quite a few failure point for other systems.

#7: system-filesystemform-cmi-1496480-7.patch queued for re-testing.

#7: system-filesystemform-cmi-1496480-7.patch queued for re-testing.

Took another look at this and found an instance where we are looking for file system paths before the config table exists in system.install. I think these missing default values are what was causing the weird test results above.

Not sure what needs to happen to work around this.

Test will fail as Installation process fails. But rerolls to had and the interdiff shows a config setting I made to avoid a PHP warning for a missing argument.

This will fail. Simply rerolling against HEAD and merging the conflicts of test files removing into their respective test files.

All config system conversions are API changes, so tagging as such.

The patch attached rerolls the patch from #11 as the patches in #14 and #15 have included changes that are not part of this patch.

Currently this patch has issues during upgrade caused due to using config before it's available - which I will hopefully resolve soon. Posting here as a work in progress and to save anyone else who is interested in doing this the reroll.

Additionally the code needs work to improve the comments around what happens during an install.

The patch converts following variables which are present on the file_system_settings form:

• file_default_scheme
• file_public_path
• file_private_path
• file_temporary_path
• locale_translate_file_directory (added to the form using a form_alter in the locale module)

It additionally converts the following variables which are part of the file system but can not be configured through the UI.

• allow_insecure_uploads
• file_chmod_directory
• file_chmod_file
• file_icon_directory

I've removed the novice tag as the installer issues make this conversion quite tricky.

Fixed the upgrade path failures.

Wow, great work so far!

+++ b/core/includes/file.inc
@@ -1126,9 +1127,9 @@ function file_unmanaged_move($source, $destination = NULL, $replace = FILE_EXIST
+ * 'system.file.allow_insecure_uploads'. If it evaluates to TRUE, no alterations

@@ -2113,13 +2114,13 @@ function file_get_mimetype($uri, $mapping = NULL) {
+ * This function will use the system.file.permission.directory and
+ * system.file.permission.file configuration for the default modes for

(and possibly elsewhere) Admittedly, we have no standard for this kind of text references to config objects + keys within yet, but in day-to-day issue communication, the syntax of:

module.object:key.subkey

(i.e., delimited by a colon)

...gained some "popularity." For now, I think I'd suggest to go with that. (A dot as delimiter definitely seems wrong to me.)

+++ b/core/includes/file.inc
@@ -2139,10 +2140,16 @@ function file_get_mimetype($uri, $mapping = NULL) {
-      $mode = variable_get('file_chmod_directory', 0775);
+      $mode = intval(config('system.file')->get('permission.directory'), 8);
+      if (!$mode) {
+        $mode = 0775;
+      }
...
-      $mode = variable_get('file_chmod_file', 0664);
+      $mode = intval(config('system.file')->get('permission.file'), 8);
+      if (!$mode) {
+        $mode = 0664;
+      }

@@ -2319,7 +2326,10 @@ function drupal_basename($uri, $suffix = NULL) {
-    $mode = variable_get('file_chmod_directory', 0775);
+    $mode = intval(config('system.file')->get('permission.directory'), 8);
+    if (!$mode) {
+      $mode = 0775;
+    }

1) Hmmmm... there are some really really concerning user comments on intval()'s behavior on http://de.php.net/manual/en/function.intval.php

2) I think we should keep "chmod" as parent key name, since that clarifies that the value actually must be suitable for chmod().

+++ b/core/includes/file.inc
@@ -2402,40 +2412,20 @@ function drupal_tempnam($directory, $prefix) {
 function file_directory_temp() {
...
+    $temporary_directory = file_directory_system_temp();

@@ -2444,13 +2434,46 @@ function file_directory_temp() {
+function file_directory_system_temp() {

+++ b/core/lib/Drupal/Core/StreamWrapper/TemporaryStream.php
@@ -19,7 +19,11 @@ class TemporaryStream extends LocalStream {
+      $temporary_path = file_directory_system_temp();

The "system" part confused me a bit in the new function name; especially when I saw it called from elsewhere -- primarily, because there's a system.module. Would it make sense to use "os" instead? Or do we use "system" in other file functions already?

+++ b/core/includes/install.core.inc
@@ -1233,7 +1233,7 @@ function install_find_translations() {
 function install_find_translation_files($langcode = NULL) {
-  $directory = variable_get('locale_translate_file_directory', conf_path() . '/files/translations');
+  $directory = conf_path() . '/files/translations';

@@ -1273,7 +1273,7 @@ function install_select_language(&$install_state) {
-        $directory = variable_get('locale_translate_file_directory', conf_path() . '/files/translations');
+        $directory = conf_path() . '/files/translations';

I almost fear that the old variable was supposed to be configurable on a very low-level (e.g., global $conf or some weird distro-level override). We might have to retain that.

+++ b/core/modules/file/file.module
@@ -814,7 +816,7 @@ function file_icon_url(File $file, $icon_directory = NULL) {
-    $icon_directory = variable_get('file_icon_directory', drupal_get_path('module', 'file') . '/icons');
+    $icon_directory = config('system.file')->get('path.icon');

This actually seems to be a File module setting? It doesn't look like it belongs into this conversion?

+++ b/core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php
@@ -617,9 +617,11 @@ abstract class WebTestBase extends TestBase {
     // Set path variables.
-    variable_set('file_public_path', $this->public_files_directory);
-    variable_set('file_private_path', $this->private_files_directory);
-    variable_set('file_temporary_path', $this->temp_files_directory);
+    config('system.file')
+      ->set('path.public', $this->public_files_directory)
+      ->set('path.private', $this->private_files_directory)
+      ->set('path.temporary', $this->temp_files_directory)
+      ->save();

I LIKE! :)

+++ b/core/modules/system/config/system.file.yml
@@ -0,0 +1,14 @@
+inline_types:
+  - ^text/
+  - ^image/
+  - flash$

AFAIK, these belong to File module, too?

+++ b/core/modules/system/system.admin.inc
@@ -1836,18 +1837,36 @@ function system_file_system_settings() {
+  $config = config('system.file');
+  $config

btw, the repeated $config on the second line can be skipped. ->set() returns the config object :)

+++ b/core/modules/system/system.install
@@ -305,26 +305,50 @@ function system_requirements($phase) {
+    if (!empty($GLOBALS['system.file.path.public'])) {

I think you meant

$GLOBALS['conf']['system.file']['path.public']

in all of these?

@sun thanks for the great feedback. Incorporated everything in patch attached.

Do some mode reading on intval() and I've replaced it with octdec() based on http://www.php.net/manual/en/function.chmod.php#99747

Done some mode reading on intval() and I've replaced it with octdec() based on http://www.php.net/manual/en/function.chmod.php#99747

Fix installer language tests and .yml spacing.

In light of #1653026: [META] Use properly typed values in module configuration here's a patch that validates how much nicer this would make our code. The reason this works without the application of a patch is none of the config keys "typed" are maintained by FAPI.

The new YAML File looks like this

allow_insecure_uploads: false
chmod:
    directory: 0775
    file: 0664
default_scheme: public
path:
    private: ''
    public: ''
    temporary: ''

as opposed to

allow_insecure_uploads: '0'
chmod:
    directory: '0775'
    file: '0664'
default_scheme: public
path:
    private: ''
    public: ''
    temporary: ''

reroll

For now, we need to go back to #23; i.e., string values.

It's probably easiest to reverse-apply the interdiff from #24; e.g.:

git a --reverse 23-24-interdiff.txt

# or alternatively, as git might bail out on invalid path prefixes:
patch -p1 -R -i 23-24-interdiff.txt

I think I did this right. I applied 25, reverse applied 23-24-interdiff, and then diff'd out another patch. We'll see if it passes.

That patch came out a lot smaller than I expected, and it failed. I'm assuming something went wrong with my process. If I get a chance later this week (maybe office hours on Wednesday) I'll dig into it and see what happened. If someone has free time before then, by all means, have at it.

Here's a test at it. I had a similar result to disasm at first. Started QA'ing from the patch and everything looked right. Realized that I had done my diff against the later version instead of 8.x HEAD. Size looks about right now. Interdiff does show an addition I added back for the verbose settings. When I kicked off tests locally the verbose functions weren't found which I traced back to them being removed in patch. You can see what I added back in the interdiff.

Rerolled patch in #31 looks good - thanks kbasarab!

+++ b/core/modules/system/config/system.file.yml
@@ -0,0 +1,9 @@
+chmod:
+    directory: '0775'
+    file: '0664'

I think we need a YAML comment in here to explain that this should be php octal notation in a string format. Because if a user did this directory: 0700 it would break in a very weird way.

Compare - passing a string to octdec:

$ php -r "mkdir('testing',octdec('0700'));"
$ sudo ls -lah testing
total 12K
drwx------  2 developer developer 4.0K Aug 15 17:09 .
drwx------ 44 developer developer 4.0K Aug 15 17:09 ..

With - passing octal to octdec:

$ php -r "mkdir('testing',octdec(0700));"
$ sudo ls -lah testing
total 12K
d---r--r--  2 developer developer 4.0K Aug 15 17:09 .
drwx------ 44 developer developer 4.0K Aug 15 17:09 ..

Added:

# chmod variables should be a string in PHP Octal Notation.

to line 2 of the yml.

Looks great... I can't rtbc this patch cause I wrote a lot of it... but I think its ready :)

Don't think this belongs with D8MI(?).

reviewed this

+++ b/core/includes/file.incundefined
@@ -2138,11 +2139,18 @@ function file_get_mimetype($uri, $mapping = NULL) {
+    // Configuration system stores default modes as strings.
     if (is_dir($uri)) {
-      $mode = variable_get('file_chmod_directory', 0775);
+      $mode = octdec(config('system.file')->get('chmod.directory'));

This really needs a comment as to why we're using octdec() vs. intval() or (int). I would've just slapped an (int) or intval() on there too, so a summary of the php docs pages and/or links to them would help people looking at this.

+++ b/core/includes/install.core.incundefined
@@ -1210,9 +1210,23 @@ function install_find_translations() {
+/**
+ * Get installation translations directory path.
+ *
+ * @return
+ *   A string containing the installation translations directory path.
+ */
+function install_translation_directory() {
+  if (isset($GLOBALS['conf']['locale.settings']['path.translations'])) {
+    $directory = $GLOBALS['conf']['locale.settings']['path.translations'];
+  }
+  else {
+    $directory = conf_path() . '/files/translations';
+  }
+  return $directory;
 }

We should move all magic globals that aren't configuration overrides out of the 'conf' namespace to somewhere else. But that can happen all at once, doesn't need to be here.

+++ b/core/modules/system/system.installundefined
@@ -305,26 +305,51 @@ function system_requirements($phase) {
+    if ($phase == 'update' && !$config_installed) {
+      // Updating from 7 to 8.
+      // @TODO
+      // Use new functions from http://drupal.org/node/1348162 to load Drupal 7
+      // variables or use Drupal 7 defaults to create $directories array.

hmmm?

This needs to be rerolled, incorporating the changes made by these issues which have been committed since the patch in #33:

• #1344078: Local image input filter in core
• #1468328: Move file entity info, managed file, and file usage functionality into File module
• #1658842: Introduce a translations:// stream wrapper to access the .po file directory
• #1675260: Implement PHP reading/writing secured against "leaky" script
• #1742894: Get status of local and remote translation files
• #1791920: Create new translations:// directory for tests

I rerolled the patch against HEAD, converted the newly introduced variables mentioned in #38 and addressed the remarks in #37 (except the $conf issue).

I just noticed a duplicate of this issue where a ton of work was done: #1799504: Convert system file related variables to CMI. Is it possible to give these people credit for their work on this issue as well?

Interdiff:

 --- a/core/modules/locale/lib/Drupal/locale/TranslationsStream.php
 +++ b/core/modules/locale/lib/Drupal/locale/TranslationsStream.php
 @@ -20,8 +20,7 @@ class TranslationsStream extends LocalStream {
@@ -464,7 +464,7 @@
    function getDirectoryPath() {
 -    return variable_get('locale_translate_file_directory',
 -      conf_path() . '/files/translations');
-+    return config('locale.config')->get('translation.path');
++    return config('locale.settings')->get('translation.path');
    }

There were some more, but the tests are still failing.

#45: 1496480-45-cmi-file_settings.patch queued for re-testing.

How about a reroll?

And again.

Tags lost, putting back.

Rerolling onto HEAD.

Wow, that was _not_ on HEAD. Sorry.

New re-roll.

Just updating hook_update_N

Re-rolling with update change again

#61: 1496480-61-cmi-file_settings.patch queued for re-testing.

Adding system.file.xml

"unable to apply patch"? re-rolling after git pull

*Sigh*. I've tried figuring out the first few errors we're seeing here, and I can't wrap my head around it. Looking back over the issue history, it's clear that a great deal of things have changed during this patches life.

Instead of trying to work backwards with the debugger, I will attempt to "start over" with small parts of the patch, so I can see more exactly what changes cause what fails.

Cutting scope down to just file_chmod_file and file_chmod_directory. I have odd, seemingly unrelated, test-fails locally. Trying to upload to see what happens.

Updating octal view specification as specified in http://www.yaml.org/refcard.html

#77: 1496480-77-cmi-file_settings.patch queued for re-testing.

Based on http://drupal.org/node/1653026#comment-6311516 they symfony YAML parser converts octals to the decimal equivalent. Therefore perhaps it would either be better to store the permission in the config as a string or cast as an (int) within drupal_chmod.

If the number from the config file is cast to int - the tests pass. I might be missing something vital and trivialising the issue by a simple (int) cast though.

What in the world? I was certain I fixed the conversion before I uploaded the patch. Here we go again.
@typhonius Isn't casting to int what we already do with octdec?

Letharion: I may have misinterpreted PHP docs but octdec() appears to convert an octal to its decimal equivalent whereas casting it as (int) appears to take the octal and merely convert the type to int but leave the actual number as is.

I think one of the big differences between #82 and #77 is the permissions being stored as strings vs octal types in the config file. My comment about casting to int was related to permissions not being stored as strings so we're all good with that now.

Your patch seems to have taken care of drupal_chmod and relevant tests in the first instance - I think I'll start to have a look at expanding the patch to cover the scope of other file system settings.

nice to see it back in green again :). My only concern is calling octdec() in all places where we do config()->get().

Also, wouldn't be quicker if we split them separate as separate task? I made one for file_temporary_path at #1856752: Convert file_temporary_path to the new configuration system

And here's one for file_public_path: http://drupal.org/node/1856766

Not sure that makes sense. Writing the actual code is just a part of what needs to be done, the issues also need to be RTBC'd and commited, and if you split it up, then you will need to re-roll them each time one is commited due to conflicts (upgrade path..).

I do agree with not to split, but the number of items are high and failing most cases. Regarding update_N, as it is in system, anyway we need to update when new variable convert. your thoughts?

Now I can see the 'Upgrade path' and I'm totally agree with @Berdir in #87. We need to get this issue committed so that we don't need to common stuff(like http://drupal.org/files/17-19-interdiff.txt) in individual patches.

I've had a go at altering almost all of the file_public_path variable_get() calls.

As far as I can tell, the fails stem from the default value of the file_public_path is set in $conf prior to test installation in WebTestBase. We probably need to move those to new variable-names into $conf as well, but I fail to do so. I could just be doing it wrong, but my attempt with $conf['system.file']['path.public'] = $this->public_files_directory; does not make the value available from config().

Very short patch on top of #82 with debugging code relevant to figure out what's going wrong in #90/#92.

There are a couple of amendments in both TestBase.php and WebTestBase.php that I hoped would address that. I tried doing config()->save on the public files directory location in WebTestBase for example (whilst also leaving it in $conf to try and keep as much working and reduce errors)

When applying the patch locally the affected files pass tests although that's not indicative of a successful patch, rather, that things are roughly on the right track.

Admittedly it took forever for me to realise that to get successful results from config in, say, stream wrappers tests, the correct value for public files location should be saved earlier in the test procedure.

Trying to cover all the changes for this issue. Locally it is failing on Action looping, but it is not related to this patch (hopefully).

Action looping was one of the things that didn't make any sense to me and I couldn't figure out, so that's why I tried starting from scratch.

Thanks Letharion. I just found this in my local testing:

The requested page "/sites/default/files/simpletest/verbose/Drupal_action_Tests_LoopTest-3.html" could not be found.

It make sense that it's failing on this patch :) Looks like default permission for /files/ is not getting set proper?

Updating to get current core changes to start work on this patch.

re-roll to update system.install.

Tried to test this locally and found that most of the failing test cases are unit Test Cases and the reason is config.factory is not available on PublicStream:

-    return variable_get('file_public_path', conf_path() . '/files');
+    //return config('system.file')->get('path.public');
+    return conf_path() . '/files';

So this code fixed test cases, Updating this hard coded path to make sure this is the only issue for all test cases. if it is then we need to add a fix to make config.factory available in PublicStream::getDirectoryPath().

updating patch...

Yes, that's a great idea and absolutely necessary. As pointed out by catch currently the config directory is relative to the public files directory which makes storing the public files directory path inside ... inception.

Is it? I have not yet looked at this closely but if there really would be a dependency, this patch should fail to install/run tests, which is not the case?

Doesn't it just have the same default value logic? Here is the relevant piece from the config_get_config_directory() function

    // Allow a configuration directory path to be outside of webroot.
    if (empty($config_directories[$type]['absolute'])) {
      $path = conf_path() . '/files/' . $config_directories[$type]['path'];
    }
    else {
      $path = $config_directories[$type]['path'];
    }

That said, I'm still +1 for putting the public file path into settings but what about private and temporary?

The advantage of having the public file path in settings.php is IMHO that we could then also simplify the config_directories structure and default to absolute = TRUE and remove the nested array structure. So that these two settings would by default overlap but then they'd be in the same file which would make it easier to change them.

OK, so things do not actually break because we hardwired conf_path() . '/files into config_get_config_directory. I presumed it was using variable_get. If it doesn't, that doesn't really invalidate the argument, it just makes the change from UI a little less devastating but still -- I argue for removing the public files path from the UI because all your uploads still break. So that's not useful. Also, about 99% of the cases the sites/X/files is just fine.

As for private and temporary, it's a whole different bag of hurt. private does not really have a good default as you want to set it outside of docroot. temporary has a default but it's not always working. These two (needs fiddling, no good default) make me vote UI for these. I would put the public path there still with an explanation of why it can't be changed.

As discussed in IRC, there is still a very high chance that users will break their site despite that.

Because after changing the path in the UI, you will move the files directory over the other new location that you configured. And *then* your site will break, because you will have moved the config directory too and the system won't find it anymore.

And that's why I think the absolute option needs to go.

If we have this in settings.php:

$settings['file_path_public'] = 'sites/default/files';
$settings['config_directory']['active'] = 'sites/default/files/config/active_aserwesgrsewsef';

(or similar)

then it will be *much* more obvious to anyone who is changing file_path_public that it does in fact not affect the config path and they will either fix that as well or keep the config files where they are.

The next question is then if config should by default be in files but as discussed with @chx, that is a discussion for another day (Has implications on the installation, needs another writable directory).

$settings['config_directory']['active'] = 'sites/default/files/config/active_aserwesgrsewsef';

+10000000000000000000000000 to make the config directory DRUPAL_ROOT relative instead of the mess we have now.

updated the patch, replaced path.public with a setting.

Still needs quite a lot of work, just a start.
- There are 25+ definitions of the default value in core, we should either write it into settings.php and require its existence or add a helper function
- Needs a section in settings.php which describes it, similar to other $settings.
- Upgrade path probably needs to write it?
- Fix the failing tests ;)

#114: file-configuration-cmi-settings-1496480-114.patch queued for re-testing.

Opened #1887750: Use path relative to DRUPAL_ROOT in configuration directories

With putting the public files path in settings.php, I'm concerned about testing. Web tests in particular.

So far, pretty much everything in settings.php is not testable. And, settings.php force-overrides the environment in which tests are running.

We obviously don't want tests to use, clutter, and destroy the public files path of the parent-site/test-runner. So we'd have to find a discrete way for replacing settings in a web test with settings that are specific to the test environment.

In #1576322-29: page_cache_without_database doesn't return cached pages without the database, @chx explicitly denied writing of a custom settings.php for a test environment that would be used as a replacement for the actual/test-runner's settings.php, due to security reasons; i.e., file paths, authentication credentials, etc. could be exposed to the public.

Hm, yes, I see. That's a problem.

The current patch sets the setting to files/simpletest/... which makes it available within the test class but page requests will just use settings.php, which does not specify it. Had a similar experience with settings.php overrides and tests in 7.x recently.

An idea that I had was that we could *somehow* support a settings.php within the file_storage, which would be a safe thing to write to. That said, I'm not sure how easy it would be to trick Drupal to look there :)

If we put the whole files url into the agent string instead of just the ID then we could use php storage to read settings.php

Just to make sure I understand what you guys are thinking of - do you mean something like this?

// Generate:
$test_id = $this->database_prefix;
$php = simpletest_produce_settings_php($test_id);
// Write:
$storage = PhpStorageFactory::get('simpletest');
$storage->save($test_id . '/settings.php', $php);

---

// Read:
if ($test_id = drupal_valid_test_ua()) {
  $storage = PhpStorageFactory::get('simpletest');
  if (!$storage->load($test_id . '/settings.php')) {
    die("Hacks are us.");
  }
}
else {
  require_once conf_path() . '/settings.php';
}

Something along those lines. the problem is that php_storage needs the hash salt, which is defined in settings.php, so we can either only load the test settings.php additionally to the default one or have to pass through the complete file name (or at least the hashed name), so that it can be loaded directly.

Still, not sure if this is even possible, but I don't have any other ideas on how to make that work at the moment :)

And it is a blocker for using settings() for the public file path. I guess with #1887750: Use path relative to DRUPAL_ROOT in configuration directories, it is not actually required anymore, especially if we can move the config directory out of files.

So I'm not sure if we want to go back to the patch in #106 for the time being, and convert it to CMI to get rid of the variable_get() calls as a first step and look into making it a settings() thing later on... ?

Ok, let's see if we can get that working.

Straight re-roll of the patch from #106 to see if the installer and so on still work. There are some new variable_get() calls that I haven't look into yet.

Fixed the php storage tests, unit test can not use the config system.

Not sure what's up with all those crazy exceptions, let's try again.

Fixed DrupalKernelTest. Still hoping that I'll get to see the results even if there are some weird fatal errors remaining, but those look random to me and usually don't prevent from displaying the results...

Fatal error: Call to undefined method stdClass::entityType() in /var/lib/drupaltestbot/sites/default/files/checkout/core/includes/entity.inc on line 600

stdClass being used for an entity instead of an Entity, looks like?

Maybe the patch attached will fix the testbot errors...

I think we should go with heyrocker's suggestion from #124 and remove the public path conversion from this patch... especially since...

+++ b/core/lib/Drupal/Core/StreamWrapper/PublicStream.phpundefined
@@ -19,7 +19,8 @@ class PublicStream extends LocalStream {

@@ -19,7 +19,8 @@ class PublicStream extends LocalStream {
    * Implements Drupal\Core\StreamWrapper\LocalStream::getDirectoryPath()
    */
   public function getDirectoryPath() {
-    return variable_get('file_public_path', conf_path() . '/files');
+    //return config('system.file')->get('path.public');
+    return conf_path() . '/files';
   }

I think makes it moot...

So there were two three bugs in WebTestBase.

- The public file path was set to the translation directory. That caused the file field RSS failure.
- The path configuration was written before the modules were installed and then overwritten with the default configuration. So it worked within the test but blow up in the test page.
- The config overrides were wrong, as nested keys need to be an array, not using the . syntax.

Also converted some missing translation path settings and emptied the default path setting and made sure that it's set in locale.install.

Not yet sure what to do about the @todo in the installer but this should pass the tests I think.

EDIT: Forgot one bug, there were three.

That set needs a save.

Missing a call to parent::setUp() in a test.

Dang forgot to change the status...

Committed and pushed to 8.x. Thanks!

Followup #1914040: Private file system path is "0" after installation

Reopening since there is still a call to variable_get('stream_public_path', 'sites/default/files'); in core/modules/file/tests/file_test/lib/Drupal/file_test/DummyReadOnlyStreamWrapper.php

That's just a test variable, let's open a new issue instead of re-opening an old issue with 150 comments.

OK, opened #2109833: Finish converting stream_public_path to CMI