I just upgraded a test site running Drupal 6.14 from Brilliant Gallery 6.x-3.5 to 6.x-3.6. After successfully updating the files as well as running update.php I discovered that none of my galleries displayed images. The html is written to the page but the image link apparently doesn't work because no image loads and there is no valid link on the page (you can only see that the html has been written if you view the source). All my galleries are set up to pull from Picasa, but I tried a test local gallery and it was broken as well.

Here are a bunch of error records from the Drupal database logs (these particular entries happened when I tried to access the test local gallery). There are about three different errors that repeat for each gallery accessed:

Type	php
Date	Monday, November 2, 2009 - 12:21
User	Anonymous
Location	[site root]/sites/all/modules/brilliant_gallery/image.php?imgp=L2dhbGxlcmllcy90ZXN0aW5nL3BlcmlzY29wZTMuanBn&imgw=170&imgh=128&imgcrop=1
Referrer	[site-root]/content/test-story-2
Message	imagecopyresampled(): supplied argument is not a valid Image resource in [server root]/sites/all/modules/brilliant_gallery/image.php on line 180.
Severity	error
Type	php
Date	Monday, November 2, 2009 - 12:21
User	Anonymous
Location	[site root]/sites/all/modules/brilliant_gallery/image.php?imgp=L2dhbGxlcmllcy90ZXN0aW5nL3BlcmlzY29wZTMuanBn&imgw=170&imgh=128&imgcrop=1
Referrer	[site root]/content/test-story-2
Message	imagesx(): supplied argument is not a valid Image resource in [server root]/sites/all/modules/brilliant_gallery/image.php on line 167.
Severity	error
Type	php
Date	Monday, November 2, 2009 - 12:21
User	Anonymous
Location	[site root]/sites/all/modules/brilliant_gallery/image.php?imgp=L2dhbGxlcmllcy90ZXN0aW5nL3BlcmlzY29wZTMuanBn&imgw=170&imgh=128&imgcrop=1
Referrer	[site root]/content/test-story-2
Message	imagesy(): supplied argument is not a valid Image resource in [server root]/sites/all/modules/brilliant_gallery/image.php on line 166.
Severity	error

This is above my pay grade for sure, does anyone have any idea what could have broken everything so badly? Also, please let me know what additional information you need to help, I'm sure this is not enough but am not sure what else I should add. Thank you!

Comments

Vacilando’s picture

Vacilando CreditAttribution: Vacilando commented
Assigned: Unassigned » Vacilando
Status: Active » Postponed (maintainer needs more info)

Did you clear ALL cache on your site? That's crucial.

Check for any telling error messages in your watchdog -- of type 'Brilliant Gal'.

Are all your settings at /admin/settings/brilliant_gallery all right?

If not resolved, go to your Picasa cache folder on the server and delete all its content manually. Then load a page that contains a [bg|...] tag and check whether the Picasa folder is filling up with fetched images.

If still not resolved, post your live URL (if you have any), and specify what is the BG tag that you are trying to resolve on that page.

drpchris’s picture

drpchris CreditAttribution: drpchris commented

I saw this recently after upgrading to a -dev release - it's the cache. Delete your caches.

droller’s picture

droller CreditAttribution: droller commented

Thank you for your help, here's some more info:

(1.) All cache data has been cleared.

(2.) My database log does not contain any errors of the type Brilliant Gal, only seemingly regular notices about it fetching images from the Picasa XML files. The errors in the database are labeled as type PHP and are repeating occurrences of the errors I pasted above.

(3.) I discovered a bit more by reverting back to 6.x-3.5 and then trying to upgrade again (in case I had done something wrong). I was able to confirm that everything is working fine at 6.x-3.5.

One thing I did notice is that the settings page at admin/settings/brilliant_gallery changes between the two versions. At 6.x-3.5 I was asked for a full server path to the Picasa cache folder, and then was given an option to select database or file system caching. At 6.x-3.6, however, I am asked for a path to the Picasa cahce folder that seems to imply a relative path from the sites/default/files directory (the instructions about a full server path are gone). In addition, there is no longer any option to select between database and file system caching. Are these expected changes or has something been corrupted?

Also, when I upgraded to 6.x-3.6 and did not make any changes to the Picasa cache folder path setting (so it still read as a full server path) I got the following errors (repeated for each image in the gallery) when loading any brilliant gallery tag:

