Parent album drop down not showing

I'm haing the same issue, but haven't made any progress yet. I tried to import from the local filesystem. This is a brand new install of drupal 4.7.3 with the 4.7 versions of both filemanager and acidfree. Those are the only non-standard module active.

I did notice that if I upload a single image using the "acidfree photo" tab, I can see the photo right after it's uploaded, but not after that. I get a node page with just the image title. The title is linked to "http://drupal.chrismillerstuff.com//active/0/tmp333094984_large.jpg", which doesn't exist. I find it suspicious that there are two forward slashes in that link. Also that the filename starts with "tmp" - not sure what it means, but possibly related to the issue.

Fix here...

http://drupal.org/node/85233#comment-156452

Points 3 and 4 of the original bug can be fixed by setting the correct public files URL in the filemanager settings. For example, my public folder is "files", so my public URL is "http://drupal.chrismillerstuff.com/files". It's not set by default - so you need to do it.

Point one could probably be fixed by adding more "official" node types for each class, but I'm guessing the author didn't want to clutter anyone's install. hook_node_info currently tries to guess the class from the current path, so when you're looking at the content listing in the admin, it basically chokes and says that everything is an album.

Can anyone point me to instructions on generating a proper module patch?

I don't clearly understand why anybody contributes something which does not even work.

What kind of programmer behaviour is to publish something without running at least one test and wasting a lot of people's time?

Is there anybody who could explain this to me?

Are you talking about the module, or the fix I proposed?

If you're talking about the fix, can you give more details?

I think the module was probably never tested on a clean install, but rather an old install that had albums in it already. That's the only case where the parent album dropdown would not show.

Lityi,

Not too long ago, there was a thread on the drupal-devel mailing list about people saying things that were rude and out of place. The things you said in comment #5 fit right along in that category. If you don't have anything nice to say, don't say anything at all.

Drupal is an open source project. I don't get paid a dime for working on or contributing for Acidfree. If you were a paying customer, you might have more of a right to expect things to always work perfectly. Frankly, it is comments like yours that drive great contributors away from great projects. It is incredibly frustrating to have spent literally thousands of hours working on a project just to have someone say:

What kind of programmer behaviour is to publish something without running at least one test and wasting a lot of people's time?

You don't think I tested it? Well maybe next release I won't test and see if that works better for you. Like I said, I have spend thousands of hours, working unpaid, on Acidfree: planning, designing, coding, testing, coding, testing, coding, and testing. Oh, and did I mention that I tested it too? Acidfree happens to be an incredibly complex module and I don't have the resources to test EVERY feature EVERY release I make. I am the only consistent active contributor for Acidfree, though several others have been good at helping out in forums and supplying patches and features. There are thousands of users and a single unpaid programmer.

Maybe rather than wasting my time reading your complaints about how it is broken, you should write a fix for it and post the patch to this issue.

vhmauery,
I have been watching the Acidfree forum since some time already. It is certainly one of the best manteined module and you managed to follow everyone's request/contribution (this is not the case for all the modules).
That's just to remind that everybody's work here is very appreciated :)
Regards,

criznach,

I applied the fix you posted to the forum. For future reference, http://drupal.org/diffandpatch has info about how to create a patch (and has links on how to apply, etc.) Look for acidfree version 1.62.2.54.

jorisx,

As per point number 1, this will not change in 4.7. All Acidfree nodes are the same type. It was a design decistion that came back to haunt me. In 5.0, Acidfree will be using pre-defined Image and Video node types from the respective modules. So your problem will be solved then.

As per points 3 and 4, it sounds like a filemanager configuration problem. Have you managed to fix this yet? I am going to mark this as fixed, since the points have been addressed. Feel free to open it up again if you still need help.

Acidfree looks like exactly what I need for my site, but I am having a similar problem. I can upload files, create albums, etc without problems. But when attempting to rotate an image, I get the error:

The selected file [path/filename.jpg] could not be uploaded, because the destination /[path-to-files-directory]/working/0/[filename].jpg is not properly configured.

On my server, a file called "working" is being created by Acidfree (or possibly by Filemanager) in my "files" directory. Owner and group are "apache" and permissions are 664 .

