That's the function that disables the submit buttons after pushing them so users can't push them twice. Removing the first line inside the function seems to work, so I guess CKEditor doesn't like having its submit button disabled.
I commented everything out and then uncommented out each function one at a time and tested. I'm sure there's a more high tech way to find js conflicts but this way worked...
Partially fixed problem by changing global variable "photo" in colorbox.js to true to force the script to handle the object as an image. See function isImage().
Now need to figure out how to change the inline images plugin to set this variable on an image by image basis (which would be more useful).
Changed the global photo variable back to the default false. Added "photo:true" to the $(document).ready() section at the end of the script.
$('a.thickbox').colorbox({photo:true});
Added this as a seperate line, because we may have content in the site that uses other inline features of thickbox, lightbox, shadowbox, colorbox. InlineImages extension explicitly uses the class "thickbox".
Suggestions: 1. Modify inlineimages extension to add an additional class to inline image links to identify them explicitly as inline images as opposed to other inline content such as html or iframe.
2. Add $('a.inlineimage').colorbox({photo:true}); to the document ready call
3. For better use of jquery, move the document ready call out of colorbox.js so that future updates won't break. Do all the document ready stuff in a separate js file that can be utilised by any extension that uses jquery.
@fraser, this looks like some great research into the problem and some sensible suggestions - thanks!
Regarding point 3, I initially started including the document ready stuff at the end of the actual plugin JS to save an extra HTTP request to the server, but since Vanilla 1.2 is going to include minnify, this becomes a bit of a moot point. I will go through the various plugins and move the document ready stuff out of the main JS files. This will also make things ever-so-slightly easier to update in the future.
2. Yes
1. Agreed.
I think it would also, perhaps, be a good idea for the "thickbox" option in InlineImages to be renamed to something else akin to "thumbnail inline images and open the full image in a modal window". That's overly wordy, but it gets across what I'm trying to communicate. This would add class="modal" to the link. Perhaps I should be suggesting class="modal" as the best way to use things like ColorBox...?
That way it would remain modal JS agnostic should ColorBox stop being maintained and replaced with something else in the future, as has happened with ThickBox. A class of modal also seems a little bit more semantic for the markup, which is always a nice thing to have if you can afford it
Until InlineImages is updated, I'll see about getting something in place to stop this happening.
The new version of InlineImages (combined with HTML Formatter) in the repository has class="InlineImage" added to the image if Thickbox is disabled. However the way images are handled now are quite different. The default allowed width for an image is quite large (5120px) but now there is client-side (JavaScript) sizing. It means that if an image is too wide to fit on the person's screen without creating a horizontal scrollbar, the image is resized to the perfect width for them. It's quite cool I think.
I take it this client-side resizing thing only kicks in if you are not using "ThickBox"?
Client-side image resizing is all very well for not breaking your layout, but it doesn't address the alternative reason for using thumbnails - reducing initial bandwidth/load time.
Does this resizing kick in even without using InlineImages?
<muttering>I should probably download V1.2 and take a look for myself...</muttering>
Vanilla 2 (at this point) uses jQuery as it's JS library so there's less need for this plugin. However, the extra little JQuery plugins I've included should be relatively easy to port to V2.
Comments
Just did some bug testing and it seems that CKEditor conflicts with line 248 of global.js
function Wait(Sender, WaitText) {
I have no idea what this does, but commenting it out makes CK work in all of the above...Sender.disabled = true;
Sender.value = WaitText;
var el = Sender.parentNode;
while(el != null) {
if (el.tagName == "FORM") {
el.submit();
break;
}
el = el.parentNode;
}
}
Any Vanilla 1 gurus out there that can tell me what this little function is and does? And can we
kill itrewrite it to not conflict?Removing the first line inside the function seems to work, so I guess CKEditor doesn't like having its submit button disabled.
@Cablespider: I'd like to know that as well. When I tested it, it seemed to be the best setting. With it set to 0 the lines weren't breaking.
See:
http://www.nqscots.com/discussion/136/ayr-water-festival-parade-news-story/?Focus=1576#Comment_1576
When you click on the thumbnail, colorbox appears to be handling the content type as text?
Have tried the minified and uncompressed versions of the included colorbox js.
Now need to figure out how to change the inline images plugin to set this variable on an image by image basis (which would be more useful).
$('a.thickbox').colorbox({photo:true});
Added this as a seperate line, because we may have content in the site that uses other inline features of thickbox, lightbox, shadowbox, colorbox. InlineImages extension explicitly uses the class "thickbox".
Suggestions:
1. Modify inlineimages extension to add an additional class to inline image links to identify them explicitly as inline images as opposed to other inline content such as html or iframe.
2. Add $('a.inlineimage').colorbox({photo:true}); to the document ready call
3. For better use of jquery, move the document ready call out of colorbox.js so that future updates won't break. Do all the document ready stuff in a separate js file that can be utilised by any extension that uses jquery.
Regarding point 3, I initially started including the document ready stuff at the end of the actual plugin JS to save an extra HTTP request to the server, but since Vanilla 1.2 is going to include minnify, this becomes a bit of a moot point. I will go through the various plugins and move the document ready stuff out of the main JS files. This will also make things ever-so-slightly easier to update in the future.
2. Yes
1. Agreed.
I think it would also, perhaps, be a good idea for the "thickbox" option in InlineImages to be renamed to something else akin to "thumbnail inline images and open the full image in a modal window". That's overly wordy, but it gets across what I'm trying to communicate. This would add class="modal" to the link. Perhaps I should be suggesting class="modal" as the best way to use things like ColorBox...?
That way it would remain modal JS agnostic should ColorBox stop being maintained and replaced with something else in the future, as has happened with ThickBox. A class of modal also seems a little bit more semantic for the markup, which is always a nice thing to have if you can afford it
Until InlineImages is updated, I'll see about getting something in place to stop this happening.
However the way images are handled now are quite different.
The default allowed width for an image is quite large (5120px) but now there is client-side (JavaScript) sizing. It means that if an image is too wide to fit on the person's screen without creating a horizontal scrollbar, the image is resized to the perfect width for them. It's quite cool I think.
Client-side image resizing is all very well for not breaking your layout, but it doesn't address the alternative reason for using thumbnails - reducing initial bandwidth/load time.
Does this resizing kick in even without using InlineImages?
<muttering>I should probably download V1.2 and take a look for myself...</muttering>
Edit: Actually yes it does work without InlineImages, I forgot I had already coded that bit
If this is the case, then both the resizing and the "modal window" option can hook into the class="InlineImage".
Vanilla 2 (at this point) uses jQuery as it's JS library so there's less need for this plugin. However, the extra little JQuery plugins I've included should be relatively easy to port to V2.