Jeffrey’s “Collection Publisher” Lightroom Plugin

This Lightroom “Publish” plugin allows you to export copies of your Lightroom photos to local disk in a folder hierarchy that mimics the collection hierarchy you build within Lightroom.

This plugin works in Lightroom 6/CC (and older versions as far back as Lightroom 3, though some features depend on the version of Lightroom).

The same download works for both Windows and Mac. See the box to the upper right for the download link (in orange) and installation instructions.

This is a sister plugin to my Folder Publisher plugin, which is similar to this plugin except that Folder Publisher creates a layout on disk that mirrors the images' folder hierarchy instead of their collection hierarchy.

Unlike a normal export, this Publish service allows you to create an ongoing relationship between the photo in Lightroom and the copy on disk. The tree on disk is refreshed for any changes (new images, removed images, and image changes) each time you “Publish”. I've found it very convenient to publish selected collections of portfolio images for my iPad.

Here's an overview of what it looks like in the Publishing Manager.. the areas marked in red are from this plugin (with the blue and green items being from other plugins that I happen to be using in this example):

The plugin is normally used in the following pattern:

  1. Initial setup of the publish service.
  2. Initial setup of the collection hierarchy within the publish service.
  3. Populate the collections with images.
  4. “Publish” them, causing copies of the images to be reflected into a hierarchy on disk matching the collection hierarchy in Lightroom.
  5. Going forward, any time changes are made (images updated, added, or removed), “Publish” causes those changes to be reflected on disk.

Publish-Service Setup

When setting up a new publish service, you first assign a name, though you can leave it blank if you'll only have one...

You indicate where published copies are to be placed by specifying the root of the publish tree. When first setting up a new publisher, you'll likely want to pick an empty folder as the root.

The next sections are all part of the standard Lightroom export. In them you decide the size and quality of the published copies...

The next two sections shown in the example aren't included unless you specifically add them:

They're from my crop for iPad and Metadata Wrangler plugins; I use them in my exports to allow me extra control of what metadata is included in each exported copy, and in the case of my iPad portfolio, special iPad-specific crops so that some images better fill the screen.

The next section controls what changes in Lightroom should cause published images to be slated for republish.

Then we have a plugin-specific seciton on file renaming that gives much more flexability than Lightroom's standard “File Naming” section, should you need it:

This allows you to have the files for the exported copies named derived from image matadata using template tokens that are processed on the fly for each image.

The next section provides a way to do an FTP sync of the published copies, should you need it. Photo-viewing iPad apps tend to allow updates via FTP sync, so this section is convenient for that.

It's here as a convenient tool rather than an actual part of the configuration; the FTP sync is never automatic... it happens only when you launch it manually from the Publishing Manager.

The plugin also provides a way to import and export settings, making it easier to set up comparable publish services on multiple catalogs (such as when part of your library is on your desktop, and part on your laptop, as is my case).

When first setting up a service, you'll have the ability to import settings...

... but once it's been set up the first time, after that the section allows for export:

Collection Setup

Once you've got the publish service created, its context menu (alt-clicking or right-clicking on it in the left hand side of Library) brings up a menu allowing you to create collections or sets...

Collections can contain images, while collection sets can contain collections and other collection sets. It's different from the normal file/folder hierarchy on disk because images can only go into collections, and not into collection sets. This makes it inconvenient and unnatural to mapping between how you must organize images within the plugin and how the plugin writes them out to folders and files on disk, so I've built two ways to do it; hopefully at least one will make sense...

When you create a collection in the plugin, you have three choices for the Collection Type, which determines how the plugin treats photos in the collection when outputting copies during Publish:

If the “Collection Type” is “Its own sub-folder”, the collection name (“Travel” in the example above) becomes a sub folder in the publish destination, and images in the collection are placed in the sub-folder. This is likely the most common collection type for most folks.

When the collection type is “Part of its parent”, the name of the collection is not used by the publish system. Instead, exported copies are placed into the folder of the collection's parent collection set.

(The third option, A mirror of..., is discussed below.)

Let's look at an example, two ways to put images into a “Japan” sub-folder within “Travel”:

  1. Invoke “Create Sub-Folder or Mirrored Collection Set” named “Travel”, then within it create a collection named “Japan”, being sure to select “its own sub-folder”.

  2. Invoke “Create Sub-Folder or Mirrored Collection Set” named “Travel”, then within it create another sub-folder named “Japan”, then within that create a collection, with any name, being sure to select “Part of its parent”.

Mirroring Pre-Existing Collections

A new, experimental feature as of August 2015 allows the plugin to mirror (automatically keep in sync with) collections you already have elsewhere in your catalog.

This mirroring feature is a bit fragile because what it aims to do does not fit easily into how Lightroom's plugin infrastructure has been designed. In trying to implement this feature, the plugin is pushing the envelope with what Lightroom can do, and as a result some loose ends can potentially make for surprises if you (the user) don't keep the important caveats discussed below in mind