# warning: fopen([server root]/sites/default/files/[server root]/sites/default/files/galleries/temp/bg_picasa_ad4eceb1d442d0d5f8ada4c21573366b/[image name].jpg) [function.fopen]: failed to open stream: No such file or directory in [server root]/sites/all/modules/brilliant_gallery/picasa.inc on line 95.
# warning: fwrite(): supplied argument is not a valid stream resource in [server root]/sites/all/modules/brilliant_gallery/picasa.inc on line 98.
# warning: fclose(): supplied argument is not a valid stream resource in [server root]/sites/all/modules/brilliant_gallery/picasa.inc on line 99.

When I change the Picasa cache path to a relative one (from the sites/default/files) directory, these errors disappear.

(4.) Finally, I deleted the contents of the Picasa cache folder and tried to load a gallery (with the cache path specified as a relative path). The images were in fact fetched from Picasa, a database log was created to this effect, and a new folder was created in the Picasa cache folder (so I think this answers my question above about whether or not that change was correct - it seems to be). However, there are no images displayed on my site, I'm back to the original error.

If you'd like to check this out yourself, you can visit an example page at http://bubblycreek.org/preprod/2007/10/head-charles-gravas-party.

Vacilando’s picture

Vacilando CreditAttribution: Vacilando commented

Hi droller. And hi, druchris1; thanks for helping with this.
The difference between 3.5 and 3.6 was quite drastic. Normally I'd put it into a new major version, but there was some need to patch a potential security/privacy problem. See #566178: Security hole: absolute path for more.

Part of the re-work was indeed:
a) change from full server path to your Picasa cache folder to a relative one under your /files folder. See the instructions at /admin/settings/brilliant_gallery under "Path to Picasa image CACHE folder".
b) removal of the file cache setting - I had planned to take it out in 6.x-4 (in fact little impact on speed while complicating the code a lot) but it made sense to remove it as part of the above work.

The remaining question is why do your images not show at that page.
Have a look at the source. The URL parameter 'impg' points to L2dhbGxlcmllcy90ZW1wL2JnX3BpY2FzYV9hZDRlY2ViMWQ0NDJkMGQ1ZjhhZGE0YzIxNTczMzY2Yi8wMWwtcmRhcmlubWVzc2luYW1hcmtrbGl0Z2FhcmRqb2R5a29wbG9icmlhbndlZGVsZGVyZWtyb2xsZXIuanBn which after decoding (e.g. using this tool) give locations like this "/galleries/temp/bg_picasa_ad4eceb1d442d0d5f8ada4c21573366b/01l-rdarinmessinamarkklitgaardjodykoplobrianwedelderekroller.jpg"
Does this look correct? The module will look for this path in your files folder and if the path is correct, it will display an image.

Btw, you seem to be running in a subfolder of a domain - I haven't really tested such option. All my BG installations run on the domain or subdomain itself. You should be able to grab the URL of an image and display it alone -- e.g. at http://vacilando.net/bg there is an image http://parallel-3.vacilando.net/sites/all/modules/brilliant_gallery/imag... (from Picasa) which will display fine if you put it into the browser.

droller’s picture

droller CreditAttribution: droller commented

Sorry, was away from this for a few days.

