smd_slimbox

Bloke · 2007-03-04 03:52:09

mrdale wrote:

How would I acheive the following; from the selected categories, select the 10 newest images, then put them in random order… neither orderby="random,date:desc" nor orderby="date:desc,random" seem to work

Erm * cough * you wait until I fix the code to allow that. Sorry, I didn’t test all the combos with randomness in them :-(

I can now see I have to do something slightly different depending where in the orderby list you place the random option. I’ll have a play with it tomorrow and get a fix out asap. Right now, it’s 4am and I’m having trouble typwiepasnaergl6tr*&

decoderltd · 2007-03-04 14:19:57

Hi Stef,

Man thanks for the ability to display images by parent category, makes life much easier.

One question, I’m a little confused about how to display the images by child category, you mention using CSS2 and the ‘rel’ attribute in your help file, but I’m not sure I really follow. My tag is currently:
<txp:smd_slimbox category="gallery" subcats="1" orderby="category" groupname="?c" />

If I could crack this, then the gallery page would pretty much update itself as new child categories are added – it will be non-techy people using the site once it’s finalised.

Bloke · 2007-03-04 15:26:10

mrdale wrote:

neither orderby="random,date:desc" nor orderby="date:desc,random" seem to work

They do now :-) and they both do different things. The first will pull random images from the database, then order whichever pictures it has grabbed by descending date.

The second will do what you intend: pull out the most recent pictures first and then order them randomly on the page. Clicking ‘Next’ to page through them will pull the next most recent batch of images, displaying those randomly, and so on.

‘fixed’ is still honoured and takes precedence if you’re using a fixed-order imageid list. One caveat is if you ask it for random images from the database by putting ‘random’ first in the list. In this case you cannot guarantee to pull out all the images you have specified on the first page of results. But if it does pull out some or all of the image IDs you want, they will appear first in the list.

The help file explains more if you need it.

Other tweaks in this version are:

orderby now accepts any (or all!) of the following: category (the default), name, alt, caption, id, date, author, ext, width, height, random, or fixed : Sort-tastic!
New attribute: maxlimit. Specifies the absolute maximum number of images you will get from the database. Very useful if you want to make sure you’ll only get 100 pics so you can display them in 10 pages of 10 (i.e. maxlimit="100" limit="10"). If you omit the option, it is essentially unlimited (99999 in reality)

Give v0.23 a whirl and let me know how it hangs together for you.

Bloke · 2007-03-04 15:56:45

decoderltd wrote:

One question, I’m a little confused about how to display the images by child category, you mention using CSS2 and the ‘rel’ attribute in your help file, but I’m not sure I really follow.

You’re not the only one, it doesn’t quite do what I expected it to either :-s

The idea was this: using the tag as you have it, if you look at the source code you’ll see each image has a rel="lightbox-categoryName" associated with it. I was hoping (perhaps too highly) that using CSS2 selectors you could access this attribute and style it so you could, say, pull each category-gallery into its own space. e.g. if you had a category/sub-category called reptiles you could do:

.smd_slimbox li a[rel="lightbox-reptiles"] {
  margin-left:5em;
}

which would (and indeed does) indent all images of the reptiles group.

Unfortunately I overlooked one tiny detail; the rel attribute is applied to every image so the system falls over on at least two counts:

If you float the images (as most people will), you can’t use the CSS clear: property to drop the whole group to the ‘next row’ on the page; every image is affected
You have to write a CSS rule for each and every category/subcat, which is brain damaged when you don’t know what subcategories will be made or how they are organised

With that in mind I think the plugin will need extending, and as it happens it ties in nicely with the work I’m going to be doing for tollady on ‘nth image’. What I propose is some way of tagging the first (or last?) image of each category with a different class. The class name would be choosable by you. Indeed, it could be that you want every other category to be styled differently, so you could use maybe:

catclass="catodds, catevens"

That would style the first image of every new category with catodds or catevens, alternately for category groups down the page. Combined with the groupname="?c" option, this allows both for easy logical on-screen grouping and also physical boundaries such that when you’ve clicked on an image in a group, slimbox will only allow you to navigate within the images of that group and not “spill out” into a different category/subcategory, if that’s the behviour you want.

Do you think adding a classname to the first image of a category is enough or would you prefer the option of wrapping each category in its own <div class="given_class_name">? Can you think of any other ways the plugin can group images that might benefit from this approach? I’m struggling to think of any; apart from author (and maybe ext?!), category seems to be the only obvious choice as all the other “orderby” options are somewhat linear in nature.

If I go for styling author groups as well (somewhow…) I’d extend the groupname option to allow physical grouping that way too.

Let me know your thoughts on this (anyone else before I start to code it up?) and I’ll see what I can come up with.

mrdale · 2007-03-04 18:56:47

>Bloke

Thanks for the orderby fixes, they are great.

Oddly enough, I dont use this plugin, but rloaderro’s slideshow, which uses code from this one to do the heavy lifting. So I’ll have to ask him to migrate those changes into the slideshow plugin.