When creating a collection or collection set with this plugin, you have the option to mirror a collection or an entire hierarchy of collections. When one collection is mirrored from another, the plugin semi-automatically keeps the set of photos in one updated to reflect any changes in the other.

For example, consider these normal collection in a Lightroom catalog:

If we've spent time curating the Travel set of three collections and would like to see that set mirrored in the Collection Publisher so that we can have a local hierarchy of copies on disk, we right click on the Collection Publisher and choose Create Sub-Folder or Mirrored Collection Set to bring up the set-creation dialog:

We've selected Mirror collection tree rooted at... and then pulled up Travel from the list of sets. (The list includes all collection sets in your Lightroom catalog except those within a Collection Publisher service).

After having selected the Travel set, the name of the new published set to be created is pre-filled in as MIRROR: Travel and can't be changed.

Upon pressing the [Create] button, we see the new MIRROR: Travel set in our publish service, filled with the three new collections and pre-populated with respective photos from the three source collections:

The MIRROR prefixed to the name is there to remind you that the plugin is supposed to have control over it and its contents, and that you shouldn't manually make any changes to the collections or add/remove photos within (they should be added/removed in the source collection this publish collection mirrors). More on this in a moment in Caveats below.

In the example above, the publish collections have been created but they haven't actually been published yet — all the photos in them are in New Photos to Publish — but you can publish them individually (click on their name then on the [Publish] button), or en mass via File > Plugin Extras > Refresh and Publish Mirrored Collections.

The Caveats of Mirroring

