Environment:

  • Core 6.26
  • Commons 6.x-2.6
  • Filedepot 6.x-1.2

4 errors are logged each time a file upload is attempted (relative file paths, of course):

  • Type: access denied
  • Location: filedepot_ajax/savefile
  • Message: filedepot_ajax/savefile

  • Type: php
  • Location: filedepot_ajax/savefile
  • Message: You have an error in your SQL syntax; at line 1 query: SELECT p.perm FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN () in /modules/user/user.module on line 528.

  • Type: php
  • Location: filedepot_ajax/savefile
  • Message: array_keys() expects parameter 1 to be array, null given in /modules/user/user.module on line 528.

  • Type: php
  • Location: filedepot_ajax/savefile
  • Message: implode(): Invalid arguments passed in /includes/database.inc on line 253.

  • Type: php
  • Location: filedepot_ajax/savefile
  • Message: array_fill(): Number of elements must be positive in /includes/database.inc on line 253.

The installation was functional before moving from the test (Ubuntu 11.10) server over to the pre-production (RHEL6) server. These errors were not logged on the test server. The test server is still running 6.25 core & the Filedepot install there is still functional.

All files were moved in-tact, and all permissions replicated. To the best of my knowledge, everything is the same, including the path to the physical file repository. The .htaccess files are identical. The physical repository (RHEL server) is completely empty.

The visible symptoms are that the file upload bar rolls across the window, then, in Firefox, just sits there. In Chrome, the page actually redirects, but the file isn't given an icon, & throws a 404 when trying to edit/download it. Top-level folders can be created, but new files can't be uploaded into them.

Comments

t-readyroc’s picture

t-readyroc commented

Further testing has definitely narrowed the culprit to the "filedepot_ajax/savefile" function.

If a user attempts to use the Filedepot UI to upload a file, the behavior is the same as described above (URL is: /filedepot/folder/4). If, however, an admin navigates to the content node through content management > content > nodeitem (URL is: /content/nodeTitle), files can be successfully uploaded by editing the node, using the "browse/upload" functions under "Folder File:." These uploaded files then display correctly in the Filedepot UI, and are able to be downloaded.

More info at the Nextide forum here.

blainelang’s picture

blainelang commented

Are you using any other modules that alter the fieldfield paths or cck field permissions?

If you can eliminate (disable) any other modules other then core or required.

t-readyroc’s picture

t-readyroc commented

Hey Blaine - our testing site is an exact mirror of our production site, save for updates to the core, webform, pdf page converter, chat, & mail handler/comment. Uploading through the UI works just fine on the testing site.

blainelang’s picture

blainelang commented

Well then, that's very odd. I wonder if something wonky occurred during the drupal data migration. I assume you did some sort of backup_migrate operation.

t-readyroc’s picture

t-readyroc commented

Good question. Yes, I did a straight mysqldump of the database & tar/un-tar of the site files over ssh to migrate to the new server.

nibo’s picture

nibo commented

I have the same problem on initial Commons 2.6 installation ...
I can upload files only with the admin account. When I try it with another user account, which has all possible permissions, then I get the "access denied"-Error on filedepot_ajax/savefile.
Could it be some permission overriding issue?

t-readyroc’s picture

t-readyroc commented

Hey Nikolay - this is the behavior we experienced as well. The previous functionality I described on the testing server above turned out to only be whenever I used the #1 account.

nibo’s picture

nibo commented

Hey Travis,
I tracked the issue to the filedepot_user_access() function, where the user_access() function is called, which then executes the incorrect sql query. Than I saw following comment and the solution worked for me (for now): http://drupal.org/node/970388#comment-4243772
Hope this helps!

_timpatrick’s picture

_timpatrick commented
Status: Active » Closed (fixed)
t-readyroc’s picture

t-readyroc commented
Version: 6.x-1.2 » 6.x-1.3
Status: Closed (fixed) » Active

Sorry I haven't been able to get back to this in a while. I've been working with WebFM & dealing with that entirely separate set of issues.

Just checked back in here after the issue was marked as closed. I just now updated the module to the 1.3 version & even applied the suggested fix linked in #8. Uploads still do not work for normal users on our site. Same symptoms as in OP.

_timpatrick’s picture

_timpatrick commented
Assigned: Unassigned » _timpatrick