smd_slimbox

vittorio · 2007-11-08 16:03:06

Just a quick followup.

Stef,
i digged in the mootools forum (since i’m quite sure it is that script which causes IE to crash), and found this thread which sounds interesting. Especially when it says, on post #6:

IE often crashes if you try to append something (especially scripts) to the dom before it’s ready. I suggest putting your code in a Window.onDOMReady block so that you don’t try and execute any code before the dom is ready. This will allow you to remove the javascript from the page entirely.

Then I found this other thread, solved by moving all the javascript code at the end of the html file. I tried this solution, putting the mootools js just before the closing </body> tag, but it doesn’t seem to work at all: on IE, the page which normally crashes is loaded, but the browser output some error, and the slimboxed gallery doesn’t work. There was also a possible explication suggested, again involving the DOMReady-thing.

Thought that maybe it could be the reason, and it looks similar to what you said about moving a script above or below another. The problem is that is sounds like chinese for me (sorry, I’m not so experienced in coding, especially in javascript), but maybe it can tell you something…

Bloke · 2007-11-08 16:43:08

vittorio wrote:

IE often crashes if you try to append something (especially scripts) to the dom before it’s ready… putting the mootools js just before the closing </body> tag, but it doesn’t seem to work at all

With Slimbox it shouldn’t matter where the code is placed, because it already executes on DomReady (quite why slimbox is refusing to work at all is weird though). The only time it could cause an issue would be if IE lied about the DOM being ready when it actually wasn’t!

The acknowledged problem with SWFObject (fixed in the current v2 beta), however is certainly a problem if you include swfobject.js on your page. Moving that to the end of the page might help, or adding defer="defer" to the tag. I don’t know if externally referenced scripts (using the src="" attribute of the script tag) take notice of the defer though.

Unfortunately, this bug probably affects kml_flashembed and, as far as I know, there’s no way to guarantee that a plugin is loaded last on the page. The best kimili can hope for right now is to put the defer="defer" attribute in the <script> tags and wait for v2 of swfobject to be released. Or add a domReady() call himself somehow.

Now, if your page is crashing and you’re not loading swfobject/kml_flashembed anywhere and you’re not using <embed> then it’s a problem elsewhere and we’ll need to look deeper into your page code to work out why.

vittorio · 2007-11-08 17:00:36

Bloke wrote:

Now, if your page is crashing and you’re not loading swfobject/kml_flashembed anywhere and you’re not using <embed> then it’s a problem elsewhere and we’ll need to look deeper into your page code to work out why.

Sorry Stef, maybe I wasn’t clear enough. I disabled kimili’s plugin, and deleted the call for the swfobject js, so it isn’t a problem anymore. The issue is with the <embed> tag, and I am still trying to find a solution to avoid the manual editing of every video I posted so far.

What I don’t yet understand is: why my video pages load correctly on IE with no mootools script being called (even though we know that the code provided by youtube and such sites isn’t good), but they don’t when mootools is present? If I’m not wrong, this should be a common issue for everyone who uses mootools AND posts videos from youtube-like sites. So, when I read those post in the mootools forum, I thought I could have a chance of solution…

Edit: What about this thread which concerns IE’s weird “operation aborted” error and Slimbox in particular?

Last edited by vittorio (2007-11-08 17:34:45)

raveoli · 2007-11-08 21:03:10

I can install smd_lib 0.3, but the main slimbox plugin returns a “Badly formed or empty plugin code.” message.

I notice the slimbox plugin has strange linebreaks?! Every other plugin I’ve installed is one big massive chunk of code. Maybe you’ve saved it differently Stef?

Or can it be something else?

Last edited by raveoli (2007-11-08 21:11:53)

Bloke · 2007-11-09 09:44:24

vittorio wrote:

I disabled kimili’s plugin, and deleted the call for the swfobject js, so it isn’t a problem anymore.

Right, cool. Thanks for researching this by the way, it’s much appreciated.

I looked at that link you sent. As you found out, Christophe says:

I think the problem is caused by the use of the onDomReady function of mootools in combination with document.write() in IE, in another conflicting Javascript. The quick fix is to either remove the document.write() or the other conflicting javascript or use window.addEvent(‘load’, Lightbox.init.bind(Lightbox)); in the last line of the Slimbox script instead of onDomReady.

Some people complain the ‘load’ method doesn’t work, but feel free to modify the last line of slimbox.js to try it. Just swap the ‘domready’ for ‘load’. The downside is that your lightbox won’t be available until the entire page has fully loaded. Incidentally, I found the reason your page does not show a lightbox: you moved mootools.js to the bottom of the document. The mootools library must appear before slimbox.js on the page. Try moving slimbox.js to the bottom of the page instead.

Having said that, looking at your page you have a lot of other javascript functions on there. Google Syndication, Technorati, and Feedburner to name three, plus some weird EO library (I have no idea what it does!)

Any one of those could be doing a document.write() at a time that IE (or mootools) thinks is inappropriate. It certainly looks like Technorati does a document.write() without waiting for the DOM, perhaps that’s the culprit? Maybe add a defer=“defer” to that <script> tag?

It may well be mootools itself, in which case we’re stuck with it until they release an update. But I’m leaning towards it being IE itself since Micro$oft claim it’s a bug in IE6 (and 7 which is inexcusable given it was in development along with Vista for, like, 6 years!) that is triggered if a piece of javascript attempts to modify an element that is not fully loaded. What it should do is trigger a javacript error not “operation aborted”, but that’s M$ devs for ya :-p