As noted above, this well beyond what Lightroom's plugin infrastructure was designed to handle, so it's not as smooth as one would like...

  • We'd like for the mirroring to be completely automatic, but unfortunately Lightroom's plugin infrastructure doesn't allow for it. Rather, mirrored collections are synced only when they are published, and/or when via File > Plugin Extras > Refresh and Publish Mirrored Collections is invoked.

    Publishing a single collection via [Publish] syncs and publishes just that collection, while invoking the Refresh and Publish Mirrored Collections syncs (and optionally publishes) all Collection Publisher collections. Depending on the changes made during the sync (discussed below), syncing via the [Publish] button may leave some photos in the Deleted Photos to be Removed section of the collection, so it may need to be published once more to finally push out all changes.

  • Syncing means that the target collection in this plugin is made to have the same photos as the source collection it mirrors, so any extra photos here but not there are deleted (even if you had manually, specifically added them here), and any photos there but not here are added (even if you had manually, specifically removed them here). It would be nice if this were a full two-way sync, but the plugin has no idea why a photo might be in one place and not the other (did you remove it there or add it here?), so it's a simple make this look like that.

  • Given that it's a simple one-way sync, it'd be nice if Lightroom disallowed local changes (that is, disallowed adding/removing photos to the publish collection), but such restrictions are not possible with the current plugin infrastructure, so if you forget a collection is mirrored and start adding/removing images, that work will be silently lost at the next sync. That's why the collection name has MIRROR prepended, to remind you.

  • The same can be said for mirrored sets. If you add/remove collections within a mirrored set, that work will be undone at the next sync when the collections are re-mirrored back from the source set.

  • Once a mirrored collection is set up, it can't be edited or modified because there's nothing to edit or modify. (It's renamed by renaming the collection it mirrors and then syncing.) However, it can be deleted via the context menu for its name in the publish-services list.

  • Similar to the previous point, mirrored collections can't be moved within the published-collection sets of the publish service, nor can other collections be moved or created within a mirrored collection set. If you want to add or subtract collections, do so in the original source being mirrored and then sync.

  • There's a bug in Lightroom that has the potential to cause some havoc with collection creation. Due to this bug, the collection-creation part of the plugin sometimes gets confused about where within your publish service a collection is about to be created, and so sometimes mistakenly gives a can't create a collection within a mirrored collection error, or sometimes might not give it when it should.

    The bug can happen when you have a collection or set selected for display in Loupe/Gird at the time you bring up the collection-creation dialog...

    Lightroom conveniently pre-fills the Set in the collection-creation dialog with whatever set is associated with the selection at the time it's invoked...

    The bug is that if you change the Set in the dialog, information about that change may or may not be passed to the plugin.

    The workaround is to make sure that either no collection-publisher collection is selected when you invoke the collection-creation dialog, or that only a root-level collection is selected.


This plugin is distributed as “donationware”. I have chosen to make it available for free — everyone can use it forever, without cost of any kind — but unless registered, its functionality is somewhat reduced after six weeks.

Registration is done via PayPal, and if you choose to register, it costs the minimum 1-cent PayPal fee; any amount you'd like to add beyond PayPal's sliding fees as a gift to me is completely optional, and completely appreciated.

Note: a Lightroom major upgrade, such as from Lr4 to Lr5, de-registers the plugin in the upgraded version, so if you want to maintain registration, a new ($0.01 if you like) registration code is needed in the upgraded version. It makes for a hassle every couple of years, I know. Sorry. See this note for details.

For details on plugin registration and on how I came into this hobby of Lightroom plugin development, see my Plugin Registration page.

Version History
( Update Log via RSS )


If there's an error exporting one particular image, try to continue with others and merely have Lightroom report a summary of errors at the end.

Added support for sequence numbers on publish. See the "sequence numbers" link in the "Enhanced File Renaming" section of the dialog.

Added {SpeedKPH} and {SpeedMPH} to the list of template tokens supported by my plugins.

The {People} token wasn't working properly for some keywords without a registered birthday.


Allowed the Enhanced File Renaming to actually create sub-folders under where an image would normally be placed.

20150822.68 Added extra debug logging to track down file-copy issues.

Added the ability to automatically mirror normal Lightroom collections in this plugin; See this link for details.


Fixed the "SpecPeople:259: attemt to index al nil value" error.


If the root folder of the publish tree had a very long name, the view/change buttons would be pushed off the edge of the screen.


In the "Enhanced File Renaming" section, add the ability to override the extension on the exported filename.


In the POODLE-vunerability dialog, display a raw URL of a page on my site that discusses the issue, so that folks can be independently sure that the dialog is indeed from me and not malware.


Fix to the date_diff() function supported by the LUA template token.

Updated the camera-name code to try to guess the actual camera model of Hasselblad H5D files, since in their infinite wisdom Hasselblad decided to encode three distinct models with the same internal code, making it impossible to know for sure what camera produced a given image file.

20141219.61 Added a bit more debug-logging for when a file copy can't be done.
20141019.60 Windows Only: Add a one-time check for the POODLE security vulnerability, and alert the user if it exists.
20140923.59 Added the LrMD5, LrLocalization, LrSystemInfo, and LrMath packages to the {LUA} template token.
20140902.58 If the plugin failed to create such-and-such a folder because a file of the same name already exists, report the details to the user.
20140828.57 Extra debug logging to track down a folder-creating problem on some systems

Made the {GPSAltitude}, {Altitude}, and {GPSCoordinates} tokens subject to the geo-privacy settings like the other geo-related tokens.

20140731.55 Registration fix for Lr5.6
20140720.54 More Creative-Cloud support.

Fixed an issue with Creative-Cloud revalidation.


Lr5.5 and later Creative-Cloud installs can now revalidate themselves if needed.

20140710.51 Sigh, had a bug in the Creative-Cloud support.

Now supports Lr5.5+ Creative-Cloud Installs.

20140704.49 Sigh, introduced an error for some folks with the rebuild the other day.
20140630.48 Build-system update

Added date_diff() and raw_time_diff() functions to the special {LUA} token understood by the plugin.

20140612.46 Under some error conditions plugin would crash instead of presenting the proper error message.
20140514.45 Got rid of a "Done" confirmation dialog that's not really necessary.

Added new tokens to the template language the plugin understands: LrVersion, LrVersionMajor, LrVersionMinor, LrVersionRevision, LrVersionBuild, Location, CatalogName, CatalogPath, OperatingSystem, OS

Added new token filters: NS and LO

20140423.43 Fix a location-related template-token bug introduced in a recent build.

Fixed a bug in the "smoother revalidation" stuff recently added.


Enhancements to the FTP stuff: take care not to work with "." and ".." that some servers return.

Make the revalidation process smoother, especially for folks using Lr5.4 and later.

The {Empty} template token wasn't working properly.


Internally track whether exports are via the master image or via a smart preview. In the future this may allow for a "republish those for which a master is now available" feature.

Worked around a mysterious "attempt to get length of a nil value" bug.

20131213.39 Added {PublishCollectionName}, {PublishCollectionDepth}, and {PublishServiceTitle} tokens to the preset templates. See template-token web page for important restrictions.
20131102.38 Update for OS X Mavricks
20131010.37 Yikes, it seems that version 20130905.36 broke the "Metadata that Triggers Republish" section, clearing all items you might have had set (well, all but Caption). Sorry about that. Please visit the "Metadata that Triggers Republish" section to reconfigure to your liking.
20130926.36 Oops, fix a bug introduced in the previous update

Added a bunch of tokens to the preset templates supported: ExportFormat, ExportColorSpace, ExportBitDepth, ExportQuality, ExportSharpeningLevel, ExportSharpeningMedia, IpernityUrl, GoogleDriveUrl, and TumblrUrl.

The token-examples dialog had been broken. Also deprecated Folder and Path tokens in preference to FolderName and FolderPath tokens.


Work around a Lightroom bug concerning the determination of whether a photo is offline.


Respond more gracefully when enhanced file renaming can't come up with something valid.

Fixed the KW/KWE tables in template tokens; they had been broken when using load for the script.

Added an "Ask" option to the "Export with Smart Previews?" section, so one can be alerted to the situation at each export.

Made the file time control stuff (added in the previous update) optional, because it imparts a (small) performance penalty. The default is set to "off", so you'll need to re-enable it if you actually care about the file date/time stuff.


When "Format" is "ORIGINAL" (meaning to spit out the original image pixels with new metadata, instead of the developed version with new metadata), the plugin didn't handle XMP sidecars properly at all. Now it does.

You now have control over the file time of exported copies (set to the image capture time, or the time of export).

20130620.31 Allow published copies to remain on disk even if a photo is deleted from Lightroom.
20130613.30 Better support for plugin revalidation.
20130612.29 A failure for the plugin to copy a file on disk resulted in a plugin crash instead of the appropriate error message display.

Added the ability in Lr5 to export images even if the master image file is not available, so long as there's a smart preview available.

20130611.27 Yet another Lr5 update
20130610.26 Final update for Lr5
20130513.25 More changes for the root-selection problem... really seems to be a bug in Lightroom, but it's hard to tell because I can't replicate the bug myself.
20130501.24 Update for Lr5
20130412.23 Build system update.

More with with the code that handles changing the root of the publish tree.


Added support for some new template tokens: FlagStatus (requires Lr4.1 or later), and for Lr3 and later, a bunch of IPTC extended metadata: AdditionalModelInfo, CodeOfOrgShown, DigImageGUID, Event, ImageSupplierImageId, MinorModelAge, ModelAge, ModelReleaseID, ModelReleaseStatus, NameOfOrgShown, PersonShown, PlusVersion, PropertyReleaseID, PropertyReleaseStatus, and SourceType.

20130209.20 More build-system maintenance
20130206.19 Tweak for my registration system

The plugin wasn't robust against case-only changes in filenames or folders. This is a real pain because such names (e.g. "test" vs. "Test") appear different to the plugin, but they refer to the same underlying file on most filesystems for most users (because most Windows and OSX file systems have case-insensitive file naming). There's no easy way for the plugin to make such renames, so the plugin now reports that it won't work for existing files, and offers a chance to abort along with info on how to actually get it done: rename to something different (e.g. from "test" to "test2", then from "test2" to "Test").

While doing a rename, Lightroom pops up a "this may take a while; proceed?" dialog, and if the user canceled it, the plugin neglected to cancel the entire update, leaving things in an inconsistent state.

20121210.16 Added some extra debug logging.
20121024.15 Allow Video to be FTP'd as well.

Workaround for an "attempt to call field 'getProgressScope'" bug introduced in Lr4.2.

Disallow DPX video export because it breaks things.

Enhance the {EMPTY} template token so that it interrupts the squelching of superfluous joining characters.

20121004.13 Oops, hte file-extension thing got worse, not better... reverting that change.

Work around a "situation" (likely Lr bug) where exported video loses its file extension.

More debug logging for the elusive "no root folder" problem.


Updates to the environment in the {LUA} token (in the template tokens in my plugins) to include photoTime() and currentTime(), and other changes to match the updated docs at that link.


Added the ability to create dynamic destinations on disk via naming patterns using plugin templates. This is a pretty big change, so you may want to test carefully before using it wholesale.

Reduced the amount of debug logging done, unless the "debug logging" option is checked in the plugin manager.


Oops, I was moving the original XMP file (when the Publish format was "Original" instead of copying it. Fixed.

Update to handle the Mac App Store version of Lightroom.


Added the ability to move/reset the root folder. As a byproduct, this should allow the "choose a root folder" situation to be repaired.

In some crazy file-renaming situations, the plugin could get confused about the file extension.

Enhanced the send-log dialog to hopefully make reports more meaningful to me, yielding, I hope, the ability to respond more sensibly to more reports.

Added to the template tokens supported by the plugin: {FullMasterFile}, {FullMasterFolder}, {FullExportedFile}, and {FullExportedFolder}


When a new collection is created, require that the type be explicitly selected. This may help avoid screwups when one doesn't notice that there are different types to being with.

Update to handle 4.1RC

20120315.6 Add some extra debug logging to try to track down some network-folder errors.

Update to the debug logging to better track down timing issues that might arise.


Wasn't handling some kind of file-rename templates properly.

Now handles things much more gracefully when some files are offline when the publish is started.

Better support for video in Lr4.

20120217.3 Didn't handle XMP sidecars correctly when publishing original raw files.
20120217.2 Discovered why "metadata that triggers a republish" wasn't reliable, and fixed it.
20120213.1 Initial release, evolving from my earlier tree-publisher plugin, which dated back to the summer of 2010.

The 30 most-recent comments (out of 79; see all), most recent last...

Hi Jeffrey,

Fixed the problem by moving the plug-in home folder to a real Windows folder instead of a samba share. Running jpegtrans from a samba share seems to be the problem.


— comment by Jos van der Woude on September 1st, 2014 at 12:05am JST (1 year, 3 months ago) comment permalink

I was having this problem, after I read and reloaded LR it worked correctly.

Thanks Jeffery

— comment by James Lascek on December 24th, 2014 at 2:11pm JST (11 months, 6 days ago) comment permalink

Jeffrey, I’m a huge fan of your products. While you track down the “move” error in jf Folder and jf Collection publisher, why don’t you change the error warning box so that it doesn’t require the user to press Enter … that way other publish runs could continue running as opposed to waiting for the user to press Enter.

Fundamentally the “move” error should not happen except in extraordinary cases (target disk full, target disk no longer present, etc.), so it makes no sense to try to continue in those situations. It’s possible for the error to come back for other reasons (perhaps unlucky timing somehow?), but as you mention in another comment elsewhere, it’s a huge can of worms to try to figure this stuff out, for little global benefit but some data-loss risk (and a lot of productivity risk on my part), so I’m inclined to leave it as it is, sorry. —Jeffrey

— comment by Cris on January 14th, 2015 at 1:31am JST (10 months, 17 days ago) comment permalink

Hi Jeffery,

Can you tell me where (on disk) the FTP Sync destination preset files are stored for the Collection Publisher? I’m running LR4 on Mountain Lion.

Thanks in advance,


They’re all handled by Lightroom (the FTP presets are a black box to the plugin). You should find them in your ~/Library/Application Support/Adobe/Lightroom/FTP Presets along side other folders for various kinds of presets. My system-info plugin will show you exactly, if you need. —Jeffrey

— comment by Michael Pollack on February 10th, 2015 at 5:18am JST (9 months, 19 days ago) comment permalink

Hi Jeffery,
Congrats and thank you for your great plugins set.

I have just found a problem with the Collection Publisher, once you have created the path initially there is no way to change it because the Lightroom Publishing Manager window does not allow you to go wider. So the “Publish Tree” button is not accesible (if) because the root is quite long…

Just let you know to see if can be fixed.

Thank you (and please excuse my english)

Good catch, thanks. Fixed. —Jeffrey

— comment by Luis on February 22nd, 2015 at 12:29am JST (9 months, 9 days ago) comment permalink


I’ve just installed the standalone Lightroom 6 and downloaded the latest version of Collection publisher, installed it and restarted LR 6. But it says that the Nil plugin has not been installed.

Appreciate any help.

It sounds like a generic “corrupt plugin install” kind of thing… check out this faq —Jeffrey

— comment by Alan C on April 23rd, 2015 at 4:12am JST (7 months, 8 days ago) comment permalink

I must admit I’m disappointed. The name “Collection publisher” and the first paragraph of the the page (“… that mimics the collection hierarchy you built within Lightroom”) is building false expectations.

Now that I searched the comments and reread the sparse examples (at least 3 times), I understand.

It is not mimicking the collection structure that I carefully built in the “Collections panel of LR. Instead, I’d have to recreate this same structure in plugin’s Publishing panel! Were’s the logic in that?

I understand that it’s a limitation of Lightroom, but I do believe that you should document this limitation clearly on top of this page! Tell the people what to expect and what not.

For me it’s too late; I’ve registered for a plugin which I cannot use – I guess I can mimic the folder structure, but I had registered that plugin already.


— comment by Peter on May 10th, 2015 at 10:24pm JST (6 months, 20 days ago) comment permalink

Hi Jeffrey

Just updated to Lightroom CC from Lightroom 5. Hoped I would just need to re register, but LR telling me the plugin isn’t compatible. I’ve downloaded the latest version but still no joy. Are there any plans to update the plug in or am I doing something wrong. Thanks.


Modern versions of my plugins work fine on LrCC… are you sure you pointed the Plugin Manager at the new copy? —Jeffrey

— comment by John W on May 14th, 2015 at 11:53pm JST (6 months, 16 days ago) comment permalink

First – thanks for all your LR plugins!

2 Questions –

1) I’m using LRCC and have a massive organized SM site (currently published using the SM branded plugin) that I now need to ‘mirror’ on a shared network drive. Would this plugin work for a) the initial setup / mirror of at least the structure and images and b) for future folders and galleries?

