I have successfully installed Acidfree 4.6.0 into a working 4.6.0 drupal site. I've applied its patch to the filemanager module, created its mysql tables and verified their existence and proper load, enabled the module, set the accesses, and attempted to use it.

Upon creating a new Acidfree album, it appears in "content" as an "Acidfree media"-type node. Attempting then to add a photo, the photo uploads and appears as a Drupal node, but it is not tied to the Acidfree media album. Upon accessing the photo, the following two SQL errors appear:
---

user error: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '&& class!='album'' at line 1
query: SELECT COUNT(*) FROM acidfree_hierarchy INNER JOIN acidfree ON child = aid WHERE parent = && class!='album' in /var/www/localhost/htdocs/includes/database.mysql.inc on line 66.

user error: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '&& class!='album' ORDER BY weight ASC, aid ASC LIMIT 0, 1' at l
query: SELECT child FROM acidfree_hierarchy INNER JOIN acidfree ON child = aid WHERE parent = && class!='album' ORDER BY weight ASC, aid ASC LIMIT 0, 1 in /var/www/localhost/htdocs/includes/database.mysql.inc on line 66.

No newly-created albums show up as child nodes to the top-level album. In the drupal "acidfree" table, the top-level album has parent "-1" but subsequent albums show only "Root" as a selection for parent on their creation page, and their parent in the "acidfree" table is "0".

Additionally, and possibly unrelated, is the fact that a photo added to any album does not show up in the album, but only under "Recent Posts." When selected, its thumbnail appears, but an error occurs when the photo is called up, Manually adding a "?" to the URL brings up the full photo, even though I have clean URLs enabled.

Comments

vhmauery’s picture

vhmauery commented

I just set up a new sandbox to play in so I could start from scratch. I could not duplicate this bug.

What happens if you clean up and start over?

Mysql cleanup:
truncate acidfree; truncate acidfree_hierarchy; delete from node where type='acidfree'; delete from file where area='acidfree';

If acidfree is the only thing using the filemanager, you can just delete the working and active directories.

Now when you try again, does it do the same thing?

As for things showing up in recent posts, is acidfree stuff set to be promoted to the front page, or am I not understanding?

rxfelix’s picture

rxfelix commented

I have executed cleanup as you describe, and the filemanager module has been patched properly. I have unpacked the acidfree-4.6.0 tar file in to my modules subdirectory and modified the owner as apache:apache. Now:

1. I enable the acidfree module (no throttling).

2. I check acidfree settings. I see that the "Location of acidfree media" setting asks for a relative path from my sites/files directory. I have no sites/files directory, so I create one at htdocs/sites/files and another acidfree directory at htdocs/sites/files/acidfree. This may have been an issue before, as my "files" directory is under htdocs, not sites. I set ownership to apache:apache for both new directories. I leave the setting as "acidfree" with no trailing slash and change no other settings.

3. I set access control for registered users to import, create albums and elements, and edit own elements.

4. I attempt to create new content - an album. I get the "first use" notice that: No Acidfree root album found, created new root -- node 15588. I then create a new album as node 15589.

5. All seems to be working. I create a sub-album and add five pictures. Now, though, when clicking on a picture thumbnail, I get the following SQL error:

user error: You have an error in your SQL syntax.  Check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISTINCT(n.nid) = '15590from=0,2'' at line 1
query: SELECT n.*, u.uid, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid WHERE DISTINCT(n.nid) = '15590from=0,2' in /var/www/localhost/htdocs/includes/database.mysql.inc on line 66.

warning: Cannot modify header information - headers already sent by (output started at /var/www/localhost/htdocs/includes/common.inc:384) in /var/www/localhost/htdocs/includes/common.inc on line 192.

The URL in question is:

https://www.felix.org/node/15593&pid=15590from=0,2

I can fix it manually by adding an ampersand before "from":

https://www.felix.org/node/15593&pid=15590&from=0,2

Enough for now -- will hit this again later.

rxfelix’s picture

rxfelix commented
Title: Acidfree SQL Errors » Trying with CVS version

I've replaced the acidfree-4.6.0 group with the acidfree-cvs group. This solved the URL problem when clicking on an album thumbnail to access a photo. However, now the thumbnails are wrongly sized. The album random photo is now larger than the album icon when viewing albums, and in the album view with multiple photo thumbnails, the grey backgrounds to the thumbnails are now too large.

After deleting and recreating the parent album, the system is locking up. Will start from scratch as before, cleaning all but using the cvs version.

rxfelix’s picture

rxfelix commented
vhmauery’s picture

vhmauery commented

I just fixed a bug in the cvs version today -- deleting a picture using the album contents view will delete all the photos on that page. You might want to update it again. :) I will see if I can fix the error from comment 2 in the 4.6 branch too. Thanks for your patience. As always, it seems to work fine for me, it is everyone else who sees the bugs.

rxfelix’s picture

rxfelix commented
Title: Trying with CVS version » Acidfree SQL Errors

I think I've localized the original 4.6.0 SQL error problem that manifested when clicking on a thumbnail within an album. Recall that the error was:

user error: You have an error in your SQL syntax.  Check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISTINCT(n.nid) = '15604from=0,0'' at line 1
query: SELECT n.*, u.uid, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid WHERE DISTINCT(n.nid) = '15604from=0,0' in /var/www/localhost/htdocs/includes/database.mysql.inc on line 66.

warning: Cannot modify header information - headers already sent by (output started at /var/www/localhost/htdocs/includes/common.inc:384) in /var/www/localhost/htdocs/includes/common.inc on line 192.

The error resulted from an incorrectly-generated URL on the album display page:

https://www.felix.org/node/15606&pid=15604from=0,0

It is still an unknown problem in the acidfree module, but the reason that some see this and other don't is that it is affected by the output_buffering setting in php.ini. When output_buffering is off (the default setting), the problem occurs, but when output_buffering is off, it does not.

Quoting from "Beginning PHP 5 and MySQL" by W. Jason Gilmore:

"Cannot add header information - headers already sent"

"These messages occur when a script attempts to modify a header after it has already been sent back to the requesting user. Most commonly, they are the result of the programmer attempting to send a cookie to the use after some output has already beensent back to the browser, an impossibility because the header (not seen by the use, but used by the browser) will always precede that output.... When enabled, output buffering tells PHP to send all output at once, after the script has been completed. This way, any subsequent changes to the header can be made throughout the script, because it hasn't yet been sent...."

This would make sense, because the SQL statement is missing a character.

Hope this helps. Again, this applies to the 4.6.0 version. I've backed away from the cvs version for now, fearing for now its use of the hook_node_info() function.

vhmauery’s picture

vhmauery commented

These SQL errors are different than the original. I could not reproduce the original ones. The sql error you are reporting now has been fixed in CVS for a day and a half (I fixed it as soon as you pointed it out). But it seems that the 4.6 release doesn't automatically re-generate itself... The same fix is applied to the CVS 4.6 branch, but it hasn't been repackaged. I guess I need to look into how that works.

The CVS version won't work in a 4.6 branch anyway because among other things, the pager argument changed from 'from' to 'page'. But you could go to the CVS web and download the fixed 4.6 files. Just download these two files and replace the old ones.

http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/modules/ac...
http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/modules/ac...
http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/modules/ac...
http://cvs.drupal.org/viewcvs/*checkout*/drupal/contributions/modules/ac...

This will bring you up to date with the CVS 4.6 branch.

vhmauery’s picture

vhmauery commented
Status: Active » Closed (fixed)

These errors are fixed in the latest available code. Closing.