table populated with image tags, but they don't display

Post links to your gallery pages, or screenshots, or mail me the html dump of them.

Since it's on your local site, we can't test it.

Try going to the links in the gallery.

Does http://localhost:8888/cms/files/albums/tbug/101_0510.jpg show?

And what about this one:
http://localhost:8888/cms/sites/all/modules/brilliant_gallery/image.php?...

It will be simply a path issue, I think.

What's set up as album folder in the BG settings?

And what tag have you used to get the html you posted?

I have just installed this module as it is exactly what I am looking for. I am also having this issue.

My test page is at http://www.seangates.co.uk/node/279

weird. i'm also having this issue. it works on my dev site, but when i move things to production, the galleries break. i think it has something to do with BGs caching mechanism. i'm going to do some digging this morning to see what i can figure out!

i just wanted to follow up on this. my gallery page is at:
http://www.lapetitefleuronline.com/test-gallery

the img tags are pointing to a src of http://www.lapetitefleuronline.com/sites/all/modules/brilliant_gallery/i...

as you can see, nothing is coming up. i originally thought that it might be a caching issue, so i cleared out the cache table in mySQL. still no dice. this is on a windows server running apache.
my dev server (where it works), is apache on OS X 10.5.
are there any other requirements for brilliant gallery aside from the pre-requisite modules?

I have now got this working. I had to chmod 755 modules/brilliant_gallery/image.php

I have about the same issue. I chmodded image.php to 755. That doesn't do the trick for me.

If I call the img url, which is:

http://www.bakelbos.nl/modules/brilliant_gallery/image.php?imgp=L2hvbWUvYmFrZWxib3Mubmwvd3d3L2ZpbGVzL2FsYnVtcy9zaW50bWFhcnRlbi8xNy5qcGc=&imgw=150&imgh=149

I get the follwing message:

Unsupported database type

The database type is unsupported. Please use either mysql for MySQL 3.x & 4.0.x databases, mysqli for MySQL 4.1.x+ databases, or pgsql for PostgreSQL databases. The database information is in your settings.php file.

For more help, see the Installation and upgrading handbook. If you are unsure what these terms mean you should probably contact your hosting provider.

I have php5 and msql5.

I have 2 other drupal site running (with the same (shared) code base but without BG) and the do just fine.

hey i think i may have found the answer...at least in my situation. hopefully this helps you too.
in modules/brilliant_gallery/image.php search for the line:

$result = mysql_escape_string(base64_encode(serialize(array($head, $result))));

and replace it with:

$result = base64_encode(serialize(array($head, $result)));

let me know if that helps!

crap....nevermind, that wasn't it. still searching...

@zbricoleur:

The property "imgp" in the second URL points to (decoded): /Applications/MAMP/htdocs/CMS/files/albums/tbug/101_0510.jpg

Is that the valid path to the image?

The first URL (which you say works) contains "cms" in lower case, while this one is in upper case. Perhaps that's where a problem is. Any comments?

Cheers,

Tomáš

PS The 'filectime' issue occurred because the image could not be found. So if the path is corrected, the filectime error will disappear as well.

I'm having a similar issue, but mine is only effected in IE7. The gallery works fine in every other browser I have tested. In IE7 nothing appears though.....

This is weird.

I'm having exactly the same problem, both in IE7 and Firefox 1.5.0.3

Would love to know if there's an update or solution?

I've done a bit more digging. After doing a decode of the file string, it looks like the thumbnail is calling:

C:\apache2triad\htdocs\yourwebsite\files\gallery\testgallery/DSC_2246bw.JPG_duotone.jpg

Note that all are back-slashes except the last one, which is a forward slash.

Sadly, I'm not clever enough with PHP to fix the necessary code, but at least I know why the error is occuring and it seems a pretty straight-forward fix. If anyone is clever enough to know which bit of code I need to update to make this work, I'd be very grateful!

Just a slight further update. After playing a little bit more, I find the following behaviour:

If I correct the path to read:

C:\apache2triad\htdocs\yourwebsite\files\gallery\testgallery\DSC_2246bw.JPG_duotone.jpg

and manually encode it to Base64, then run it as the input to image.php, I get a 404 error.

However, if I change the path to read:

127.0.0.1/yourwebsite/files/gallery/testgallery/DSC_2246bw.JPG_duotone.jpg

and manually encode it to Base64, then run it as the input to image.php, I don't get the correct image, but I do get a 120 x 90 black box.

Any update on this. I'm also getting the same problems as above. i have tried the chmod 755 fix, didn't work. My img tags don't resolve either.
Any further help on this would be appreciated.

Ok, everyone seems to still be on holiday.

Anyway, here is one of the image links generated by brilliant gallery

