There were a few reports of issues with my Lightbox Mango Plugin in Internet Explorer (e.g. the "close" button wasn't working), and in the process of debugging them I noticed that I was using Lightbox 2.02 and the latest version is 2.04. Upgrading to Lightbox 2.04 resolves the IE issues, so you can find an updated version of the plugin here.

For the lazy, here's a direct download link for the latest version of the plugin.

Happy new year!

A couple of days ago I got a call from my dad. He was at my grandfather's house, working on the laptop he and my mom gave him for Christmas. One of the primary reasons for giving him the laptop was that it had a webcam, and they were setting him up on Skype to be able to video-chat with our enormous and widespread family. But now there was a problem. He wasn't seeing any video — mine or his — on his end, even though I could see him when we would call each other. Days before this, we had tested everything and it was working perfectly.

So what changed between the passed test and the failed test?

1. New location, ISP (Grandpa's house)
2. Installed Microsoft Office
3. Turned on Windows "Large Fonts"

My grandfather, like so many older people, doesn't have the greatest eye-sight, even with his glasses; and the Large Fonts feature of Windows really helps him use the computer.

As it turns out, this was the culprit. Changing back to "Normal" fixed the video problem. And through some clever tuning in the dialog found by clicking the "Advanced" button in that screenshot, you can make the fonts larger without using "Large Fonts," if necessary. I know Skype hasn't done this intentionally, and I've sent them a bug report via their suggestion form.

In the meantime, I hope this helps someone else out there trying to fix their grandparents' video problems.

Randy asks:

[With your Lightbox Mango Plugin] how do I setup lightbox to include multiple images in a lightbox slideshow?

Before I answer this, let's first talk about how to insert a single lightbox effect into your Mango blog, and then expand it into a slideshow.

Once you've got the plugin installed and activated, your New/Edit-Page and New/Edit-Post pages will allow for what TinyMCE (the WYSIWYG editor) refers to as "advanced linking." When you click the chain icon to create a new link, the dialog will be a little larger, and it will now have a few tabs inside it.

As seen above, the advanced tab is where you set the relationship to "Lightbox" — which indicates that when the link is clicked, Lightbox should try to display the image being linked to. The body of the link can be thumbnail images, as I've done above, or text as I'll do right here.

You may have noticed that if you click the left thumbnail above, and hover your mouse over the right half of the image, a small "Next" icon is displayed on top of the image, near the top right of it. That is because I've created a Lightbox Slideshow, as Randy asks about. Similarly, while viewing the second image, a "Prev" icon will display on the left while your mouse is hovered over the left half of the image. Unfortunately, slideshows aren't supported by the TinyMCE advanced linking dialog, but fortunately you have two fairly simple work-arounds to chose from.

The goal is to be able to edit the underlying HTML, and TinyMCE does provide a facility to do this: the "HMTL" button on the toolbar, next to last. I prefer not to use this button though, because it's yet-another-popup, and well… I'm particular. The other option is a small modification to Mango: follow Brian's instructions to give yourself the ability to toggle TinyMCE on and off. The first few parts of his article are optional in this case, the only important part is stuff under the heading "Toggle TinyMCE."

Once you can edit the underlying HTML, creating a slideshow is simple; and you can have multiple different groups in a single post or page. When you create your links and select the relationship of "Lightbox", the HTML generated looks something like this:

<a rel="lightbox" href="/foo/bar1.jpg">body1</a><br />
<a rel="lightbox" href="/foo/bar2.jpg">body2</a><br />
<a rel="lightbox" href="/foo/bar3.jpg">body3</a>

To turn these 3 separate lightbox images into one slideshow, change the above code to this:

<a rel="lightbox[GroupName]" href="/foo/bar1.jpg">body1</a><br />
<a rel="lightbox[GroupName]" href="/foo/bar2.jpg">body2</a><br />
<a rel="lightbox[GroupName]" href="/foo/bar3.jpg">body3</a>

Of course, GroupName can be any alpha-numeric string, so symantically the best thing to do is use something descriptive of the slideshow. If it's photos of your trip to Spain, call it "spain" or something similar. To create multiple separate slideshows, just give each slideshow a distinct GroupName.

Again, the body of the anchor tags can be anything you like. For brevity I've used the text "bodyN" in my code, but you can replace that with an image tag to have thumbnails that you click for a larger version. Just be sure to physically resize and save smaller versions of your images as thumbnails, because using width and height attributes in the image tag does not affect the size of the file that the browser has to download, causing slower loading times. This is a big faux pas of online photo galleries.

I'll end with a tip/trick you can use to put a multi-image slideshow on a page without showing all of the thumbnails or using text to link to each image. Instead, start with one image/text link to the first image in the slideshow, and follow it with empty anchor tags to the rest of the images, like so:

<a rel="lightbox[GroupName]" href="/foo/bar1.jpg">body1</a><br />
<a rel="lightbox[GroupName]" href="/foo/bar2.jpg"></a><br />
<a rel="lightbox[GroupName]" href="/foo/bar3.jpg"></a>

I'm not sure how this would sit with usability people who worry about screen readers and other things like that. Maybe Mark will stop by and comment on that?

As your Mango Plugins get more complex, you will find yourself needing to include a JavaScript file on pages, or access images, css, or other resources. With some work, you can programatically find the path to your plugin's folder inside the components/plugins/… folder, but that's a bad idea.

Well, it breaks convention… so it's sort-of bad.

One of the folders in the root of every Mango install is the assets folder. Inside are two more folders: plugins and content. The content folder is the default place that files are stored when you use the File Explorer in your Mango admin to upload files. The plugins folder is intended to house files that a reader will need remote access to.

Convention dictates that when your plugin is activated, it should place any files that will be accessed remotely (ajax, css, images, js, etc) into [mango]/assets/plugins/[plugin name]/. For instance, my Lightbox2 plugin copies a dozen or so css, js, and image files to its asset folder; and then the plugin itself injects HTML onto pages that access the files in this location.

Convention also dictates that when the files are no longer needed — when your plugin is de-activated — you should remove them. Clutter is bad, mmkay?

I wouldn't say the code to accomplish this is necessarily overly complex, but it's certainly going to be frequently repeated, which means it's a good case for some encapsulation.

Here are two methods I've written that will copy the contents of [mango]/components/plugins/user/[plugin name]/assets/ to [mango]/assets/plugins/[plugin name]/, and delete them.

<cffunction name="copyAssets" access="private" output="false" returntype="void"
   hint="I'm used during plugin activation to copy files to a public location">
      
      <!--- copy assets to correct public folder --->
      <cfset var local = structNew()/>
      <cfset local.src = getCurrentTemplatePath() />
      <cfset local.src = listAppend(listDeleteAt(local.src, listLen(local.src, "\/"), "\/"), "assets", "/")/>
      <cfset local.dest = expandPath('#variables.blogManager.getBlog().getBasePath()#/assets/plugins/#variables.name#')/>
      
      <!--- create the destination folder if it doesn't exist --->
      <cfif not directoryExists(local.dest)>
         <cfdirectory action="create" directory="#local.dest#"/>
      </cfif>
      
      <!--- copy our assets to the root/assets/plugins/RelatedEntries folder so that they are web-accessible --->
      <cfdirectory action="list" directory="#local.src#" name="local.assets"/>
      <cfloop query="local.assets">
         <cffile action="copy" source="#local.assets.directory#/#local.assets.name#"

destination="#local.dest#/#local.assets.name#"/>
      </cfloop>

   </cffunction>

   <cffunction name="clearAssets" access="private" output="false" returntype="void"
   hint="I'm used during plugin de-activation to remove public files">

      <cfset var local = StructNew()/>
      <cfset local.dir = expandPath('../assets/plugins/#variables.name#')/>

      <!--- delete assets --->
      <cfdirectory action="delete" directory="#local.dir#" recurse="yes"/>
      
   </cffunction>

To use them, simply add <cfset copyAssets() /> to your setup function, and <cfset clearAssets() /> to your unsetup function. The copyAssets funtion is not recursive, which means you can't use sub-folders. It would be simple enough to convert to recursive, so I won't include that here.

This methodology also facilitates really keeping your plugin architecture simple. Again, using my Lightbox2 plugin as an example, here are the contents of the plugin folder:

And the contents of the assets folder:

Pretty straight-forward, right?

So now that you're copying your resource files to the appropriate folder for remote access, how do you get that URL?

I'm glad you asked…

Similar to finding out what DBMS the current Mango install is using, you can use Mango's API to find its base path and then build on it. Remember: not all users will install Mango to the root of their site. It could be in /blog, /some/other/folder, or anything else. This practice will make sure your plugin works no matter where Mango is installed.

The method that will return the blog base path is getBasePath() and it belongs to the blog object, so you get its value like so:

variables.blogManager.getBlog().getBasePath()

Remember that variables.blogManager is a variable passed into and saved from the plugin's init function.

If Mango is installed at the root of the site, this method will return "/". If installed at /blog, it will return "/blog/" — it always has the trailing slash.

From there, add "assets/plugins/[plugin name]/" and your files are ready and waiting.

What, you want an example of that too? Ok, here's some code from my Lightbox2 plugin that adds the css and JavaScript files to a page:

<cfset data = arguments.event.outputData />
<cfset data = data & '#chr(13)##chr(10)#<link rel="stylesheet"

href="#variables.blogManager.getBlog().getBasePath()#assets/plugins/#variables.name#/lightbox.css" type="text/css" media="screen" />'/>
<cfset data = data & '#chr(13)##chr(10)#<xscript

src="#variables.blogManager.getBlog().getBasePath()#assets/plugins/#variables.name#/prototype.js" type="text/javascript"></xscript>'/>
...
<cfset arguments.event.outputData = data />

Note that I had to replace "script" tags with "xscript" tags for them to be displayed here, just drop the X.

Over the last few days I've had some time to update a few plugins and clean up my project pages.

Mango-Lightbox2:

Now at version 0.9, I've:

• Fixed a bug that caused broken images when Mango wasn't installed at the root of the site
• Overhauled the file-system usage to properly put and access resource files in [mango]/assets/plugins/pluginName/ instead of accessing the files from the [mango]/components/plugins/… folder
• Fixed a few trivial bugs

Download the latest version from the RIAForge project page.

Related Entries:

Version 0.2 is now compatible with CF 7 and 6 (untested on 6, but it should work). Previously, I had used a CFC Method with a returnFormat="JSON", which was introduced in CF8. To work around this issue, I incorporated Nathan Mische's JSONUtil.cfc (Thanks, Nathan!) to do JSON Serialization, and added a proxy template to convert the WDDX result to JSON for AJAX usage.

The plugin formerly known as Comment Whore:

Back in July I created a plugin called Comment Whore that adds a sort of comment summary page to Mango's admin dashboard. While I still feel the name is accurate (and derived from the behaviour that inspired the plugin), I realize that it is a little "family-unfriendly" and want to rename it before I post it on RIAForge. If anyone has any ideas for a new name, I'd love to hear them.