Bug #45859: Element Browser stops working - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #45859

closed

Element Browser stops working

Added by Christian Herberger over 11 years ago. Updated about 6 years ago.

Status:

Closed

Priority:

Must have

Assignee:

Benni Mack

Category:

File Abstraction Layer (FAL)

Target version:

Start date:

2013-02-26

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

6.0

PHP Version:

5.3

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

We found a bug in the element browser in TYPO3 (maybe only in the image selector, but this is one of the most central parts for editors)

When you try to add a picture to a textpic-element, you get the element browser dialog. There you can navigate through your folders. From the moment on you use an arrow to open a folder with subfolders, you cannot select a folder anymore. Javascript error console says "jumpTo is not defined". We tested it on a client's page which was upgraded from 4.5 to 6.0 and on a fresh 6.0 installation without any extensions changing file or element browser behaviour.

Related issues 4 (0 open — 4 closed)

Actions

Copy link

Updated by Tilo Baller over 11 years ago

Same here with TYPO3 6.0.0 - 6.0.4. Tested in Firefox 19 and Chrome 24/25.

Actions

Copy link

Updated by Tilo Baller over 11 years ago

I also recognized the following two errors in belog which occur when opening the Element Browser popup.

16:19:04 tbal@LIVE     [5]     [0]     Core: Error handler (BE): PHP Warning: ArrayIterator::seek() expects parameter 1 to be long, string given in [...]typo3_src/typo3/sysext/core/Classes/Resource/Driver/LocalDriver.php line 312     
16:19:04 tbal@LIVE     [5]     [0]     Core: Error handler (BE): PHP Warning: rtrim() expects parameter 1 to be string, object given in [...]typo3_src/typo3/sysext/recordlist/Classes/Browser/ElementBrowser.php line 1867

Actions

Copy link

Updated by Helmut Hummel over 11 years ago

Category changed from Backend User Interface to File Abstraction Layer (FAL)
Status changed from New to Accepted

This indeed a bug which was introduced with the ajax loading of the subfolders in the file picker

Actions

Copy link

Updated by Benni Mack over 11 years ago

Assignee set to Benni Mack

working on that.

Actions

Copy link

Updated by Benni Mack over 11 years ago

OK. This does not have anything to do with FAL, but with the fact that there are multiple Tree implementations in the Core. The AJAX call uses an old function to return the tree parts, but the original tree set up when loading a page uses another.

Actions

Copy link

Updated by Fry over 11 years ago

Is there any workaround for now?

Actions

Copy link

Updated by Oliver Rowlands over 11 years ago

Mack: any update on this issue yet?

Actions

Copy link

Updated by Simon Huebner over 11 years ago

No News yet? I have the same issue while inserting some (dunno what the failing attributes are) images to rte.

Actions

Copy link

Updated by Sven Juergens over 11 years ago

same bug in 6.1.1

Actions

Copy link

#10

Updated by Thomas Blaß over 11 years ago

Is there an update on this issue? My editors are very annoyed because this issue is a mayor usability issue for them and is not fixed after 3 month.

Actions

Copy link

#11

Updated by Chris topher over 11 years ago

This is at least for one part the same problem as #47648.

The problem comes from ElementBrowser.php line 1138:

TYPO3\CMS\Recordlist\Browser\ElementBrowser::main_file() calculates the value of $this->selectedFolder and in one case, $this->selectedFolder is not set to a string, but to an object:

$fileOrFolderObject = \TYPO3\CMS\Core\Resource\ResourceFactory::getInstance()->retrieveFileOrFolderObject($this->expandFolder);
if ($fileOrFolderObject instanceof \TYPO3\CMS\Core\Resource\Folder) {
    // It's a folder
    $this->selectedFolder = $fileOrFolderObject;
...
if ($this->selectedFolder && !$this->isReadOnlyFolder($this->selectedFolder)) {

This causes the problem.

It would be correct, if $this->selectedFolder would be set to the absolute path of the folder.

Actions

Copy link

#12

Updated by Andreas Renner over 11 years ago

I'm currently confrontated with this problem too, as I'm trying to update a customers site from 4.6 to 6.0.6. Everything seemed to work fine, but this problem stops the whole process. For testing reasons I've set up a blank new Typo3 installation next to the updated site. The problem does not exist on the new site, only on the updated one! The next thing I tried was to deactivate all the installed extensions on the customer-page, so that on both sites there are the same extensions installed, but no luck, the problem still exists. Unfortunately time is already short...is anyone out there, working on this issue?

I've investigated further, but first I have to say, I'm not familiar with the typo3-core:

I debugged this with the help of Christopher's post, made a workaround for this, just to see if this is the only problem with the ElementBrowser and: no it isn't. The next exception thrown is the following:

PHP Warning: ArrayIterator::seek() expects parameter 1 to be long, string given in <blablabla>typo3/sysext/core/Classes/Resource/Driver/LocalDriver.php line 316 (More information)

and it originates from

typo3/sysext/recordlist/Classes/Browser/ElementBrowser.php, Line 1523 where getFiles is called with the only Parameter $extensionList. But getFiles (in typo3/sysext/core/Classes/Resource/Folder.php, Line 184) is defined as follows:

getFiles($start = 0, $numberOfItems = 0, $filterMode = self::FILTER_MODE_USE_OWN_AND_STORAGE_FILTERS, $recursive = FALSE)

So the a string with file-extensions is passed as $start which leads to the error in LocalDriver.php, line 316.

Hope that helps someone more familiar with the typo3 core!

Actions

Copy link

#13