Issue with "path" param in fileTree widget

[qzminski]

When we define the "path" parameter for a fileTree widget, it works pretty well. The problem appears when we switch to the file manager and back - then we are already in session breadcrumb. That means the "path" will be ignored next time we launch the fileTree.

I thinkt he "path" should always override the session breadcrumb.

[qzminski]

Perhaps it can be simply added to the fileTree widget button "Change selection" as a &node=path param?

[leofeyer]

What are the exact steps to reproduce this issue?

[qzminski]

The issue occured in the situation:

1. Go to the file manager and click on a folder e.g. files/albums
2. Now in the custom module I have a fileTree widget with path set to files/photos
3. Clicking on the widget, I am still seeing the files/albums due to session breadcrumb

I think the path should always override the current session path. I have a custom extension where you can add objects. Each object can have multiple images, so I create a folder for each of them, e.g. files/objects/123. Now when I want to edit the object and upload the images from the popup file manager, I am forced to clear the path and search through a huge list of the folders.

This is the current hack I am using:

// config.php
$GLOBALS['TL_HOOKS']['loadDataContainer'][] = array('Class', 'setFileTreePath');

// Class.php
/**
 * Set the correct file tree path
 * @param string
 */
public function setFileTreePath($strTable)
{
    if ($strTable == 'tl_ext_objects' && TL_MODE == 'BE' && strpos(\Environment::get('request'), 'file.php') !== false && \Input::get('do') == 'extension')
    {
        $strPath = \tl_ext_objects::generateFileTreePath(\Input::get('field'), \Input::get('id')); // outputs "files/objects/123"

        if (\Session::getInstance()->get('tl_files_node') != $strPath)
        {
            \Input::setGet('node', $strPath);
        }
    }
}

[leofeyer]

Hm, is this somehow reproducible in the example website (Contao core)?

[qzminski]

Only if you can edit the /system/config/dcaconfig.php, as this is the only way we can set the path parameter. I think the below code would do just fine:

$GLOBALS['TL_DCA']['tl_content']['fields']['singleSRC']['eval']['path'] = 'files/music_academy';

Then follow the steps:

1. Go to the file manager and set breadcrumb path to e.g. files/tiny_templates
2. Try to add an image (or anything that uses singleSRC) in a content element
3. It will still point to files/tiny_templates and the path parameter will be ignored

[leofeyer]

Ah, now I see the light :) Thanks for your patience, Kamil.

[leofeyer]

Fixed in 65910c51f007c79055f087497ae3b1438feddc88.

[qzminski]

Thanks Leo for that patch, but apparently that's not what I was looking for. If we go to the file manager in the popup window, there is still an old breadcrumb set. This way the path does not make much sense if we cannot upload the files immedietally - in the file manager I still have to browse to tha appropriate folder.

Not sure if it was your desired case, but the fact is I still have to live with the hack. In my opinion the path should be added as node param (see my 2nd comment).

[leofeyer]

I see what you mean, however, the file manager and the file picker are independent from each other. Since the limitation in the dcaconfig.php is not applied in the file manager, seeing the selected nodes seems correct to me.

As far as I understand, you want the file manager to show a different selection when you open it directly and when you open it in the modal window coming from the picker. This would be a new feature, so I'd asked you to open a new ticket. However, I am not sure whether it makes sense in all use cases. @contao/workgroup-core

[qzminski]

This is quite a specific problem and appeared in several of my projects so far. I think nobody reported it before, so that means it's not a huge issue. In those projects where the issue was discovered, I provide the auto-folder creation upon the record creation, so the back end user doesn't have manually create a folder to store e.g. media files per each record.

I think we can leave this issue as closed. We'll see in the future if anyone encounters the similar problem and think about it again.