In my ftp program, "working" is showing up as a file rather than a directory. (AFAIK in *nix systems there isn't really a distinction, but other directories DO show up as directories rather than files, and this one seems different.)

I have tried re-naming the "working" file and creating a new directory with permissions 777, but to no avail.

A directory called "working" is also being created inside the "private" directory. That directory does show up in my FTP program as a directory. It has permissions 755 (owner and group are "apache").

I am using Drupal 4.7 on GNU/Linux (shared hosting environment) with Imagemagick enabled.

Thanks for all the work people have put into this module (designing, debugging, and supporting novices like myself). Any help would be greatly appreciated!

I am far from an expert, but it seems like this might be a permissions/ownership issue.

I changed my download method (at administer->settings->file system settings) to:
Public - files are available using http directly.

And I UNchecked Force all new images to be transferred by Drupal (at administer->settings->acidfree)

Now instead of errors involving the "working" directory (noted in my previous post), I get only the following errors:

* The selected file [path to files directory]/tmp/acidfree/imagemanipvvrTgb.jpg could not be uploaded, because the destination is not properly configured.
* The selected file [path to files directory]/tmp/acidfree/imagemaniph8VkWW.jpg could not be uploaded, because the destination is not properly configured.

That acidfree directory is owned by "apache" and its permissions are 750. It seems to be created by the acidfree module.

I'd still like to have the ability to use the settings that allow access control (i.e. use "Force all images to be transferred by Drupal" and "private" download method). But maybe this will help to diagnose the problem...

Thanks again to anyone who can help!

isaac77,

You need to make sure that the filemanager paths (admin/settings/filemanager) are all subdirs of the drupal file system path (admin/settings).

The 'destination is not properly configured messages come from the drupal file handling when it is told to write a file outside of the drupal file system path (or subdirs).

THANK YOU! THANK YOU! THANK YOU!
That did it... I had created a separate directory for "filemanager_files" outside of the drupal "files" directory based on advice from a forum post.

In case any other relative newcomers are having trouble, here's the setup that finally (FINALLY!) worked for me:

(using drupal 4.7, mySQL with gnu/linux shared hosting plan. Note: I am NOT an expert, so take this advice with at least a few grains o' salt)

drupal/sites/sitename/files/
Manually created this directory. I had to set permissions to 777, but this is not a good idea in terms of security. Use more secure settings if you can, or otherwise do something with htaccess to make the directory more secure.

*** (possibly) important ***
drupal/sites/sitename/files/tmp/
I manually created this directory before specifying the location in "Admin->settings->file system settings". If you do not create his directory yourself (via FTP, SSH, etc.) drupal will create it for you, and I think that _might_ create some permission problems in certain cases.

drupal/sites/sitename/files/public
created this manually, then specified the location under "Admin->settings->file manager" Be sure to use full path when specifying the directory (see install notes for filemanager). And make sure this directory is inside the "files" directory.

drupal/sites/sitename/files/private
created this manually, then specified the location under "Admin->settings->file manager" This is not the ideal location for this directory; put it in a non web-accessible location if you can.

It is fine for the private dir to reside in a path like drupal/sites/sitename/files/private. Then you just need to make sure that Apache knows to not allow direct access to files in that dir (or subdirs).

Something like this in the vhost section for that site.

    # deny stuff from the private filemanager filestore
    <Directory /path/to/drupal/sites/*/files/private>
        Order Deny,Allow
        Deny from All
    </Directory> 

Make sure the * is in the path at the sites spot, or they can use a cross-site reference to get file drupal/sites/a/files/private/a.jpg from site b or vice versa. The * doesn't allow access to ANY of the private stores from this vhost (make sure this stanza is in ALL vhost setups).

the most common way to have a user select an album is to have them use the quick links block. This block gives them links to add an image to this album with urls like:
http://mydomain.dom/drupal/node/add/acidfree/album/97
http://mydomain.dom/drupal/node/add/acidfree/image/97
http://mydomain.dom/drupal/node/add/acidfree/video/97
http://mydomain.dom/drupal/node/add/acidfree/mass/97

These will automatically select album 97 to be the parent album of the newly added items. This is a reasonable approach. If your users have problems filing stuff, you might have to educate them on. I wrote this software to be simple enough that my mother-in-law could use it, and she does without problem, despite the fact that she is not technically savvy.

So with that, I think this bug is closed.

I'm having a weird kind of error with the parent album and new users and was wondering if anyone could point me to the fix. Basically I had the site previously setup where new users got their own album and could post in it,... and up until just a little bit ago it was working fine.

The problem I’m having now is when new users sign up and go to add an album or photo to an album, the "parent album" dropdown is completely non existent on the submission form. This creates a weird error where they can still upload images or create albums but aren't included in their per user top album. Users who already signed up prior to this error can still see the "parent album" drop down and it appears to be working fine for them.

I noticed these problems after installing the buddy list module, and finding it suspicious i uninstalled that module and it went back to working fine for a while until just a day or two ago. Is this connected to some kind of odd permissions error? or database error? does anyone know what would be causing the parent album dropdown to simply not be displayed for new users?

In combination with this problem it has come to my attention that new users who haven't authenticated themselves threw email can still go ahead and create content uploading albums and photos while they should not be able to until they authenticate themselves through email. The main thing that is bothering me is that it was working just fine up until just recently and I’m wounding if it is because of conflicts with new modules I’ve recently installed. Are there any known modules that have conflicts with acidfree?

I would greatly appreciate any help or suggestions on this problem.

After recently installing Acidfree HEAD to a new 5.0 site (with filemanager HEAD & Video 5 installed first), I am also struggling with the parent drop-down issue - e.g. a required field for Parent exists with no dropdown selections present yet. I know that vhmauery incorporated criznach's fix already, but I looked through the module anyway and was unable to locate anything similar/equivalent so perhaps this has another cause. My PHP skills are still undeveloped, but I suspect I could create a parent to work around this (by creating a page with a PHP input type) if I knew the code required.

Until another fix or patch is offered, can anyone help me hack my way around this problem?

Drupal 5, Apache 1.3.37, PHP 5.1.2 MySQL 4.1.16