2) I have an additional ~40k image archive organized in LR but not published to SM – same questions as above would this plugin work to allow me to ‘click and drag’ the folder hierarchy and images over to our new network drive as a published collection?

Or…. is your other ‘folder publisher’ the way to go for either of those?

For issue #2, Folder Publisher could indeed solve the problem… just create a single smart collection that refers to whatever you want to be sent to the network drive. In testing it as you set it up, take advantage of the fact that you can hold the option/alt key down to turn the [Publish] button into [Publish Selected]…. trying to invoke a publish operation on 40k photos may crash Lightroom before the plugin ever gets control. For the first issue, unfortunately I don’t have a good solution… lots of folks want to mirror their collections, but I just can’t think of a way to do it with the slim pickings that Lightroom supplies for plugins in this area. )-: —Jeffrey

— comment by jhelms on May 27th, 2015 at 12:38am JST (6 months, 4 days ago) comment permalink

Hi, I wonder if I can have certain types/groups of keywords which can then be written into file names on export?


There could be a keyword group “abbreviations” and in that group are as keywords “aa”, “bb”, “cc” etc for one image, and in the same group another image would have “xx”, “yy” and “zz”.

When these are exported then I would like the one image to be automatically named “aa-bb-cc.jpg and the other xx-zz-yy.jpg by using these tags.

