images

Yes, I was fundamentally mistaken in my understanding of what I need to do to have a Views-generated image trigger Lightbox.

Re-reading the Lightbox2 settings more carefully, I see the key phrase "Choose how URLs for [such-and-such] images will be automatically handled" repeated for many settings.

Ah, that may be what I was skipping over. Perhaps Lightbox2 is looking for URLs, not certain classes, attached to the images. Going back to the Views settings for my random image block, I found the desired setting under the Fields section, where I had specified "Image: Image" as the field to appear in the View. The settings for that field include the option "Link this field to its node". I had originally left this unchecked, as I don't want clicks on images taking users to a page built on the image node. But, as I soon confirmed, that's not a worry; with a link URL in place on the images, Lightbox2 intercepts those links and performs its magic, opening a big floating image on the same page. Boom!

Now, what about inline images in my general nodes, the ones embedded helter-skelter amidst node text via my WYSIWYG text editor (TinyMCE and IMCE, if you must know)? I was getting no Lightbox2 click love there either. "Ah", I brilliantly surmised after enough tequila, "Perhaps you want a URL there as well, Lightbox2?" Ever so gently, I adorned my inline image with – for lack of a better idea – a link to its actual location in the file system (files/image.jpg or whatever).

"Now you understand me", breathed Lightbox2, and graced my inline with that old popup hoodoo. She/he/it and I have been like this (crosses fingers) ever since. 

I don't know that the above is the way to best work Lightbox2 into a site, but as a quick solution to what I was looking for, it did the trick for me.

As of January 2010, I have no answer to the problem – but suddenly have no problem, either. In the kind of unsatisfying conclusion that happens time and again, I find that I can now change all affected sites to Public download, and even enable optimization of CSS and Javascript at Administer » Site configuration » Performance (which was the point of it all). After doing so, images display normally – even though the images still have the screwy addresses, like http://www.site.com/sites/site.com/files/images/image.png, that earlier resulted only in "image broken" placeholders.

That's if I'm logged in. If not logged in, image addresses have the nice expected form http://www.site.com/system/files/images/image.png. Can't these images make up their minds? But either way, they seem to display just fine.

So, what gives? I can't say. I don't recall making any major changes to the system that would affect this; perhaps it was simply an upgrade to the Image module somewhere between then and now (I'm currently running 6.x-1.0-alpha4).

If you've had this same problem, all I can suggest is trying the change from Private to Public again, especially if you've made any changes to Drupal or modules recently. Who knows, it just may suddenly work.