With that in mind, what are the chances of getting this plugin to do recursive image selection of descendant categories? That is, an attribute (recursive=“1”) that would allow using category=”?c” to display all child category images when on a parent category page. Category tree does this with category links, and has some functions that could be incorporated.

This would allow for hierarchical galleries which I would fin extremely useful. Maybe others would find it useful too.

Make sense? Any interest in this?

Thanks btw for the best plugin I never use. :)

Bloke · 2007-03-04 20:09:29

mrdale wrote:

>Thanks for the orderby fixes, they are great.

You’re welcome. Sorry they didn’t work earlier. It was quite a big change actually; far more intensive than I originally thought. I’m sure there’s a better way to do what I’ve done because it’s a trifle messy, but hey, if it works, that’s fine by me.

Oddly enough, I dont use this plugin, but rloaderro’s slideshow

Blimey. Didn’t even know about that one. Amazing what comes out of such a small idea. And I based my original idea on Rob Sable’s rss_thumbpop, then over time it’s been tweaked to make the options more generic and powerful.

Reading through rloaderro’s slideshow thread I can see why he had problems migrating the code because of my slapdash approach in the early days of learning this awesome Textpattern thing. I’m not sure it’s any easier for the poor guy now I’ve siphoned off loads of core functionality into smd_lib. I’ll send him a note and apologise for being too much of a hacker ;-)

what are the chances of getting this plugin to do recursive image selection of descendant categories? That is, an attribute (recursive=“1”) that would allow using category=”?c” to display all child category images when on a parent category page.

I think I half-follow. How does this differ from subcats="1" when using a single category name? Do you mean you want it to show a whole subcategory of thumbs, then another subcategory of thumbs and so on but not show the parent category? Or do you mean show a thumb from each top-level category and allow someone to “drill down” into each subcat until they reach the bottom and get a full image gallery?

How do you envisage it being laid out on the screen, just so I can get a visual feel for the effect you’re after? Like blocks of image galleries, vertically above each other, with each block being a sub-category of the one above it?

As it stands, if you were in an article category called ‘flowers’, category="?c" will pull out all images from the ‘flowers’ image category. Adding subcats=“1” will recurse through any image subcats and order (i.e. group) the images by category name on the page. Of course, they will all show together in a big lump right now.

The missing piece of the puzzle is what I mentioned in the post above to decoderltd, about being able to trigger a new class when each (sub)category is encountered. With that in place, I think it will do what you want, but maybe I’ve misunderstood?

Category tree does this with category links, and has some functions that could be incorporated.

I’ll certainly take a look at stw’s code and see what’s going on under the hood when I get a chance.

Any more detail on this appreciated. I’m sure it’s possible to do, but I want to be sure I understand the desired effect first!

mrdale · 2007-03-04 21:57:15

OK, things would go a whole lot better if I actually read through the thread before making feature requests for things that already exist. The v.22 update provided exactly what I was looking for (although I don’t need it for slimbox, I need it for aro_slideshow… which is the irony about my posts in this topic).

Well, thanks, I’m off to make a request or two of the kind mr rloaderro…

Once again, this is a really great plugin. Loads of useful options.

Last edited by mrdale (2007-03-04 22:03:58)

joel · 2007-03-05 00:53:28

As I wrote earlier in this thread I have discovered a weird problem in IE6 & 7 with the slimbox. The black overlay doesn’t stretch down 100%. It’s more like 10px at the top.

I´ve really googled my *ss of to find the answer but no luck so far. Perhaps someone can help me? :)

Here is a real-world-exemple of a non working site

I have a few others as well (but they are in development and cant be shown in public yet).

benjibot · 2007-03-05 03:35:08

Thanks for fixing the issue I mentioned earlier. I’d put off the photo gallery portion of my current project since I posted that (this being sort of a “spare time” sort of deal I have the luxury of doing that) and hadn’t noticed the recent activity until just now. I installed the most recent version and it solved my issue with the error messages.

I am, however, having another problem. I want to have slimboxes for my article_images in a certain section of my site. When I call smd_slimbox with imageid=”?article_image” I get nothing. I took a peek at the plugin source and I don’t see article_image mentioned anywhere.

Browsing through the help files I realized that this plugin can do a whole lot more than I realized. I’m glad I gave up on developing my own little slimboxer. I don’t think I’d have been able to put in as many options. Thanks for writing it, and extra thanks for being so quick to post fixes.

Bloke · 2007-03-05 10:19:54

joel wrote:

As I wrote earlier in this thread I have discovered a weird problem in IE6 & 7 with the slimbox.

Hmmm, I still think it’s related to IE’s strange layout engine.

Since the black background covers the whole screen on the front page, but doesn’t on the summary page, it’s got to be a layout issue and for some reason, slimbox is injecting the code into the wrong div. Or maybe the div doesn’t stretch all the way down in IE because of its reliance on having content in order to have dimensions? I’m not convinced that DOM-injected content is treated as “content” by the IE layout engine if the DIV didn’t previously have something in it. * shrug * clutching at straws.

