smd_slimbox

Bloke · 2007-03-06 22:17:32

ultramega wrote:

I’m planning to import series of images for articles and get them categorized automagigally by fpx_image_import. So I’d like to drop that cat name in one custom field. So far what I have tested, if the field is empty, it’s adding all images, right? Was it possible to restrict by some tag?

Yes, it’s a subtle but annoying bug. If you specify an actual named category and it finds no category of that name, it returns nothing. If you specify a custom/article field e.g. category="?custom1" or category="?excerpt", if that contains a category name that doesn’t exist it will return nothing. But if that field is empty it will panic and return all the images. I’ve not found a way round that yet; but it’s on the todo list.

In the meantime, give it a fake category also, e.g.: category="?custom1, bloke_is_bad". As long as the bloke_is_bad category doesn’t exist in TXP, the tag will return nothing if custom1 is empty.

Sorry for the inconvenience.

ultramega · 2007-03-07 00:47:38

Don’t worry, not a big deal at all :) I was just wondering if there was some solution for this.

transph0rmer · 2007-03-09 18:05:35

Hey Bloke,
thanks for this great plugin. 7 Thumbs up!

I’d like to know if there will be a possibility to display the image title in a future release?

Keep up the great work,
Cheers
transph0rmer

Bloke · 2007-03-09 20:27:34

transph0rmer wrote:

I’d like to know if there will be a possibility to display the image title in a future release?

Do you mean the image (file)name? Sure, that would be no problem. I’ll add it to the todo list.

In fact, dunno why I don’t do that already; I do category and alt, so might as well do the rest (author, id, date, name etc) in case anyone needs them.

Instead of overloading the plugin with showalt, showcaption, showauthor, showname, etc I’ll probably add a tag show= where you can specify which bits you want to show and where you want them displayed. e.g. show="caption:below, author:above, name:before" and so on. I’ll then deprecate or phase out showalt/showcaption/textpos in favour of the new tag.

Sound like a plan to you?

transph0rmer · 2007-03-10 13:49:15

Bloke wrote:
Sound like a plan to you?

Sounds like a great plan to me. Thanks very much and have a nice weeekend

Last edited by transph0rmer (2007-03-10 13:49:39)

Bloke · 2007-03-11 16:49:30

Just an update on joel’s slimbox not stretching the whole page. Not sure if I’ve found a fix per se, but I found a reason for it to happen.

On one of my sites, IE was only showing the overlay in the left half of the screen. It appears that the lbOverlay div is injected into the DOM tree under the <body> tag. In my case, I’d defined the body to have:

margin: 0 auto;
width: 500px;

so it floated horizontally in the centre of the page as the browser was resized. Looking at the DOM tree in IE (using the slightly sub-standard but functional IE dev toolbar) I could see that although the body was defined as 500px wide with auto left and right margins, IE thought it simply stretched for 500 pixels from the left edge of the screen, thus “stopping” somewhere in the middle of the page. Bizarrely, the content was centred correctly, so the margin adjustments must be made in IE’s Trident engine after the body tag is rendered (at a guess).

The upshot was this: set the body tag to have a width of 100%, then add a <div id="wrapper"> immediately inside the body tag surrounding all your content and apply margin: 0 auto; width: 500px; to that instead. Stupid, but it worked.

Now, in Joel’s case I’m not sure it helps because his body tag appears to stretch the whole width and height of the browser viewport, yet the lbOverlay div is assigned height: 0px in IE, and the full viewport height in Firefox etc. What’s even more curious, the lbOverlay doesn’t appear to be constrained by anything on the page; in my case, the edge of the lbOverlay was clearly being “chopped off” by the body tag having less than 100% width.

At the point the DOM is sufficiently rendered, the slimbox js code must look at something on the page to work out how big to make the black lbOverlay and in Joel’s case it’s seeing 0px (I’d guess the fact there’s 10px or so of height being shown is to do with the line-height?). Normally, IE’s damaged engine sees 0px height or width if there’s no content in a particular container. Perhaps at the time the DOM is flagged as “ready” there is no content in the body? Long shot…

You could try changing the last line in slimbox.js to:

window.addEvent('load', Lightbox.init.bind(Lightbox));

instead of ‘domready’ to see if it makes any difference?

Not sure if that gives you anything to go on, Joel: it’s not much, sorry.

Last edited by Bloke (2007-03-11 16:51:02)

Rowar · 2007-03-12 14:15:27

Hello,
i have installed your plugin succsefully and am very glad with it. Its Really a great work!!! But i have a problem with the image output please have a look at http://www.synapstix.de/bildergallerien/first-post. Use an other Browser then Internet Explorer. Choose a picture at the middle (Avril lavigne for example) and move the mouse between prev and next. The Picture is sliced in two peaces and are displaced.

I don’t changed the files i just uploded the files and installed the plugins.I dont know which Informations are helpfull for you, so please ask if you need more infos. I Really don’t know whats wrong with it and i hope you can help me.

