WebFM is working fine on most of our sites, is refusing to cooperate on one of them. Loading admin/webfm* presents the usual directory and file panels, but both are empty and the WebFM debug pane displays the following:

current directory undefined
tree fetch: { 'status':0 'data':'Unspecified error' }

I've checked and double checked the folder configuration and permissions on the folder but I can't find anywhere it differs from the other installations we have happily running off the same module.

Any ideas?

* Yes, we're still on version 1.11 - we're putting off upgrading due to the number of different sites we have running off the same code base. However, I have tried temporarily upgrading this particular site - using the sites/mysite.com/modules folder - and it returned the exact same error. I've since removed the updated module, uninstalled and reinstalled v1.11.

Comments

robmilne’s picture

robmilne commented
Status: Active » Closed (won't fix)

I wish I could help but my time is so constrained that I will not be addressing this issue. From what info you presented here it looks like the root path isn't set (webfm root directory is manually created in 1.x versions).

kingandy’s picture

kingandy
he/him
commented

Sadly no - the webfm root is both installed and exists in the file system. :|

The only difference I can find at the moment is that the file path contains hyphens (/sites/xxx-xxx-xxx.com/files). Would that throw off the directory reading part at all? I'm probably grasping at straws...

robmilne’s picture

robmilne commented

It is nearly impossible to diagnose these things remotely. My only suggestion is to use firebug to capture exactly what is being posted and returned via ajax during the startup of the module. If nothing useful can be gleaned from firebug then all I can suggest is debugging the webfm.module with print_r and echo statements. I'm sorry that I cannot be more useful.

kingandy’s picture

kingandy
he/him
commented
Status: Closed (won't fix) » Active

I have a clue!

Luckily (!) the bug popped up on another of our sites (one without hyphens in the path), and I spotted a commonality - both sites used the Internationalization module.

Switching i18n off on the second site appears to have fixed the problem but unfortunately the original site requires this module. the second site no longer has a requirement for i18n but we hadn't got around to switching it off yet).

I suspect it's the part of the module that meddles with URLs (each path is prefixed with a language code - eg http://example.com/node/1 becomes http://example.com/en/node/1 for English or http://example.com/fr/node/1 for French), which could potentially interfere with callbacks...? Omitting the language code generally seems to trigger a redirect to the path for the current or default language, I don't know what impact that would have on a jQuery call.

Does that give you something to go on? It's not much but it's all I have right now...

robmilne’s picture

robmilne commented

Ok, I just installed i18n and added French, translated a node and have been switching via the i18n block with no detrimental effect on webfm (V2.6). I didn't give it a thorough test drive, however, the language insertion into the url isn't causing a problem that I can see.

kingandy’s picture

kingandy
he/him
commented

Bother - I've now also tried activating i18n on another site (which already had WebFM active) without causing any problems. I really thought I had something there, it was definitely what fixed today's site (I even switched it on and off a few times, and WebFM came up and down with it).

I see there is a newer release of i18n than the one we have, though, so I will try upgrading and get back to you.

Could it be something to do with the order of installation?

kingandy’s picture

kingandy
he/him
commented

FWIW, I've upgraded both i18n and WebFM to the most recent releases (and run update.php) and am still experiencing the same problem.

The debug output is slightly different, it doesn't complain that there's no current folder and appears to be looking for trees, plural, now:
trees fetch: { 'status':0 'data':'Unspecified error' }

robmilne’s picture

robmilne commented

My theory is that no trees were found.

To confirm this, replace line 902 of webfm.module with:
webfm_json(array('status' => FALSE, 'err' => t('no trees found')));

chriszz’s picture

chriszz commented
Version: 5.x-1.11 » 5.x-2.6
Priority: Normal » Critical

i confirm the problem with i18n and webfm.

chriszz’s picture

chriszz commented

I tried this:
To confirm this, replace line 902 of webfm.module with:
webfm_json(array('status' => FALSE, 'err' => t('no trees found')));

But i only get this:

trees fetch: { 'status':0 'data':'Unspecified error' }

robmilne’s picture

robmilne commented
Status: Active » Postponed (maintainer needs more info)

I still cannot replicate the issue on my own test site. I'm hoping the original poster of this issue can give me more clues why some i18n sites work with webfm and others don't. Is there specific functionality or components of i18n that cause the conflict?

chriszz’s picture

chriszz commented

It works now for me - cannot replicate either anymore. Do not understand, what happend - but it works now!

teebo’s picture

teebo commented

I'm out of luck because on my site it's not working....
I have WebFM 2.8 with Localizer 3......

Anyone find a solution?

andremolnar’s picture

andremolnar commented

As you may know Drupal 6.x version is available for testers - and I tested to see if this occurs with the 6.x core i18n set up. The good news is that I can't produce this error with internationalization turned on. Bad news is that this is in Drupal 6.x (apples) vs Drupal 5.x (oranges).

Worse news is that even in 5.x we are getting mixed results and this error is difficult to reproduce.
Has anyone else been able to both reproduce the problem AND done some more investigation via firebug?

andre

vanhanit’s picture

vanhanit commented

I too had the problem that WebFM couldn't perform any actions through the AJAX functions.
Discovered, stated before, that the Localizer modulen indeed is the one that breaks this.
It rewrites the path from webfm_js to something like en/webfm_js and in the process all the posted data from the JavaScript is blanked.

I solved this, and probably some other problems to, by adding a check for posted data to the function localizer_change_language() in the localizer.module file.
I added this snippet to the beginning of the function

if($_POST && count($_POST) > 0) {
  return;
}

This is actually a Localizer problem and therefore it should be patched.

I just noticed that this problem is fixed in Localizer version 5.x-3.4. Upgrade recommended.

lambertnet’s picture

lambertnet commented
Version: 5.x-2.6 » 6.x-2.9-alpha2

I had the same error - the Global Redirect module is not compatible with WebFM. I have now disabled it and all works fine.

kingandy’s picture

kingandy
he/him
commented
Version: 6.x-2.9-alpha2 » 5.x-2.6

Ahhhh Global Redirect! My old nemesis.

This does seem to have resolved the issue on my i18n'ed 5.x-2.6 install as well. It turns out i18n and GR also don't play well together when browsing to root in a foreign language, so I'm perfectly happy to switch that off!

... Should this be updated to Won't Fix or something?

nhck’s picture

nhck commented
Status: Postponed (maintainer needs more info) » Closed (fixed)

Thank you all for reporting this. If you still have this problem, please reopen.

Thank you.