The path you have decoded is a valid one. I repeated your steps using the tool you referenced and confirmed that the path is valid. Taking that path and entering it into the browser directly (so going to http://bubblycreek.org/preprod/sites/default/files/galleries/temp/bg_pic...) successfully displays the image.

I'm not sure, but this seems to suggest the problem lies somewhere in image.php right? It is being passed a correct encoded path but for some reason isn't displaying the image.

About the sub-directory issue: I am not ruling out a possible role in this because I don't really know enough, but I do know 6.x-3.5 worked without a problem in this environment. Unfortunately, I'm not really ready to take the leap on the main site (the web root) because I don't want to lose all the pictures.

I'll keep playing around, any other suggestions or places to look for problems would be welcome. Thanks again for the help!

droller’s picture

droller CreditAttribution: droller commented

Another update:

I use Hostgator to host this particular domain, and I also happen to have another Drupal site on a separate account with Hostgator. I installed brilliant gallery 6.x-3.6 on this other site (a clean install, as opposed to an upgrade from 6.x-3.5) and am seeing the exact same thing - no images show. So, I installed a copy of Drupal 6.14 on my local computer then installed BG 6.x-3.6 on it. On my local machine, there is no problem viewing the images from BG.

In light of the fact that this problem is occurring across two domains/accounts with the same host but is *not* happening on my local computer I'm thinking it could be a host issue. My problem is I don't know where to go from here. Does anyone know what I should be investigating with Hostgator? What kind of settings would interfere with BG in this way? As another way of thinking about it, what changed between BG 3.5 and 3.6 that could have interfered with the host's settings (because version 6.x-3.5 works fine)? I checked the Hostgator webserver logs, and it has no errors reported.

ericwongcm’s picture

ericwongcm CreditAttribution: ericwongcm commented

Just want to let everyone knows that I am also unable to get Brilliant Gallery 3.6 working properly either........though 3.5 is working perfectly though.

Tried clear cache while 3.6 was installed, still didn't work.......note: 3.6 kinda works but creates all sort of problems......e.g. tiny thumbnails

Update: 2013-07-04
-------------------------
I finally figured out why Brilliant Gallery 3.6 broke my gallery..
I was using syntax like this..
[bg|photo||100||9]

It turns out that Brilliant Gallery 3.5 ignore the missing parameter within || whereas Brilliant Gallery 3.6 doesn't accept it and show tiny thumbnails instead of what I had specified.

My syntax should not have any empty || and should look like this
[bg|photo|9|100|random|9]

droller’s picture

droller CreditAttribution: droller commented

A final update (maybe) because I believe I have solved the problem.

I decided to see if I could trace my way through image.php and figure out what was going wrong. I did this by adding watchdog statements throughout the image.php code so I could examine each variable as it was assigned. Fortunately for me, the problem began developing practically at line 1.

The very first action in image.php is to decode the imgp variable from the URL and assign it to the $urlpath variable. What I noticed is that the $urlpath variable was empty all the time. I tried altering the expression to directly decode a certain string rather than grabbing the variable from the URL and at some point (I don't remember exactly what I did to notice this) I saw a php error about an undefined function for base64_decode. Through trial and error I found that if I moved this function down below the drupalize function (which started on line 16 of image.php) then everything would work fine. Turns out this was the key to everything.

So, after a lot of head banging the solution is simply:

In image.php grab the drupalize function (lines 16-27) and move it up above the $urlpath = base64_decode... expression (line 4).

I'm not sure I have a good explanation for why, and I have no idea how you roll a patch so I'm sorry I couldn't help solve the problem more permanently, but it seems like an easy fix to commit if you believe it won't introduce new problems.

Thanks again to everyone for their help!

daph2001’s picture

daph2001 CreditAttribution: daph2001 commented

Thanks droller, I had the same problem and solved it in the same way.

BTW I am also hosted at hostgator. I wonder if that's related...

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

I had a problem that looks similar, but turns out to be that I was using a path such as ../../../../common/galleries to my (non-Picasa) gallery folders. This has been deliberately prevented for security reasons in v3.6.

It looks to me as if the fix in #8 may be just circumventing a similar security check.

Tony.

saurabh.bhambry’s picture

saurabh.bhambry CreditAttribution: saurabh.bhambry commented

This might have something to do with hostgator. Since a clean install of brilliant gallery works absolutely fine on the local machine. However on a site hosted at hostgator I am facing a similar issue. The solution suggested in #8 fixed the issue for me too. If this results in a critical security breach . Please update

drpchris’s picture

drpchris CreditAttribution: drpchris commented

I can't see initially why moving the drupalize() function changes anything about the initial security check. base64_decode() is a PHP function, and I don't know why the drupal bootstrap code would have any effect on it's availability - it's part of the core PHP function set.

I'm not sure there's any security risk to calling drupalize() first - the only URL stuff that the bootstrap code does is look for the 'q=' part, and that's not included in the normal image.php call. I'd have to check whether putting it in does anything bad.

I'm not clear on why image.php needs to call the drupal bootstrap code either, but that's another question - maybe to assure drupal function availability? Why then doesn't the core module do this also?

drpchris’s picture

drpchris CreditAttribution: drpchris commented

To answer my own question, image.php needs the drupalize() function to do the drupal file includes bootstrapping that happens automatically in the brilliant_gallery.module code. I would argue that this is bad code design - everything should call through brilliant_gallery.module, and the image.php code should be made an include if it wants to be kept in a separate file.

But that doesn't answer the question of why moving the drupalize() function makes those particular installs work.

bshaf’s picture

bshaf CreditAttribution: bshaf commented

I can confirm that #8 solved my problem as well. I will keep tabs to see if a final and confirmed secure patch is made available. Thanks for a beautiful module!

r371769’s picture

r371769 CreditAttribution: r371769 commented

I can also confirm that #8 solved my problem too.

Thx to droller and the maintainer of BG.

Frank

AxelBernhardt’s picture

AxelBernhardt CreditAttribution: AxelBernhardt commented

why not use this

function drupalize() {
    chdir($_SERVER['DOCUMENT_ROOT']);
  /* instead of that ...
  while (!@stat('./includes/bootstrap.inc')) {
    chdir('..');
  }
  */
...
}

??
in my installation i am using symlinks for inserting modules into a project.
in this case the logic in drupalize() cannot work :(

to my case this solved the problem.