If at all possible, try moving the call to technorati a bit lower down the page or add the defer=“defer” to the tag. I know having to move things around on the page is silly and annoying but if it means you can use <embed> and save yourself a load of hassle then it’s worth it. What’s slightly baffling still is that it goes away if you remove <embed>. Perhaps Micro$oft’s implementation of the the embed tag itself modifies the DOM behind the scenes. Now that would be ironic :-)

Bloke · 2007-11-09 10:00:54

raveoli wrote:

the main slimbox plugin returns a “Badly formed or empty plugin code.” message. I notice the slimbox plugin has strange linebreaks?!

Hmm, not saved it any differently to usual. Straight out of the awesome ied_plugin_composer. But I know some people do have difficulty (no ideas why it works for some and not others, perhaps the text editor or browser the code was copied out of?) because the plugin’s so big now (mostly documentation).

For that reason I’ve now put all the docs online, I distribute the docs as a standalone file in the zip with the plugin and I’m going to start encoding the plugin with only a contents page that links back to my web site for the full docs.

You can be the first person to try it out. Let me know if that fixes it.

Last edited by Bloke (2007-11-09 10:01:41)

raveoli · 2007-11-09 19:06:35

Thank you Stef, that one worked;-)

Your plugin is joyful by the way. I enjoy it very much.

Have a nice weekend!

vittorio · 2007-11-10 18:16:21

Bloke wrote:

Try moving slimbox.js to the bottom of the page instead.

Hey hey hey! I moved slimbox.js at the end of the page, and now those ~~hated~~ loved videos seem to load without causing my pc to explode! Finally, the solution has come!

Having said that, looking at your page you have a lot of other javascript functions on there. Google Syndication, Technorati, and Feedburner to name three, plus some weird EO library (I have no idea what it does!)

Yes, I know there’s quite a lot of js code in my pages. But, except for Eo.js, which is an Email Obfuscator, Google Analytics, Technorati, Feedburner… could you blog without them?! :-)

Any one of those could be doing a document.write() at a time that IE (or mootools) thinks is inappropriate. It certainly looks like Technorati does a document.write() without waiting for the DOM, perhaps that’s the culprit? Maybe add a defer=“defer” to that <script> tag?

Don’t know why, but each time I add defer="defer" to some <script src=""> strange things happen… tried with technorati and the whole page turned empty… :-\

Anyway, after days and days spent trying… I will settle down with the slimbox.js at the end of the page. And amen!

robin746 · 2007-11-23 03:13:06

I want to do the simplest possible thing.

Inside an article I want to display a single image by ID and have ONLY that image show up in the lightbox. But if I add this code inside the Write box:

<txp:smd_slimbox imageid="2"/>

Then I have a problem. Although the thumbnail for the image in question shows up correctly, the lightbox image has a “Prev” button that allows browsing through all my other images. The following does not help:

<txp:smd_slimbox maxlimit="1" imageid="2"/>

Neither does this:

<txp:smd_slimbox showpagelinks="0" imageid="2" />

Please help me out with this or I cannot use this nice plugin.

iblastoff · 2007-11-23 05:52:49

odd. i just tested on my own site using your first example format <txp:smd_slimbox imageid="2" /> in an article and i get the correct thumbnail with working slimbox effect with no ‘prev’ or ‘next’ buttons.

Last edited by iblastoff (2007-11-23 05:53:05)

Bloke · 2007-11-23 09:13:08

robin746 wrote:

if I add this code inside the Write box: <txp:smd_slimbox imageid=“2”/> … the lightbox image has a “Prev” button that allows browsing through all my other images.

My guess is you have other slimboxable images on the same page; perhaps you’re using this on an article list page?

The way round it is to use groupname to uniquely identify each slimbox tag on a page. In your case the best option will be groupname="?id" which will give each image within each slimbox its own unique identity (check out the source of the page after you apply it and look for the rel= attribute on the images to see what it’s done).

Other options are groupname="?c" to give each image in each slimbox the name of the category that image is in, or groupname="?author" and so on. Examples in the docs. (ab)Use of this feature allows some quite interesting navigation effects. You can also use any fixed string of your choice for groupname if you’re using it within an article.

Hope that helps.

robin746 · 2007-11-23 12:51:42

@Bloke: That’s it exactly. Using groupname works:

.bc <txp:smd_slimbox groupname=”?id” imageid=“2”/>

Thanks for the quick reply. This plugin rocks, even if the attributes are a bit complex.

Textpattern CMS

Textpattern CMS support forum

#325 2007-11-08 16:03:06

Re: smd_slimbox

#326 2007-11-08 16:43:08

Re: smd_slimbox

#327 2007-11-08 17:00:36

Re: smd_slimbox

#328 2007-11-08 21:03:10

Re: smd_slimbox

#329 2007-11-09 09:44:24

Re: smd_slimbox

#330 2007-11-09 10:00:54

Re: smd_slimbox

#331 2007-11-09 19:06:35

Re: smd_slimbox

#332 2007-11-10 18:16:21

Re: smd_slimbox

#333 2007-11-23 03:13:06

Re: smd_slimbox

#334 2007-11-23 05:52:49

Re: smd_slimbox

#335 2007-11-23 09:13:08

Re: smd_slimbox

#336 2007-11-23 12:51:42

Re: smd_slimbox

Board footer