NOTE: Images with an icon next to them have been artificially shrunk to better fit your screen; click the icon to restore them, in place, to their regular size.

This post is of interest only to Lightroom plugin developers.

Round about Lightroom 3.2, Adobe added support for intercepting “lightroom://” URLs, but have not documented it yet, so I'll do so here. It's particularly useful as part of an OAuth-authentication procedure.

What

You can have your plugin automatically respond to certain “lightroom://” URLs if they are formatted correctly, and if you add appropriate support to your plugin.

URL Form

After registering the appropriate handler in you plugin, as described below, the handler will be invoked when your system browser receives a URL of the form:

The “your.plugin.id” is the LrToolkitIdentifier in Info.lua. For example, the id for my Flickr plugin is “info.regex.lightroom.export.flickr2”, so it can be set to handle URLs such as:

etc.

How

Create a .lua file that returns a table along the lines:

return {
   URLHandler = function(url)
       -- The url string sometimes actually have a double quote as
       -- the first and last byte, so strip just in case.
       url = url:gsub('^"(.*)"$', "%1")

       -- Work with url here...

   end
}

Wrapping the function in a one-element table seems like an odd level of indirection, but that's how it works.

You then add a reference to that file in your Info.lua, as “URLHandler”. If the file is named “MyUrlHandler.lua”, for example, the reference in Info.lua would look like:

return {
   LrToolkitIdentifier = "info.regex.lightroom.export.flickr2",
   LrPluginName        = "jf Flickr",
   LrPluginInfoUrl     = "https://regex.info/blog/lightroom-goodies/flickr",

   LrSdkVersion        = 3.4,
   LrSdkMinimumVersion = 3.4,

   URLHandler = "MyUrlHandler.lua",
}

Within the URLHandler function, you can access parts of the URL (e.g. in an OAuth situation, the token) and stuff into global variables, and perhaps shut down a dialog that had been open by calling LrDialogs.stopModalWithResult(...).

That last bit seems to be unfortunately necessary... I've found that the handler is not properly invoked in some rare OS/browser combinations, so I feel that to cover all my bases, the plugin must open a dialog to tell the user to paste in their token; if the handler ends up working, the plugin can immediately shut down that dialog so the user is not bothered with it. Usually, that's exactly what happens, and it happens so quickly that the user never even sees the dialog.

I don't think Adobe's plugins do this, so maybe the problem has been on my end, but I thought I'd mention it because this is what my plugins do.