Can't upload images

My first guess would be that you didn't properly configure filemanager and acidfree before trying to upload the image. Make sure the directory settings in admin/settings/filemanger are okay and that permissions are web-writeable for that directory AND for the directory in admin/settings/acidfree.

I am also not able to upload pictures into an album. First i clicked on submit instead of preview button as the instructions said so and i did get this error when i hit the submit button.

Fatal error: Only variables can be passed by reference in /var/apache2/www/modules/filemanager.module on line 390

But i click on preview button i can see the uploaded picture as preview. Finally i am not able to upload the picture as i get the above error when i click on submit button.

I did check the "private" dir for filemanger.module and it seems to be ok as i did not get any error when i save the settings for filemanager module. Here is some of the files list in my drupal location. Note: webservd is owner of apache2 daemon.

# ls -la
total 170
drwxr-xr-x 11 root root 512 Oct 14 00:22 .
.......
.......
drwxr-sr-x 2 302 302 512 Aug 14 17:50 database
-rw-r--r-- 1 302 302 8430 Jun 11 2003 favicon.ico
drwxr-xr-x 4 webservd webservd 512 Oct 15 21:52 files
drwxr-sr-x 2 302 302 512 Aug 14 17:50 includes
-rw-r--r-- 1 302 302 595 Aug 20 2004 index.php
........
........
drwxr-xr-x 2 webservd webservd 512 Oct 15 21:46 private
.......
.......

Thanks

i'm seeing the following error also whenever Admin or a user tries to logout from the site:

Fatal error: Call to undefined function drupal_get_path() in /var/apache2/www/modules/acidfree/acidfree.module on line 112

I deleted the empty album created as a previous step and the error still comes up.

undefined call to drupal_get_path() is because your cache is enabled. Caching does not work with acidfree for right now. It is listed in the known limitations list on the acidfree module page. Go to admin/settings and disable your cache.

As for the fatal error in filemanager.module, I think this is a configuration setting of yours. Are you running php5? And what errors is it set to report? (check php.ini for error_reporting variable) I cannot reproduce this error, but looking at the code, I wonder if it is caused by php trying to pass something as a reference that is not actually a named variable. The function file_move is being called with the first parameter as a return value of a function, while file_move wants to have the first variable passed by reference.

Technically, this error would be caused by a filemanager bug, but I doubt they would respond well if you are telling them you are using a patched version of their module...

