We build WedSchedulePro, a social media scheduler for photographers and wedding suppliers. The part people ask about most is the Lightroom Classic plug-in: you publish a collection in Lightroom and the photos land in your library, ready to caption and schedule. We're now past version 1.80 of it. These are the lessons that cost us the most, so they might save you some.

Why a Publish Service, not an export preset

An export preset writes files to a folder. A Publish Service is a destination that remembers what it has sent. Lightroom tracks every photo in a published collection: new, modified since publish, or published. Edit a photo after sending it and Lightroom marks it for re-publish by itself.

For a photographer, that's the job after the gallery is delivered. You already have a collection of the best shots. Publishing it should be the last click.

Lua 5.1, and not quite the Lua 5.1 you know

Lightroom Classic runs plug-ins in Lua 5.1.4. No //, no bitwise operators, no table.unpack (it's the global unpack), no goto. And Adobe's SDK guide says plainly that Lightroom does not support the module system Lua 5.1 introduced: there is no package table.

That has three consequences we learned the hard way.

1. import for Adobe's modules, require for yours. Lightroom's own namespaces are injected through import:

local LrHttp  = import 'LrHttp'
local LrTasks = import 'LrTasks'
local json    = require 'json'   -- our own file, at the plug-in root

require 'LrHttp' fails with "Could not load toolkit script", because it looks for a file that isn't there.

2. Keep every module flat at the plug-in root. require 'lib.retry' looks reasonable and passes every desktop test, because desktop Lua resolves dotted names through package.path. Lightroom has no package.path. It looks in the plug-in root only, by bare name. We shipped the dotted version once. Every test was green, and the plug-in didn't load.

3. Your test runner isn't Lightroom. Stock Lua 5.1 is hard to install now, and the lua on most machines is 5.4, which happily accepts syntax Lightroom rejects. We run our pure-Lua tests under LuaJIT (it reports itself as Lua 5.1). Even LuaJIT accepts goto and bitwise ops as its own extensions, so a small linter in our pre-push hook blocks those too. Green tests prove the logic. Only a load inside Lightroom proves the plug-in loads.

Info.lua is not a normal Lua file

The descriptor is read in a restricted environment: no import, no require, only string, LOC and a few globals. It declares things. It doesn't run them.

That includes the publish service itself. You don't "register" a provider at runtime. You declare it:

LrExportServiceProvider = {
  title = "WedSchedulePro",
  file  = "WSPPublishServiceProvider.lua",
},

One key we got wrong: the OAuth callback handler is declared as URLHandler, with no Lr prefix. Ours said LrUrlHandler, so the handler never registered. Nobody noticed for a while, because our paste-the-code fallback hid it at the time.

Talking to a web API from inside Lightroom

Sign-in. We use OAuth with a browser hand-off and a lightroom:// redirect back into the plug-in. That redirect can be flaky, so we shipped a paste-the-code dialog as a backup from day one. Once we fixed the two real causes of the flaky redirect, we retired it. The plug-in now says plainly when the browser hand-off hasn't come back, and offers to reopen it. Have a backup while you find out why the redirect fails.

LrHttp must run inside a task, and it yields. Lua 5.1 can't yield across a C-call boundary. Wrap an LrHttp call in a plain pcall and you get "Yielding is not allowed within a C or metamethod call". Inside an async task, use the yield-safe version:

LrTasks.startAsyncTask(function()
  local ok, body, headers = LrTasks.pcall(LrHttp.get, url, requestHeaders)
  -- ...
end)

We have fixed this class of bug in more than one release, each time sure we had found the last one. Our rule now is to re-check every pcall on every pass, and to judge each by what it wraps.

Read failures the way LrHttp reports them. A network failure doesn't throw. You get a nil body and an info table describing the error. A server error comes back as a normal body with headers.status set. Those are two different branches, and you want both.

It follows redirects and caches GETs. You can't read a 302's Location, so don't build sign-in on catching one. And a status poll that never changes is probably being served from cache: send Cache-Control: no-cache.

Guard every file before postMultipart. If a rendition's temp file has gone, postMultipart crashes while computing the content length, and you can't catch it. Check the file exists, is readable and has a size before building the request.

One photo at a time, and never fail the whole batch

The render-and-upload loop handles one photo at a time behind Lightroom's own progress bar, so cancel works and nothing is left half-sent. Two rules made it dependable:

• Record what you uploaded. Every success calls rendition:recordPublishedPhotoId(id). Skip it and Lightroom re-uploads that photo every time you publish.
• A failed render fails one photo. rendition:waitForRender() can fail in Publish where Export works. Mark that photo failed, carry on with the rest, and say clearly at the end which ones didn't go.

What a Publish Service can't do

Publish Services can't export video. We don't treat that as an error: the plug-in sets videos aside before rendering, finishes the publish, and names each skipped file in the end-of-publish summary.

Small things that cost us a day each

• Bump the version on every change that changes behaviour. A plug-in is a frozen copy on someone else's disk. Without a version that moves, you and a customer can't agree on what's installed.
• Lua 5.1 has one number type. Keep IDs and tokens from your API as strings, end to end.

If you're a photographer who'd rather publish straight from Lightroom than AirDrop photos to your phone, that's what we built: the WedSchedulePro Lightroom plug-in.