Is that possible in Lightroom (or Bridge)? I found many general infos when googling, but nothing concrete enough to get that information.

Thanks for sharing your expertise !

You might be able to whip something together with the plugin’s “Enhanced File Renaming” and a well-crafted {LUA} token. I would require some programming experience, but should be possible. —Jeffrey

— comment by Tom on May 30th, 2015 at 4:07am JST (6 months ago) comment permalink

Hi Jeffrey,

It will be great to have the option to export multiple resolution images (web &v devices) from Collection Publisher.

Is there any alternative way to do that please?

I´m working with a very large collection of images using the collecion publisher plug in and i need to export all of them on several different sizes…

Any clues please

Thanks a lot in advance

Unfortunately I don’t have an easy answer for you. The best idea I have at the moment is to have the plugin export the largest size you want, but as part of the “Post Processing” (perhaps via my “Run any Command” plugin) invoke an external command that will take the newly-exported version and produce the smaller versions you want. —Jeffrey

— comment by Luis Munoz on June 18th, 2015 at 7:22am JST (5 months, 13 days ago) comment permalink

thank your for your kínder reply Jeffrey

I have been researching for a tool or plug in that helps with this type of tedious job and surprisingly there are very few options to choose

This could be a very interesting plug in to develop


Best regards

— comment by Luis on June 18th, 2015 at 5:14pm JST (5 months, 12 days ago) comment permalink