http://www.mountainmotion.co.nz/index.phpmodules/brilliant_gallery/image.php?imgp=QzpcRG9tYWluc1xtb3VudGFpbm1vdGlvbi5jby5uelx3d3dyb290XGZpbGVzXHBob3Rvc1x0ZXN0YWxidW0vRjEwMDAwMTEuanBn&imgw=91&imgh=61

This returns a "Page Cannot Be Found" message. I noted that the link had added index.php after the domain name (see above). removing this so it reads ...motion.co.nz/modules/.... just brings up a blank page. so i'm guessing the imgp string when decoded, isn't pointing to the correct location either.

If anyone can give somethings to try or if you need more info, please just ask as i really need this working ASAP.

Cheers.

5.x-1.x-dev 2008-Jan-02
same problem.

I have tried the older version 5.x-2.14 ..... it works !
From 5.x-2.15 until the last version I can't see an image.

The error must be between the changes from 5.x-2.14 to 5.x-2.15.

Confirm.

Well i don't know exactly what you guys did, but i still get the same problem with 2.14

I tried the 1.x-dev jan 3 still same issue, but the background appears to rendering at the correct size. Before it would be like 10px by 15px.
This problem is really starting to get to me, i need this going.

vacilando is there any more info i can give you to help resolve this?

Hi

Got to say, loving the product. Also having this frustrating problem though.

It seems that any images that are already uploaded somewhere else on my drupal site, if I copy these into a folder within BG they work fine. The link displays as http://sitename/gallery/foldername/imagename.jpg

If I copy files in from somewhere else, ie my PC and paste them into a folder within BG, the link displays as http://sitename/modules/brilliant_gallery/image.php?imgp7d7sz etc...

What is the difference here - even if I paste my new images to the same folder the ones that were on the site somewhere else work but the new ones dont?

Any help appreciated!

Thanks

I had the same problem with the thumbnails not showing up, using version 5.x-2.17 on Windows XP. It seems that problem is found at line 268 of brillant_gallery.module :

$absolpath = realpath(file_directory_path() . '/' . $galleryfolder);

It seems that the PHP function realpath() works differently on Windows than on other platforms, and returns something like C:\www\drupal\files, instead of /www/drupal/files. As a quick fix, I added this code after line 268:

$absolpath = end(explode(':', str_replace("\\", "/", $absolpath)));

All this does is replace all instances of \ with / and only keeps everything after :. There is probably a better way to fix the problem, but this works for now.

Hi everybody,

This thread unfortunately mixes at least two different problems.

1) Related to path handling - esp. in PHP on Windows servers. Let's deal with that later.

2) Some weird stuff happening to (at least) jpeg image display... For a long time I basically did not know what you guys were talking about when you reported 'no thumbnails'. Most of the sites run OK - including http://www.vacilando.eu/bg - but some don't. Now I have access to a site that has precisely that problem.

I have spent days working on this in image.php - but have to admit I still do not know why it happens. I eliminated cache and path problem. Actually, when I write the pure image into a file and then open that file, it shows perfectly. But the output to browser is broken somehow.

Eventually I bypassed all the generated images and went for loading a static jpeg and outputting it in the browser.

$filename = base64_decode( $_GET['imgp'] );
$handle = fopen($filename, "r");
$contents = fread($handle, filesize($filename));
fclose($handle);
header('Content-Type: image/jpeg');
#echo $my_data[0] . '<br>';
echo $contents;
exit();

Guess what - even that did not work on the afflicted site.

Here are the headers sent by server:

HTTP/1.1·200·OK(CR)(LF)
Date:·Sat,·23·Feb·2008·00:04:31·GMT(CR)(LF)
Server:·Apache/2.0.52·(Red·Hat)(CR)(LF)
X-Powered-By:·PHP/5.1.5(CR)(LF)
Set-Cookie:·SESS50508cd80165d75dce2951b54cd70160=4bc329a507f6136f590271c2be6c1f70;·expires=Mon,·17·Mar·2008·03:37:51·GMT;·path=/;·domain=.uia.be(CR)(LF)
Expires:·Sun,·19·Nov·1978·05:00:00·GMT(CR)(LF)
Last-Modified:·Sat,·23·Feb·2008·00:04:32·GMT(CR)(LF)
Cache-Control:·store,·no-cache,·must-revalidate(CR)(LF)
Cache-Control:·post-check=0,·pre-check=0(CR)(LF)
Connection:·close(CR)(LF)
Transfer-Encoding:·chunked(CR)(LF)
Content-Type:·image/jpeg(CR)(LF)
(CR)(LF)

I then moved the image output code right to the beginning of image.php ... and it worked!!

The headers were:

HTTP/1.1·200·OK(CR)(LF)
Date:·Sat,·23·Feb·2008·00:02:49·GMT(CR)(LF)
Server:·Apache/2.0.52·(Red·Hat)(CR)(LF)
X-Powered-By:·PHP/5.1.5(CR)(LF)
Cache-Control:·max-age=1209600(CR)(LF)
Expires:·Sat,·08·Mar·2008·00:02:49·GMT(CR)(LF)
Connection:·close(CR)(LF)
Transfer-Encoding:·chunked(CR)(LF)
Content-Type:·image/jpeg(CR)(LF)
X-Pad:·avoid·browser·bug(CR)(LF)
(CR)(LF)

So what causes the problem? Well, I still do not know. But I know what I skipped in the second test was Drupal's initialization:

drupalize();
function drupalize() {
 while (!@stat('./includes/bootstrap.inc')) {
   chdir ('..');
 }
 require_once './includes/bootstrap.inc';
 drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
}

This code must be causing something that prevents the jpeg images be properly displayed in browsers - but only in some installations.

I looked for PHP errors in the log - none. There are no headers that would disable the image's headers - as you can see. Of course, PHP and Apache versions differ somewhat. Drupal is 5.7 in both cases.
The only thing I see suspicious right now (it was a long day, eyes are weary, not speaking of mind!) is the 'Expires' date in the 'Drupalized' version... it is from 1978, meaning clearly wrong. Is this a bug in Drupal? Is this caused by some module I/we have switched on? No idea!

I hope that this work will help you guys in your own examination of this problem, and hopefully somebody will find the real reasons - and possible solutions! Looking forward to hear from you!

Tomáš (vacilando)

Thanks, earnie. I set the domain there as needed, cleared cache, re-logged in but there has been no improvement.

If I disable
header('Content-Type: image/jpeg');
and leave only
echo $contents;
I can see gibberish that in fact is the image data. I thought about double gzip somewhere but then ruled it out and also realized that the image data, towards beginning, contains 'JFIF' and other header information, so it certainly is not zipped.

I thought perhaps function drupalize() alters the image data in some other way - but when I saved the image data into a file, I can open it as an image.

So it seems to me that drupalize() somehow disables the functionality of
header('Content-Type: image/jpeg');
but how on earth could that be happening?

Also, why is the date in the header 1978?

Thanks for any and all ideas, clues..

News: I was wrong in the preceding post -- the image data seem to be altered.

See the attached two html outputs - one before drupalize() and the other after it.

The image data seems to be 3 bytes longer after drupalize()!

What 3 byte? And, most importantly, why?

I had the same problem. Im using the latest dev version. (23 february) I know very little about PHP. But here is how i fixed it:

Open image.php (which is in modules/brilliant_gallery).

Remove this:

if ( strpos( base64_decode( $_GET['imgp'] ), ":" ) !== false ) { # Fixing a possible code injection problem.
     header("HTTP/1.0 404 Not Found");
     exit();
   }

And replace it with this code:

if ( strpos( base64_decode( $_GET['imgp'] ), ":" ) !== false ); 
else { 
     header("HTTP/1.0 404 Not Found");
     exit();
   }

It has something to do with the "header code" on top of image.php. If you delete this whole code the thumbs work too. But I thought that was a dirty way. So I made this code, I don't know what it does exactly. But it looks good ;).

edit: And also I have to check "Use the temporary directory you have set in /admin/settings/file-system. Faster than database caching!" in the brilliant_gallery administration. If i use drupal cache, it doesn't work here also. Is there a solution for both problems? (the code replacement/removal and drupal cache)

Wow Minardi God bless you, that fixed my problem.
You're a saint.

Minardi, it happened to me that people / robots tried to display arbitrary images via BG using full image URLs in the 'imgp'. The code at the beginning of image.php makes sure such attempts stop soon after they begin. Currently I detect ':' there, I will change it so that '://' is detected so that it is safer.

The main problem of this thread, however, still is that Drupal initialization programs somehow disable image display in some Linux installations.

IMPORTANT news:

Note that I have now found that if you disable
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL); in function drupalize(), test images I describe above start showing (not cached ones though, they need bootstrap).

This means that drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL) is the culprit somehow... so I am asking anybody who knows more about what drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL) does -- what in there can be altering the output in such a way that jpeg images get non-displayable?

This problem is FIXED now!

I still don't know why drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL) added / changed the jpeg in any way, but the problem disappeared when I used drupal_bootstrap(DRUPAL_BOOTSTRAP_DATABASE). Also means images will load faster and with less load on the CPU.

Get it from the CVS or grab the dev version (just posted).

Cheers,

Tomáš (vacilando)

:-)

PS I also have fixed the URL injection prevention, as I mentioned in the preceding post.

I am having the same problem with Drupal core 6.6 and BG version 6.x.3.0. Any idea why this problem would come up again? I had BG working fine until recently but don't know what happened to break it. I'll do more testing but if you have any other ideas I'd appreciate hearing from you.

Thanks,
maku520

maku520 please try the latest version 6.x-3.3 and report whether you still have an issue. If so, please describe it exactly, preferably in a new thread.