I just posted some additions to acidfree. Either download the latest version from my website (http://vernon.mauery.com/projects/acidfree/4.6/acidfree-4.6.tar.gz) or get it from http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/modules/ac...

The addition I would like you to see is the built-in self-test function. Direct your browser to the acidfree/test page and you will see the results of the test. It will help with directions to fix any problems it finds. If that doesn't fix you problem, I will add a test that discovers your problem when we figure it out. That way, future
users will benefit from this bug.

I really hate answering the same question over and over, so I wrote the self test. It tests all the problems I could think of that I have answered in the recent past. So maybe it will help with yours.

Yeah, so I ran the "self test", and I'm still having problems. Sorry to make you answer things over and over again. However, it seems that somehow, between the filemanager.modlue and the acidfree.module files are being added with an incorrect owner or something, because when I try to upload pictures, they make it as far as the /files/active/0 directory, but they are then trapped because they have "nobody" as a user & group and are set 744, even though the containing folder is set 777 (and man does that bother me).

The thing is that no other module running with filemanager.modlue has this problem. If I can help debug in some way, I would, but I don't know where to start. Where are the file saves & such made? Is there some way to ensure their file permission access?

The /files directory should only have to be set as 755 or 775 (depending on the owner and group). It should be owned or part of the group that apache is in. For me, this is www-data. When files get created on my machine, they get created as 644, with the owner and group www-data. And you are saying that files created by other modules with the filemanager are different owner/group and permissions? This is very curious indeed. Acidfree just uses the standard filemanager_add_file function, which in turn calls file_copy (in the drupal core), which eventually calls php's copy function. From my experience, when you do a copy, it sets the owner/group as the user doing the copy and the permissions as whatever the ulimit mask is set to. So I am baffled.

What user is apache running as? Are you running php in safe mode?

The filemanager and acidfree paths are all relative. In fact, the acidfree path is relative to the drupal files path. So don't set them to be absolute. After you have saved the settings, you should probably go to the acidfree/test page to have acidfree test the settings and filesystem permissions. If it finds an error, it will tell you what you need to do to fix it. If it says everything is okay, chances are that it will work for you.

From the error you are encountering, I am guessing you have a "Resolution of full size image" set to something other than "no maximum" on the admin/settings/acidfree page. Is this right? This is an known limitation of Acidfree that I will fix when I get the time. But because it is very minor compared to some of the other bugs I am working with, it might be a while.

If I guessed wrong, I am stumped and will have to think of something else.

ok vernon, I *should* have chimed in sooner. this may or may not help... but I've been having a VERY similar problem. (SAME error message). it has been ongoing... and perhaps less annoying.

setup:
I don't host my drupal site on my own server (shared HSP). it is also under CPANEL (for what its worth - might explain a little about cinfiguration). my host told me this about permissions:

Anything which needs writable should have permission 777 or user/owner nobody according to our php configuration. We dont implement PHPSuexec on our servers which runs php scripts under your ownership.

problems:
i have two ongoing problems with acidfree (that i know of). video & zip files. i suspect both are related to permissions somehow. here's what Im seeing.

1. upload video. looks like it works, but i get this error:

warning: getimagesize(): Read error! in /home/foo/path/public_html/pix/modules/acidfree/class_video.inc on line 220
i should also note, i get the above error on EVERY page, AFTER uploading a video.  

if i play the video... nothing. if i click "download" i get page not found and my browser address bar changes to: http://pix.MyDomain.com/files/active// (notice the DOUBLE slash. )

I can't find the file uploaded anywhere on the server. hmm. all seems consistent that the file is not being writen/copied somewhere... but no error or message on the upload... and no obvious clues in the database as to where this should be stored. what table holds such info? file? no table row here. and acidfree table has empty cells for large, small, & thumb which appear to be references to file table.

my guess is a directory needs to be created by acidfree, but it isn't... and a null is written to URL (i am using clean URLS - not sure what it'd look like otherwise). note: I mentioned before that I had to manually create "0" directories in active and working directories... suspect I'll need to create "1" "2" "3" ... etc, and think that's whats happening now.

2. zip files... different error message... but i think probably related

Archive: /tmp/php4OGQgA inflating: /home/foo/path/public_html/pix/files/acidfree/tmp/massonnYCk/IMG_0294sm.jpg

warning: rename(/home/foo/path/public_html/pix/files/acidfree/tmp/imagemanipoFGyRu,files/working//): Not a directory in /home/foo/path/public_html/pix/modules/acidfree/image_manip.inc on line 51.

*** NOTE: IN THE PROCESS OF GATHING INFO FOR THIS POST I FINALLY JUST RESOLVED THE ZIP PROBLEM. IT WAS IN FACT PERMISSIONS. the working/0 subdirectory was at 775 -- change to 777 and all is well with zip. sadly, no effect on my problem with video. DANG! I've got a funny video to post! :P

Are your post_max_size and upload_max_filesize set appropriately in your php.ini file? This is usually the #1 hangup with video uploads and archive uploads. They are just too stinking big. You just convinced me to put that in as part of the acidfree/test page. I just added it to the CVS repository for both HEAD and 4.6.

What are your settings for thumbnailing videos? The error on line 220 of class_video.inc is trying to find the thumbnail for the video. But if you can't even download the video with the link, I think we really have bigger problems that just thumbnailing. Grab the latest acidfree.module from http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/modules/acidfree/acidfree.module?rev=1.2.2.33 and run acidfree/test to see what it tells you. It should also spit out some php.ini info.

the extra output in the acidfree test is what i needed, thanks! (suspect it'll really help out someone in the future).

i had been using an extremely small video file... but apparently still about 300k too big. my Maximum file upload size is 2M (upload_max_filesize). my test file ws 2.3M

i hadn't checked the php settings previously, because gallery2 worked with the same file. Im assuming this is because gallery2 has a ini_set(upload_max_filesize) to match a max size setting (that overrides my hosts measily little 2M setting).

oh wait... i JUST got an email from my host... they said override is disabled... (not running in phpsuexec cgi mode). now I dont know why the SAME small test file worked in gallery2 but not acidfree. hmm.

regardless... it seems to be working now.

From what I can tell by re-reading this bug, the problems have been resolved, so I am closing it. Re-open this bug or open a new one if problems persist.