elFinder

I'have seen such issue when using different connectors like php and py on the same domain even with earlier version. Try to reproduce this error after you clean the cookies on desktop_no_cookie machine.

We will try to investigate it tomorrow, but I think it's just broken cookie in browser, thanks for the report.

Hi Troex,

Thanks for your reply. Isn't the problem the other way around? On my desktop machine, Chrome and Firefox don't have ANY cookie for the app accessed through localhost. So when elfinder.js tries to get a value for "target" from a cookie on the machine, it gets nothing, so connector.php gets an empty string for the value of "target". That's what I was trying to show in my screenshot of the desktop machine with Firefox. Firefox finds the cookie of the app that was accessed from a remote server, but does NOT find any cookie for the app accessed through localhost.

But just to be thorough, on the desktop machine in Firefox or Chrome, I deleted all cookies from the time frame I accessed the app with localhost. This did not solve the problem. (There were no cookies for localhost to be deleted anyway.)

Any other idea of how this can be resolved? Thank you.

Probably if target not found (for any reason) elFinder should try to open root directory. If I understand right you have only one installation of elFinder on the server?

Btw you can try run Chrome browser in incognito mode (ctrl+shift+n) that will disable any cache or previously created cookies. If you have still no success we will try tomorrow to find this bug.

One more thing if this is real big in elFinder it should happen on the demo page as well...

You can set client option "rememberLastDir" to false to disable store last dir in cookie

Can you please also post the connector response when cookie is empty?

Hello Troex and Dmitry,

Thanks for taking time with this on a Saturday. Its great to see an active development team!

You had good suggestions to try. I'll try to address each of them. First, regarding the behavior of elFinder with the official elFinder demo (from your website). On my desktop machine, this demo ran fine, just like when I run my app from a remote server (recall the problem only happens when I access my app through the local server located on my desktop machine itself). When I first pull up your demo in Firefox, I immediately see 2 cookies get created and the demo loads fine. I have attached a screenshot of this.

Second, Troex, my 2 local machines (a laptop and a desktop) each share the same elFinder code since it is saved in my Dropbox folder that is sync'd between them. Each of these 2 machines have their own local server installed on each respective machine (which happens to be the same version of the same server software). This is why I was surprised to see my app, when accessed through each machine's respective local server, work on my laptop machine but not on my desktop machine.

So when I encountered this difference, I had two main concerns:

1. My inability to use my main development machine (my desktop) for my usual workflow - which is to get things working on my local setup, then port it over to the remote server. But more importantly:

2. I wondered if some clients would have problems getting elFinder to load, depending on which server is being used. In my case, it doesn't load when run from the localhost sever located on my desktop machine.

Next, Dmitry, let me address the client option "rememberLastDir". I tried setting it to false, but it did not change the result. If I understand the code correctly (which is quite doubtful!), doing this would not change "target" getting set to the empty string. I was looking at the open call in elfinder.js on line 578:

this.ajax({ 
            cmd    : 'open', 
            target : this.lastDir()||'', 
            init   : true, 
            tree   : true 
            }, 

It appears that if "this.lastDir()" evaluates to false, that the empty string will instead be used as the value of "target". When I look at the code for lastDir(), I see (on line 530 of elfinder.js):

        this.lastDir = function(dir) {
            if (this.options.rememberLastDir) {
                return dir ? this.cookie(this.lCookie, dir) : this.cookie(this.lCookie);
            }
        }

So if rememberLastDir has been set to false, I'm assuming that lastDir() returns false (or null). If that's true, then it looks like "target" would get set to the empty string, even when I set the client option rememberLastDir to false.

Finally, Troex, I will address the connector response when the cookie is empty (which is the main problem we have been addressing). All of the other scripts for elFinder load fairly quickly. Meanwhile, connector.php tries to load for 2 minutes, and then stops trying (I assume the browser stops trying after 2 minutes). I have attached a screenshot showing this and the "response" in firebug.

The next thing I should address is Troex's first suggestion (about 2 posts back) that if "target" is not found for any reason, perhaps elFinder should just try to open the root directory. I can try to modify the code to achieve this sometime in the next day or two. Do you think it would be easiest to handle that in connector.php? Like in the open function in connector.php, if target == '', then just open root?

In summary, it seems that there may be 2 problems to figure out when my app gets run on my desktop machine through it's localhost server:

1. Why no cookie gets created and thus elFinder can properly load, and
2. How should we deal with the case where no cookie is found, and thus "target" gets set to the empty string.

Thanks again for your help. It is greatly appreciated.

I can't reproduce your problem, empty target for elFinder connector is normal - it will return root directory:
http://elrte.org/release/elfinder/connectors/php/connector.php?cmd=open&target=
http://elrte.org/release/elfinder/connectors/php/connector.php?cmd=open
http://elrte.org/release/elfinder/connectors/php/connector.php

All these 3 cases will return the same result - it will open root file directory. If this does not happens with your connector than we probably have problem in a different place.

I have the same issue.
Empty "target".

BUT it works fine locally on my localhost and not working on server.
I tried in many browsers and all the same.
I changed directories and the same.
I moved to another server and the same.

All the time target is blank on servers.

tom

Can you please give real example? or JSON ajax request that makes client to server? This can be captured with FireBug or Inspector

All the time target is blank on servers.
Probably php died
set eroor_reporting(E_ALL); at the begining of php script to see errors

Again me.

As we look at:
http://elrte.org/release/elfinder/elfinder.php.html

We see in Firebug:
http://elrte.org/release/elfinder/connectors/php/connector.php?cmd=open&target=86f5cb53c95c3c749366a641c75a67e3&init=true&tree=true&_=1309274362412

So target has value: "86f5cb53c95c3c749366a641c75a67e3"

and for example on my test there is in firebug:
/elfinder/connectors/php/connector.php?cmd=open&target=&init=true&tree=true&_=1309274486721

So it looks like it doesnt create the cookie and so there is no initiation and no target.

tom

Okay, empty target is absolutely normal behavior for elFinder: http://elrte.org/release/elfinder/connectors/php/connector.php?cmd=open&target=&init=true&tree=true -- it will return

{
"disabled":[],
"params":{"dotFiles":false,"uplMaxSize":"10M","archives":["application\/x-tar","application\/x-gzip","application\/x-bzip2"],"extract":["application\/x-tar","application\/x-gzip","application\/x-bzip2","application\/zip"],"url":"http:\/\/elrte.org\/release\/shared\/elfinder-demo\/"},
"debug":{"time":0.034605979919434,"mimeDetect":"mime_content_type","imgLib":"gd","dirSize":true,"du":null},
"cwd":{"hash":"15adc70a11ae58cbf63c1fab4cb027be","name":"Home","mime":"directory","rel":"Home","size":0,"date":"25 Jun 2011 16:39","read":true,"write":false,"rm":false},
"cdc":
...snip...

My question was that your connector returns the to the browser when target is empty?

php could not die because other things work fine

and these were two different providers

so this example:

http://www.aktinet.pl/t/elfinder.php.html

it is the exact pack of files from the download

there is created folder

http://www.aktinet.pl/t/files/

in connector.php there is:
'root' => '../../files', // path to root directory

locally it works fine but on server not

tom

there is:

{
"debug":{"time":0.00040507316589355,"mimeDetect":"mime_content_type","imgLib":"gd","dirSize":true,"du":null},
"cwd":{"hash":"8ea8853cb93f2f9781e0bf6e857015ea","name":"Home","mime":"directory","rel":"Home","size":0,"date":"28 Jun 2011 20:42","read":true,"write":true,"rm":false},
"cdc":[{"name":"_tmb","hash":"60677103c883dbb4c7067d792e747a2b","mime":"directory","date":"Today 20:42","size":4096,"read":true,"write":true,"rm":true}]}

i change imgLib to "gd" isntead of deafult: mogrify
and mimeDetect to "mime_content_type" instead of default: auto

and i just see the spinner gif

tom

Thanks for example, now I see where the problem is:

$ curl -D - 'http://www.aktinet.pl/t/connectors/php/connector.php?cmd=open&target=&init=true&tree=true'
HTTP/1.1 200 OK
Connection: close
Content-Type: text/html
Date: Tue, 28 Jun 2011 16:48:58 GMT
Server: IdeaWebServer/v0.70

Malformed header from CGI script:
bzip2, a block-sorting file compressor.  Version 1.0.6, 6-Sept-2010.

   Copyright (C) 1996-2010 by Julian Seward.

   This program is free software; you can redistribute it and/or modify
   it under the terms set out in the LICENSE file, which is included
   in the bzip2-1.0.6 source distribution.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   LICENSE file for more details.

So this is _checkArchivers() function which checks for available archivers on the server, for some reason bzip2 redirect it's help message to STDERR instead of STDOUT which breaks headers and hangs PHP until timeout is reached. I heard about this problem before, but there is not straight-forward solution for elFinder 1.x, elFinder2 will not have this bug due to different mechanism.

So there are two solutions:
1. in elFinder.class.php, comment line 1802

// $test = exec('bzip2 --version', $o, $c);

2. Set archivers connector option to correct value of your system, right now I don't have the data and have to check this first.

P.S.: This bug is somehow floating and depends on certain PHP and webserver configuration, so better to workaround it.

I used the first option so i commented line 1802.

Now works fine.

I would never guess what to do ;)

The server is not based on apache but on some other software so probably it was the problem.

And on the other server the problem was that i didnt switch on the php5 via htaccess because that one was still working on php4 by default.

Huge thanks for solving the issue :D

Tom

p.s.

I will delete the tet folder now.

Hello Troex,

What a great find! I was able to make an adjustment based on your last post and it worked on my desktop system when I accessed my app through the desktop's localhost server. When I pulled it up in Firefox, a cookie was instantly generated and the app proceeded to load fine.

For others who are having this problem, I'll clarify exactly what I've done to fix it. In elFinder.class.php, in the function _checkArchivers(), at about line 1802, I commented out one line and added the line "$c = 1;" below it:

      // $test = exec('bzip2 --version', $o, $c);  // comment out this line
      $c = 1;  // added this line

For now, I did not set the archivers connector option as Troex recommended (perhaps the archiving feature may not work on mine right now), but the basics of elFinder seem to be working fine now. Next I will port my app over the remote server to verify things still work there. I will only report back here if there is a problem with that setup.

Thank you to those who have helped to diagnose this problem!