Should the LR6 new “Duplicate Smart Collection” work with Collection publisher? I get assertion error

Yikes, I hadn’t noticed this addition. I would expect it would not work, since it doesn’t know about plugin-specific collection data, and what can and can’t be duplicated. —Jeffrey

— comment by Petri Helenius on June 21st, 2015 at 2:31am JST (5 months, 10 days ago) comment permalink


I’ve been using on of Rob Coles plugins until LR CC, where it stopped working unfortunately.
The way his plugin worked, was to create Standard Lightroom Collections (including Collection Sets) and configuring his plublishing service, and just dropping photos into service (unsorted).
By hitting publishing, it mirrored everything from the standard LR collections.
I was wondering if your plugin can be configured like this? I’ve tried, but only came to the concolusion, that I have to recreate all my Collections, right?
I realize that both version have disadvantages :)
* his was limited that you should place your photo only once in a collection
* yours forces me to recreate my collections, and possible “lose” the collection tree, should you plugin ever stop to work, for whatever reason :)

anyway, I still like this plugin and am still considering recreating everything from scratch.

Lightroom makes this really difficult to do the way someone would naturally want. Mine has nothing to do with whatever collections you might have in your Lightroom catalog; I can certainly see the desire to mirror your normal collections, but this would be kludgy to implement at best. )-: —Jeffrey

— comment by Ivan on August 4th, 2015 at 5:24am JST (3 months, 28 days ago) comment permalink

Hi Jeffrey,

I’m coming from Germany – between Hannover and Bielefeld…
I’m working with LR (current version: CC) for a few months and I have created many collection sets with sub-collection sets. Now I was looking for a tool to export my collection sets to my disk.
So I found your 2 tools: “Folder Publisher” and “Collection Publisher”
I tried the Folder Publisher – and it works fine, all folders and subfolders were published.
But with the Collection Publisher I’ve my problems.
I follow your instructions on your homepage and I create a new collection with “Part of its parent” – but the collection only published the fotos and not the structure of my collection set.
Then I tried “It’s own sub-folder” – the folder with the name of the collection was created but in this folder are only the fotos…

Hope you can help me
Thanks a lot in advance

Collection Publisher doesn’t work that way, sorry… it lets you set up your own collections for publish to disk, and doesn’t have anything to do with non-collections in your library. You’re not alone in wanting to do what you suggest, but Lightroom’s plugin infrastructure doesn’t make it easy. —Jeffrey

UPDATE: I’ve given a try to fitting this into the plugin, despite Lightroom’s plugin infrastructure making it really uninviting. See here. —Jeffrey

— comment by Wolfgang on August 6th, 2015 at 3:24pm JST (3 months, 24 days ago) comment permalink

