Upgrading to 6.x-3.6 broke all galleries

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.

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

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:

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.

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.

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!

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.

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

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:

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!