But looking at your HTML, I can’t figure out why it would do that, because for all intents and purposes it’s the same template. There’s gotta be something strange about it that’s confusing IE. Have you tried moving the <div class="hide"> container about a bit? e.g. putting it inside a different container or just putting some lorem-ipsum text in it to see what IE does?

If you inspect the contents of each rendered output in the respective DOM toolbars, Firefox gives lbOverlay a height value, whereas IE doesn’t (it’s set at 0px). So for some reason, when slimbox.js injects the code into the layout it must look at the container and determine how big it’s going to make the overlay (just a guess; Christoph’s slimbox code is enhanced voodoo to me!)

On a side-issue I notice that the pics with dark background in IE fall foul of the random white pixel effect too :-(

IE really is in a class of its own: and at the back of the class!

I really can’t figure it out and without access to your source I can’t move stuff about on the page to see what the effect is. I bet you’re fed up of hacking around with it to try and get it to display properly aren’t you? On one of my (dev) sites I’ve got a similar issue; the slimbox dark overlay only appears on the left half of the screen in IE; split right down the middle. So I too have to spend time hacking about trying to fix it.

If I suddenly have a Eureka moment while messing with that site, I’ll be sure to let you know… if anyone else has any further insight, please shout.

Bloke · 2007-03-05 10:55:55

benjibot wrote:

I want to have slimboxes for my article_images in a certain section of my site. When I call smd_slimbox with imageid=”?article_image” I get nothing.

That is strange, it works for me on v0.23 (smd_lib v0.2) with <txp:smd_slimbox imageid="?article_image" />. I put that tag in an article, gave the article an article image id and it showed it, slimbox-able.

I also tried putting the slimbox tag in a form, then calling it from both the article body (with a <txp:output_form .. /> tag) and also with an overriden form. I then tried putting the tag in a page template too and it showed the image fine. I even tried putting a list of article IDs in the article image field and it showed them all.

So I really can’t figure out why it wouldn’t show your article_image… you have put an article image ID number in the article haven’t you?! :-p And you’re not trying to use it on an article list page are you? That won’t read stuff from the article_image field, cos there’s no article to read it from.

If you want some diagnosis output, go into the plugin almost to the bottom, find where it says:

// Construct the output
$outStr = '';
...

and immediately before that bit, add in dmp($where); and save the changes. That’s the final database query that the image laying-out segment is working with. It should show id IN ('article_image_id_number') of the image in your article_image field.

What’s strange is this: if you have nothing in your article_image field and no other tag options, it should show every image in the database rather than nothing [ note to self: consider fixing that in the next rev so it only honours that if always_display="1" is set ]

If this is a show-stopper for you right now, give it another option category="dummy" (a fake category that doesn’t exist) and it’ll show nothing if the article_image lookup fails.

I took a peek at the plugin source and I don’t see article_image mentioned anywhere.

You won’t, it’s read dynamically in smd_lib. It just throws whatever you put in the tag at the page and sees if any matches come back.

Browsing through the help files I realized that this plugin can do a whole lot more than I realized.

Yeah, it’s approaching useful now. A few more iterations and it’ll really be a monster. Shame I can’t make the docs more easy to understand (and shorter!) but it’s so ludicrously flexible that to skip over stuff or cover it all would cause confusion either way.

Let me know how you get on with getting it to show your article images. If you want, post any diagnosis output and the options you used to generate that where statement. If it’s a bug I’ll hunt it down and maim it.

benjibot · 2007-03-05 12:08:31

Bloke wrote:

And you’re not trying to use it on an article list page are you? That won’t read stuff from the article_image field, cos there’s no article to read it from.

Uhhh. . . oops! As it turns out I was. A bit more information in my post and you’d have seen my problem right away. I didn’t realize that it required an single article page, but it makes sense that it does.

I’m not entirely sure that page needed lightboxes. . . I hadn’t even thought about adding them before I read the updated help files.

Thanks again!

Textpattern CMS

Textpattern CMS support forum

#49 2007-03-04 03:52:09

Re: smd_slimbox

#50 2007-03-04 14:19:57

Re: smd_slimbox

#51 2007-03-04 15:26:10

Re: smd_slimbox

#52 2007-03-04 15:56:45

Re: smd_slimbox

#53 2007-03-04 18:56:47

Re: smd_slimbox

#54 2007-03-04 20:09:29

Re: smd_slimbox

#55 2007-03-04 21:57:15

Re: smd_slimbox

#56 2007-03-05 00:53:28

Re: smd_slimbox

#57 2007-03-05 03:35:08

Re: smd_slimbox

#58 2007-03-05 10:19:54

Re: smd_slimbox

#59 2007-03-05 10:55:55

Re: smd_slimbox

#60 2007-03-05 12:08:31

Re: smd_slimbox

Board footer