I use a number of your plugins. Have LR CC 2015.0.1. I don’t understand about the folder name. Currently i have 2 files as plug ins:


Neither of these is in a folder and they, and others, are stored within a folder I have named LIGHTROOM PLUGINS.

What change should I make, or how can I get the update and begin using it??


I suggest deleting both and downloading the latest zip from my server, unzipping it (if your browser doesn’t do it automatically), then moving the resulting “collection-publisher-jfriedl.lrplugin” to your LIGHTROOM PLUGINS folder. Then point Lightroom at it via the [Add] button in Lightroom’s Plugin Manager. —Jeffrey

— comment by VINCE on August 9th, 2015 at 12:18pm JST (3 months, 23 days ago) comment permalink

For those looking to mirror their pre-existing collections, I’ve just added the ability to do so… see here. —Jeffrey

— comment by Jeffrey Friedl on August 18th, 2015 at 9:25pm JST (3 months, 12 days ago) comment permalink

The “mirror” feature is great !!!! …. I know we’re always ask more… but …. would it be possible to specify an “exclusion pattern to prevent mirroring ?

I usually create a collection set for eg holidays. then I create a collection names “ALL-xxx” containing all picture took during this holliday.
Then I create collection 01-fvisit thuis, then 02, visit that
I would be very comfortable for me to mirror the whole collection set “holidays” and ignoring all collections having names starting with “ALL”

Does it make sense ?

It makes sense, but I probably won’t add new features for a while, to see how it settles down. For the time being you could perhaps put the “ALL-” collections off the side somewhere, or just individually mirror the 01-fvisit, 02… collections one by one. —Jeffrey

— comment by Etienne Charlier on August 18th, 2015 at 11:47pm JST (3 months, 12 days ago) comment permalink

Hi Jeffrey,

Awesome to suggested features implemented! Totally understand the limitations.
Thanks, again

— comment by Ivan on August 19th, 2015 at 4:42am JST (3 months, 13 days ago) comment permalink

Hi Jeffrey,

last weekend i’ve tested your new mirror-feature and faced a problem. I’ve published my new mirrored collection set with several sub collection sets and collections. It works fine.
I developed some pictures in my source collection and added some new pictures – publishing works. But if I delete a picture – the collection publisher don’t recognized this change. The picture will still be published and will not be deleted.

Thanks a lot

After it gets published in error, run the “Refresh and Publish Mirrored Collections” in “File > Plugin Extras” to see whether it gets deleted. In either case, then send the plugin long with a note reminding me of the problem, being sure to explicitly note the image that should have been deleted. —Jeffrey

— comment by Wolfgang on August 31st, 2015 at 5:51pm JST (2 months, 30 days ago) comment permalink

Hi Jeffrey,

i’ve tried to “Refresh and Publish Mirrored Collections” in “File > Plugin Extras” – everything works fine!!!
Thanks a lot

— comment by Wolfgang on September 9th, 2015 at 3:18pm JST (2 months, 21 days ago) comment permalink

The mirror collection feature is great.

Usability would be much better if instead of having to go to “File > Plugin Extras” to run “Refresh and Publish Mirrored Collections”, users can right click on the “MIRROR: collection name” entry under the Collection Publisher and have a Refresh entry in the pop-up context menu.

Thanks for the great works.

No kidding, but despite having asked for access to the context menu for years, it’s still not available to plugins. )-: —Jeffrey

— comment by Minh on October 2nd, 2015 at 5:16am JST (1 month, 30 days ago) comment permalink


Do you have any suggestions on how to handle file sequencing? I’m scanning old photos in fairly random order with no particular file naming conventions. I then put them in collections and use drag and drop to put them into some sort of chronological or other logical sequence. Before starting to use your publisher, I would export and use LR file renaming to add a sequence number to the exported images so that they can be displayed on a website sorted by filename.

Using Mirrored Collections, the publisher collection looses the sequence worked out for the original collection.

I’ve had some success with re-ordering the images in the publisher collection, but it only seems possible for images which have been published. Dividing the display into images waiting to be (re)published and published makes sorting difficult.

I don’t have a warm feeling that any manual sorting I do will be preserved when selected images are modified and queued for republishing. Am I right to be worried – or do you think that any manual sort order will be retained during republish cycles.

I also see problems when adding new images and changing the sort order after images have been published. I suspect that I should manually delete all images in the target folder before doing a republish to make sure that any LR sequence numbers in the filename match the manual sequences in the complete collection of images to be published.

I’ve also had problem with virtual copies where LR doesn’t seem to put them in the same sequence as the manual sequence I use in a collection.

Does LR give the plugin/template access to a sort sequence number for an image within a manually sorted collection which I could use in the renaming section, rather rely on LR export sequencing.

Appreciate any thought you may have.
David. Harwell, UK

