Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I have installed Colorpicker, jQuery_Update, Lightbox v2, and Brilliant Gallery. I've gone through the steps here. I'm pretty sure I've done all that correctly, as when I put the tag [bg|test] into a node, a table is created that is populated with img tags for the 4 images in that folder. But all I see is a corner of the table (the padding in the upper left); the URLs for the images don't resolve.
I'm having the same problem on two different installations of Drupal so, clearly, I'm doing something stupid, but I can't figure out what.
Comment | File | Size | Author |
---|---|---|---|
#29 | before_and_after_drupalize.zip | 472.09 KB | Vacilando |
Comments
Comment #1
Vacilando CreditAttribution: Vacilando commentedPost links to your gallery pages, or screenshots, or mail me the html dump of them.
Comment #2
zbricoleur CreditAttribution: zbricoleur commentedHere's a SCREENSHOT
Here's the HTML dump:
Comment #3
Vacilando CreditAttribution: Vacilando commentedSince 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?
Comment #4
zbricoleur CreditAttribution: zbricoleur commentedThe first link, http://localhost:8888/cms/files/albums/tbug/101_0510.jpg, works.
The second, http://localhost:8888/cms/sites/all/modules/brilliant_gallery/image.php?..., does not. It returns no image, and no HTML at all.
"albums" is set for the album folder in BG settings.
The tag is [bg|tbug]
One more piece of information: I get these warnings when I attempt to refresh the page:
* warning: filectime() [function.filectime]: stat failed for /Applications/MAMP/tmp/php/bg_125df99acda029510c1a54c8263d730c in /Applications/MAMP/htdocs/CMS/sites/all/modules/brilliant_gallery/image.php on line 60.
* warning: filectime() [function.filectime]: stat failed for /Applications/MAMP/tmp/php/bg_f50580c89cc071f5474aa3f4ad43abae in /Applications/MAMP/htdocs/CMS/sites/all/modules/brilliant_gallery/image.php on line 60.
I WAS able to set BG up on a different server without problems just now (really a beautiful piece of work by the way--thank you!), so I'm beginning to think it's an issue with my test server.
Comment #5
seangee CreditAttribution: seangee commentedI 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
Comment #6
karschsp CreditAttribution: karschsp commentedweird. 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!
Comment #7
karschsp CreditAttribution: karschsp commentedi 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?
Comment #8
seangee CreditAttribution: seangee commentedI have now got this working. I had to
chmod 755 modules/brilliant_gallery/image.php
Comment #9
HansKuiters CreditAttribution: HansKuiters commentedI 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:
I get the follwing message:
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.
Comment #10
karschsp CreditAttribution: karschsp commentedhey 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:
and replace it with:
let me know if that helps!
Comment #11
karschsp CreditAttribution: karschsp commentedcrap....nevermind, that wasn't it. still searching...
Comment #12
Vacilando CreditAttribution: Vacilando commented@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.
Comment #13
jmspldnl CreditAttribution: jmspldnl commentedI'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.
Comment #14
Village Idiot CreditAttribution: Village Idiot commentedI'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?
Comment #15
Village Idiot CreditAttribution: Village Idiot commentedI'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!
Comment #16
Village Idiot CreditAttribution: Village Idiot commentedJust 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.
Comment #17
AlienEclipse CreditAttribution: AlienEclipse commentedAny 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.
Comment #18
AlienEclipse CreditAttribution: AlienEclipse commentedOk, 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.
Comment #19
baja_tz CreditAttribution: baja_tz commented5.x-1.x-dev 2008-Jan-02
same problem.
Comment #20
tonino66 CreditAttribution: tonino66 commentedI 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.
Comment #21
baja_tz CreditAttribution: baja_tz commentedConfirm.
Comment #22
AlienEclipse CreditAttribution: AlienEclipse commentedWell i don't know exactly what you guys did, but i still get the same problem with 2.14
Comment #23
AlienEclipse CreditAttribution: AlienEclipse commentedI 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?
Comment #24
dave.eagle CreditAttribution: dave.eagle commentedHi
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
Comment #25
dboulet CreditAttribution: dboulet commentedI 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.Comment #26
Vacilando CreditAttribution: Vacilando commentedHi 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.
Guess what - even that did not work on the afflicted site.
Here are the headers sent by server:
I then moved the image output code right to the beginning of image.php ... and it worked!!
The headers were:
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:
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)
Comment #27
Anonymous (not verified) CreditAttribution: Anonymous commentedYou may need to set the $cookie_domain variable in the drupalize function before the drupal_bootstrap call. See the comment in settings.php.
Comment #28
Vacilando CreditAttribution: Vacilando commentedThanks, 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..
Comment #29
Vacilando CreditAttribution: Vacilando commentedNews: 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?
Comment #30
Minardi CreditAttribution: Minardi commentedI 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:
And replace it with this code:
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)
Comment #31
defdef CreditAttribution: defdef commentedWow Minardi God bless you, that fixed my problem.
You're a saint.
Comment #32
Vacilando CreditAttribution: Vacilando commentedMinardi, 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?
Comment #33
Vacilando CreditAttribution: Vacilando commentedThis 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.
Comment #34
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #35
maku520 CreditAttribution: maku520 commentedI 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
Comment #36
Vacilando CreditAttribution: Vacilando commentedmaku520 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.