Greetings,
M. Vogel

Bloke · 2007-03-12 15:02:14

During the process of updating to v0.24 and rolling in a few edits from the recent posts it has transpired that it’s hardly worth only doing half a job. Various new features rely on other new features so would make the plugin unneccessarily (more!) complex without both written and working.

So I’m shelving 0.24 in favour of a big update to 0.3 with pretty much all the stuff mentioned to date. Of course the flipside is that it’ll take me longer to finish and debug, sorry.

As a token of my appreciation for waiting you can just update smd_lib to v0.21 if you wish to add shortcut functionality that allows ranges of imageid.

For example, instead of imageid="12,13,14,15,16" you can do imageid="12-16". Also works with negation so you can negate a group (e.g. imageid="46, 53, 12-16, !54-58") which would exclude 54, 55, 56, 57, and 58. Works with fields as well so you can say "imageid="!keywords" and the keywords field could contain a comma-separated list of integers or ranges.

I have no idea what will happen if you say imageid="?keywords" and the keywords field has “!12-16” in it. My guess is the sun will go dark, the seas will boil and life will cease to exist on this planet. You have been warned.

@Rowar: Freaky! Avril Lavigne looks kinda rough when you view her in two pieces :-p

My guess is it’s a generic CSS rule (either an img or a, probably with :hover) that’s being applied from your default stylesheet across to slimbox so as you roll over the image it breaks the picture up. Try looking at the background:inherit; rules first because it may be trying to ‘copy’ stuff from under the floating image as you roll over? I deleted all the background:inherit rules and it seemed to fix it (at least from the dev toolbar) so it could be one of them. Not sure which, though…

Last edited by Bloke (2007-03-12 15:08:33)

Rowar · 2007-03-12 15:38:50

Thanks for the fast answer.
You was right, this problem was an generic definition background:inherit; for a and a :hover (like: a, a:visited {background:inherit;}). It seems that i have to accept the warnings of the stupit requirements of the css validation service.

Now i have a really beautiful Image gallery (better than the typo3-version of the page ^_), So i can furthermore play with textpattern…

Greetings,
M. Vogel

joel · 2007-03-12 21:50:09

Bloke wrote:

You could try changing the last line in slimbox.js to:
window.addEvent('load', Lightbox.init.bind(Lightbox));
instead of ‘domready’ to see if it makes any difference?

Unfortunately It didn’t work… I really appreciate your help though… :)

progre55 · 2007-03-13 21:41:33

I am experiencing the same issue as Joel. I have used Slimbox before on other projects without this issue. I plan on diving deeper into it tonight, but any assistance or guidance anyone could offer would be great.

The above change to the code also did not change the result.

Thanks.

progre55

Last edited by progre55 (2007-03-13 21:42:43)

Bloke · 2007-03-13 22:06:27

progre55 wrote:

I have used Slimbox before on other projects without this issue.

In TXP? One thing we could do to rule out the plugin would be to not use it :-) i.e. comment out all reference to smd_slimbox / smd_slimbx_inc in the page/form, disable the plugin and then manually add lines to include slimbox.js and slimbox.css.

Then, just manually add a couple of pictures in the same format as slimbox normally requires:

<a href="link_to_fullsize_pic" rel="lightbox"><img src="thumb_pic"></a>

If it still does the weird cut-off background thing then it ain’t the plugin, it’s definitely a page layout/slimbox interaction issue and it’s a hack-around-until-it-goes-away job :-(

If, however, this fixes it I’ve got a problem! Let me know where you put stuff in the code (e.g. were the links to slimbox.js/slimbox.css in your <head> section, and in what order did they occur: before or after <title>, etc, etc). It may very well be a simple thing like the actual location of the tags that’s causing Christophe’s code to inject itself in the wrong place in the DOM?

The above change to the code also did not change the result.

Yeah, it was a long shot. Just wondered if it was DOM-ready-related but I guess not. Thanks for trying it out.

Last edited by Bloke (2007-03-13 22:08:27)

Textpattern CMS

Textpattern CMS support forum

#73 2007-03-06 22:17:32

Re: smd_slimbox

#74 2007-03-07 00:47:38

Re: smd_slimbox

#75 2007-03-09 18:05:35

Re: smd_slimbox

#76 2007-03-09 20:27:34

Re: smd_slimbox

#77 2007-03-10 13:49:15

Re: smd_slimbox

#78 2007-03-11 16:49:30

Re: smd_slimbox

#79 2007-03-12 14:15:27

Re: smd_slimbox

#80 2007-03-12 15:02:14

Re: smd_slimbox

#81 2007-03-12 15:38:50

Re: smd_slimbox

#82 2007-03-12 21:50:09

Re: smd_slimbox

#83 2007-03-13 21:41:33

Re: smd_slimbox

#84 2007-03-13 22:06:27

Re: smd_slimbox

Board footer