You’re certainly tickling a lot of spots where Lightroom doesn’t shine well, combined with the concept of sequence numbers, which are much more full of pitfall than one might at first imagine. For example, if you publish a bunch of images and then delete one, do you expect all the (perhaps hundreds of thousands of) other images to be renamed to fit? What if you then add a photo somewhere in the middle? It’s a huge can of worms. That being said, I’ve just pushed a new version of the plugin that has some support for sequence numbers…. see the “sequence numbers” link in the “Enhanced File Renaming” section of the dialog, and give it a try. Do be sure to keep fingers crossed and lucky socks on. —Jeffrey

— comment by David on October 11th, 2015 at 3:23am JST (1 month, 21 days ago) comment permalink

Hi Jeff, love the tools. Is it possible to do an auto publish every day or so? Using the lightroom mobile and if pictures are picked then would like to automatically publish to folder for apple TV or other services

You mean leave Lightroom running on an unattended computer, and have Publish run every so often (to reflect changes incorporated via Mobile)? I don’t know of a plugin that does this, but it’s certainly possible. —Jeffrey

— comment by Ian on October 15th, 2015 at 10:46am JST (1 month, 17 days ago) comment permalink

My collection publish works as excpected except it doesn’t publish video files that I shot on my iPhone. I get this error report:

An unknown error occurred. This photo was not rendered. (5)
/Users/thomas/Pictures/Lightroom managed/Tom’s iPhone/IMG_1569.MOV
/Users/thomas/Pictures/Lightroom managed/Tom’s iPhone/IMG_1572.MOV

The plug-in worked in the past but doesn’t anymore. I do have the include video files checkbox selected, I’ve tried both original files and H.264 format, the files requested are on my local drive.

Any ideas what’s not working?

Could you try the same export using Lightroom’s built-in “Hard Drive” export/publish? I suspect it’s a Lightroom issue unrelated to the plugin, and this would shed some light on that. —Jeffrey

— comment by Thomas White on October 30th, 2015 at 2:14pm JST (1 month ago) comment permalink

I tried exporting the same set of videos from LR6 to Hard Drive twice–original format and H.264–it worked fine both times.

I tried deleting the videos fro the troubled publish collection and creating a new publish collection. Again the publish failed.

— comment by Thomas White on October 31st, 2015 at 2:05am JST (1 month, 1 day ago) comment permalink

I tried completely deleting the publish service and creating a new service that seemed to fix the problem. Working fine now.

— comment by Thomas White on October 31st, 2015 at 5:42am JST (1 month, 1 day ago) comment permalink

New question:

Is it possible to reorder the processing steps and inserted plug-ins used by Collection Publisher. It seems like “Crop for iPad” should be before Sharpen in the workflow.

Extras added via other plugins (like Crop for iPad) can be reordered among themselves, but they all fall together in the overall stack. Lightroom renders the copy of the image (with Sharpen, etc.) and then passes it to the extras, then to the main host plugin. You needen’t worry about Crop for iPad reducing quality… the crop is done with a special JPEG-processing tool that makes it completely lossless. —Jeffrey

— comment by Thomas White on November 1st, 2015 at 10:37am JST (1 month ago) comment permalink

Hi Jeffrey,
I’ve been very happy with your Collection Publisher and the way I’ve been syncing my LR collections with my iPad thanks to your blog post

Now I have to relocate the root of my collection tree to a new folder on my hard drive. Can I feel pretty confident relocating the tree that won’t make a mess of all that I’ve already published to my iPad? Do you have any warnings or suggestions about a best way to do it to minimize potential problems?

Thank you,
Julliette from Belmont, Massachusetts

I don’t see much potential for a mess from the Lightroom side… at worse, you just have to republish to refill the local folders intended for your iPad, but I’d expect the plugin to handle the relocation fine. How it reflects on your iPad is dependent upon how you get them there and what app you use, but in general I’d think that no matter what method you use, the moved photos will appear on the iPad as different photos (and the old ones either deleted or left lying around), so any kind of work you’d done there (adding comments, etc., or whatever the app allows) would be lost. In my case I use the iPad only for display, so this wouldn’t bother me because I have no “value-added” data added on the iPad. —Jeffrey

— comment by Julliette on November 15th, 2015 at 8:39am JST (2 weeks, 2 days ago) comment permalink

Julliette here again, adding to the previous comment. The reason I want to move the collection tree is that I followed your suggestion and put it in my Dropbox folder, but now my Dropbox space allotment has reached its limit. Since I’m not syncing the tree with other devices, I don’t see any value to it being in Dropbox so I may as well move it.

BTW I read above that you added the function to mirror collections to jfCollections! That’s great, thanks!

— comment by Julliette on November 15th, 2015 at 9:36am JST (2 weeks, 2 days ago) comment permalink
Leave a comment...

All comments are invisible to others until Jeffrey approves them.

Please mention what part of the world you're writing from, if you don't mind. It's always interesting to see where people are visiting from.

You can use the following tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Subscribe without commenting