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 Classic, 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 > jf Collection Publisher > 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 Lr6 to Lr7 (or the equivalent under the hood for the Lightroom Classic subscription) 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 )


Updates for Lr8 (Lightroom Classic CC Version 8).

Added the special PP() function to the {LUA} token.

Added hierarchical options to the Keywords token.

Try to work around a Lightroom bug related to photo timezones and how Lightroom handles accessing plugin data.


Added the 'nicknames' modifier to the {People} token.

Added the SST1, SST2, and SS3 tokens to the template tokens that the plugin understands.


Try to avoid having unexpectedly-long error messages create too-big a dialog.


Limit the amount of temporary disk used by Lightroom before handing files off to the plugin.


Fixed the {LUA} load() function.

Added the folowing template tokens: {home}, {desktop}, {temp}, {pictures}, {documents}

Added the 'PCH' variable to the {LUA} tag.


Added the IptcDateTaken token.

Clicking on the version number in the Plugin Manager now copies version info to the clipboard

Updated the PublishCollectionName token to allow numeric arguments along the lines of the CollectionName token.


Fixed a bug when 'Token Examples' invoked in certain situations.


Added a bunch of token filters: F2D F2S F2X B2D B2S B2X S2X A2D A2S A2X


Updates to the data templates that my plugins understand: updated the Keywords token, added CollectionNames and CollectionFullNames tokens, and added a bunch of stuff (KWf, CN, CFN, CNf, CFNf) to the {LUA} token.


Oops, more Lr7 stuff.


Updates for Lightroom 7


Handle the renaming of mirrored collections.

Allow the "If Exists" feature of Templat Tokens to work with the PluginProperty token.


Update registration support to handle a stupid bug at PayPal that PayPal refuses to fix )-:


Fixed a bug introuded the other day in template tokens, related to Windows filenames.


Added the "only if it has a value" feature to template tokens.

Updated the {FolderName} token to allow {FolderName=1} (rather than requiring the plus as in {FolderName=+1})


Fixed a bug introduced in the previous build that could cause some collections with dynamic template tokens to fail.


Watch out for collection names with characters that are not allowed in a Windows folder name, and replace them with '-' (a minuse sign), to avoid crashing.

Added the Newline template token.

Enhanced the FolderName token.


Added some debug logging.


Added the following tokens to the template tokens that my plugins understand: Artworks, ArtworkTitle, ArtworkCopyright, ArtworkSource, ArtworkCreator, ArtworkDateCreated, ArtworkInventoryNum


Couldn't set the exported-copy file date older than about 50 years ago; fixed.


The rules about what characters are disallowed in a folder name were too aggressive, so relax them.

Fixed a bug with the keyword tables in the LUA token.

Added Weekday, Wday, weekday, wday, and ISO8601Date to the list of template tokens that my plugins understand.

Switch the log-sending mechanism to https.


Added the following tokens to the templates that my plugins understand: FileModYYYY, FileModYY, FileModMM, FileModDD, FileModHH, FileModMIN, FileModSS, FileYYYY, FileYY, FileMM, FileDD, FileHH, FileMIN, FileSS, {FilenameNumber}.

Better support for network shares on Windows.


Fixed a "TreePublisher_Mirror:91" error.

Fix to get around a Mac display issue with Lr6 on OSX.

Added Russian-langauge support for the People-Support {People} tag.


Fixed the "Spec:2164" error.


Added ChildOf and DescendantOf filters to the {Keywords} and {KeywordsAll} template tokens that my plugins understand.

Fixed how custom {People} formatting works with people keywords that have no birthday associated with them.

Try to avoid yet another place where Lightroom gets hung because it can't handle certain kinds of dialogs at the same time.


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 112; see all), most recent last...

It would be nice, if I could export the xmp file too. I export my photos with Collection Publisher to .jpg for my Homepage. Now I want the xmp file too, so that I can read the metadata with a 3rd party tool.
Thank you

The data that would be in an XMP file is already included within the exported JPG. A separate sidecar file is required only when the original can’t hold the data, or you don’t want to modify an original. A tool that could read an XMP file should, one would hope, be able to find the same data within the JPG, because it’s there unless you go out of your way to strip it during or after export. —Jeffrey

— comment by Marco on February 26th, 2016 at 3:48am JST (2 years, 9 months ago) comment permalink


i have the same wish as Aaron
i would like to export only images with a rating or a minimal rating of x

Thanks you!

For this your best bet is to us a Smart Collection, using one of the rules to name the source collection you want to mirror. For me to add it to my mirroring stuff would require me re-inventing the wheel, so to speak, about smart-collection dialogs, rules, and actions. That’s a bit much. —Jeffrey

— comment by Daniel on April 13th, 2016 at 5:36pm JST (2 years, 7 months ago) comment permalink

Hi Jeffrey, does the collection or folder Publisher also support publishing to an NAS or to local disk only (as does LR). My setup: Win10, LR6/CC. Best, Guido

Well, by definition of “NAS”, yes, it’ll publish to it once you do the “A” part and mount it so that it appears as a local disk. —Jeffrey

— comment by Guido on August 22nd, 2016 at 7:07am JST (2 years, 3 months ago) comment permalink

Hello Jeffrey,
I can succeed to export a collection using the button “Export”.
But in can’t find the button “Import” when i try to create a new service of publication vie Collection publisher – I can only see “export” event the service is not yet registered.

Could you please check if the fonction has not deasapear in the new version of your plugin ?


One doesn’t “Import” into a publish collection… just drag photos from the Library Grid into the collection. —Jeffrey

— comment by Richard on September 18th, 2016 at 4:58pm JST (2 years, 2 months ago) comment permalink

Hello Jeffrey,

Thanks for awesome Lightroom plugins! However, I have some problems with Collection Publisher plugin. I installed Lightroom to a new computer and opened the old catalog in which I had some old collections made with the plugin. Even though I have only “Title” and “Rating” triggering to republish, Lightroom is marking every old published photos to republish. This is very annoying because now I can’t publish any new photos because I have to wait that Lightroom has processed republishing. Is there anything that I could do to stop Lightroom marking the old pictures to republished?

Best regards

Adobe designed Lightroom to handle this situation, but the implementation is full of bugs that seem to bite at random times. The best I can suggest is to select photos you don’t want to republish (that are in the queue to republish), and from the right-click menu invoke “Mark as Up-to-Date”. —Jeffrey

— comment by Lasse on October 5th, 2016 at 6:37pm JST (2 years, 1 month ago) comment permalink

Hi Jeffrey, as a long term user of your fabulous collection publisher plugin I have just a simple
question: I was doing some picture renaming in my catalog and was hoping collection publisher
gets notice of this activity and automatically selects all photos for re-publish. Unfortunately
this did not happen and I needed to manually select the photos with the changed names for
publishing again. I had selected all options which lead to a re-publish in the collection
publisher settings under the section “Metadata that Triggers Republish”.
Would this be possible to introduce such a behaviour in the plugin ?
I personally think this would make much sense.
Thanks a lot for your awesome plugins and best regards,Heiko

Sadly, Lightroom doesn’t include filename or folder location among metadata that causes a republish. —Jeffrey

— comment by Heiko on October 11th, 2016 at 6:19am JST (2 years, 1 month ago) comment permalink

Is it possible to only publish images that are ‘picked’. I realize that I can create a smart collection that matches ‘picked’ but I would rather just publish all picked images without having this extra step, and also double the amount of collections I have.

If you select some photos in a Publish Collection and hold down the alt/option key, the [Publish] button becomes [Publish Selected]. Preparing the selection via the Library Grid Filter to show only Picks, then selecting them all, you can do it this way. —Jeffrey

— comment by Min on December 4th, 2016 at 8:21am JST (1 year, 11 months ago) comment permalink


Your plugins are impressive!! I’m wondering if one of them offers a feature I need…

I have thousands of photos across a set of Lightroom collections. In order to track changes and ensure that none are missing/accidentally deleted from the collections, I would like to export a list (ideally CSV or text file) from lightroom that shows which photos (folder/name) are in each collection. Alternatively if the collection names could be copied into the metadata, I could extract the info with exiftool.

Any suggestions/advice would be much appreciated!


Unfortunately, nothing comes to mind. The first idea (dumping data to a text file) would be possible with a custom plugin; I don’t think Lr/Transporter can work with collection data, but you might ask the author. The latter idea (writing collection names) would be more difficult because Lightroom doesn’t let you list all collections a photos is in… you have to walk every smart collection and accumulate data for all the photos. —Jeffrey

— comment by Craig on December 25th, 2016 at 8:43am JST (1 year, 11 months ago) comment permalink

Hello, I love your work and now I own collection publisher! It saves me so much time and I completely do not understand why Adobe hasn’t done this or folder publisher.


I’m writing about nested collection sets. You cannot mirror these, as it makes a path with an > with isn’t an allowed character.

Trip (collection set)
|Day 1     (collection)
|Day 2     (collection)
|Approval needed     (collection set – Nested)
||Day 1a     (collection)
||Day 2a     (collection)

If I want to export Day 1a and 2a because they need approvals, I’ll export collection set Approval needed. However mirroring this collection set will automatically, an unable to edit, create a name of MIRROR: Trip > Approval needed.

I can work around this by temporarily moving the collection set to the stop but if this were changed I’d very much appreciate it.


The plugin was a bit too conservative, I guess. I’ve pushed out a new version that should work for you. —Jeffrey

— comment by Stuart on February 14th, 2017 at 5:50am JST (1 year, 9 months ago) comment permalink

Thank you! I updated and tested it. Thank you again for the quick response and all your hard work.

— comment by Stuart on February 23rd, 2017 at 11:57pm JST (1 year, 9 months ago) comment permalink

Dear Jeffrey,

Would be possible to have an option on the CP plugin that deletes all the files when a single collection is enterally re-published?

This would help a lot when you make changes or edit images on one o several Collections because the user can choose if the final Collection keeps the files that have been updated and not the old ones or, eventually, all of them.

Something like: “Delete old versions” or “Keep files updated to the last versions and delete (or not) the old versions”

In my case this will be extremely handy

Thanks very much on any case

Best regards

I’m not quite sure I understand… it sounds as if you’re asking for exactly what the plugin does. After any publish operation, there should be exactly one target photo for each photo in the publish collection, and that one photo is the most-recent rendition from Lightroom. —Jeffrey

— comment by Luis on May 15th, 2017 at 9:07pm JST (1 year, 6 months ago) comment permalink

Is it possible for a mirrored collection to take the same order as the source collection? I have a collection set up with a custom order, and I want to replicate this order on disk. At the moment the order is completely separate, so I have to repeat the custom ordering and clearly have no automatic way to keep them in sync.

Unfortunately, no, Lightroom doesn’t provide hooks to let plugins adjust the order. —Jeffrey

— comment by Mike Prince on September 4th, 2017 at 4:20am JST (1 year, 2 months ago) comment permalink

Firstly, thanks for making this plugin!

Secondly, I would like to report a possible bug when renaming a Collection. The MIRROR collection set does not reflect a renamed Collection.

I created a new Collection, forgot to rename it, so it was just called “Collection”. Then I did a ‘Refresh and Publish Mirrored Collections’, and THEN I renamed “Collection” to “Sequoia”. However, the exported directory is still called “Collection” and I can see that the ‘MIRROR:2016’ collection set under jf Collection Publisher still shows this Collection as “Collection”. Am I missing something?

No, the plugin was. I’ve just updated it. 🙂 —Jeffrey

— comment by Neal on October 5th, 2017 at 2:10am JST (1 year, 1 month ago) comment permalink

Currently in Portugal, but full time traveller and might be anywhere tomorrow!
Trying to get a file name in Collection Publisher unique to the collection name. My problem is when using mirrored collections I get the MIRROR: collection name when I only want the collection name. Tried several versions with After= with no luck. Wondering if the : after MIRROR is causing my problems?
Any suggestions to stripping out that MIRROR: ?

The colon used after “MIRROR” is not the normal colon character you can type with the keyboard, it’s a double-wide Unicode character, so the one you were typing didn’t match. If you copy-paste from here, you’ll get the proper character and it should work: “{PublishCollectionName:After=MIRROR:}” —Jeffry

— comment by Dennis Clark on October 20th, 2017 at 2:20am JST (1 year ago) comment permalink

Solved! Thanks for the help and for the terrific plugins. I use several on a daily basis and can’t imagine my LR workflow without them.

— comment by Dennis Clark on October 20th, 2017 at 3:06pm JST (1 year ago) comment permalink

Collection Publisher now has a significant delay from the time I right-click to “Create Collection or Mirrored Collection” or “Edit Collection or Mirrored Collection” and release the mouse to when the dialog box appears. The delay is typically about 15-20 seconds.

This started a while back (months) so I can’t pinpoint the version at which this began. Prior to that the delay, if any, was quite short.

(I upgraded to the latest version of the plugin yesterday, and this happens on LR CC 2015 and LR CC Classic)

I tested it and found the same long delay, so I started to look at the logs and that seems to have magically fixed it for me… further tests were all quick. It could be related to a Lightroom restart… perhaps something internally got bogged down? I’m at a loss to explain, but I imagine it’s something out of the plugin’s control. I’ll keep an eye on it. —Jeffrey

— comment by Robert Camner on October 24th, 2017 at 4:55am JST (1 year ago) comment permalink

Collection Publisher’s behavior changed slightly with the new update to Lightroom Classic CC. Previously, a Smart Collection rule that used “Folder doesn’t contain ___” would test just the name of the image’s immediate parent folder. Now, it seems to test the whole path and therefore can exclude more images than before. If the new behavior is permanent I’ll need to rebuild a number of rules. As an alternative, may I suggest just adding a choice to the main menu (where Folder occurs) called “Path”? That way the rule could be built either way very easily. The rule could say “Path doesn’t contain ___” or “Folder doesn’t contain ___” and get different outcomes depending on where the word occurs. I’m using version 20171019.86 (which seemed to be required in order for the Plugin to function under the new LR Classic). Thanks!

Unfortunately, a plugin has no influence here… this is all standard Lightroom. If the meaning of a rule has changed, it’s a serious bug, so please report it to Adobe. —Jeffrey

— comment by Doug Pearson on November 16th, 2017 at 6:59am JST (1 year ago) comment permalink

I’m hoping you can advise me on the best way to set this up: I currently use Smugmug’s plugin to upload/sync photos to Smugmug and I would also like to have the same photos (including folder structure) synced or mirrored to Dropbox. What would be the best way to do this? Thanks for all of these plugins!

Unfortunately, I don’t see an easy way to automatically mimic their remote hierarchy locally. )-: —Jeffrey

— comment by Kali on November 29th, 2017 at 6:25am JST (11 months, 17 days ago) comment permalink

Collection Publisher is just what I needed. I have a quick question, however. I arrange the photos in a certain order within the separate collection folders in LR. When I publish the photos to my hard drive, however, they loose their order (even when I add a number sequence to the file name on export). Is there a setting to preserve my photo order?

The answer is “no”, for two reasons. One is that unlike in Lightroom, there’s no intrinsic order to the files on disk… it’s up to each application that displays the list of files to present that list in whatever order it deems fit (e.g. sort by name, by date, by recentness, etc). The second reasons is that even if the plugin could craft the file data such that things displayed in the order you want in the application you have in mind, it couldn’t necessarily preserve that ordering as files are added or subtracted from the collection. To preserve some kind of sort, the plugin would have to update every file every time, which is perhaps a reasonable request, but not something the plugin does now. —Jeffrey

— comment by Nolan Conway on December 17th, 2017 at 1:05pm JST (10 months, 30 days ago) comment permalink

Folder Publisher works great for me, but no matter what I try, the Collections Publisher just keeps dumping all exported photos into a single folder on my disk. I can’t get it to replicate my collections hierarchy that I’ve set up in Lightroom. I must be dumb or missing something… why would Folder tool work fine but not Collections tool?

Collection Publisher doesn’t mirror your Collections in the same way that Folder Publisher mirrors your folders. What it does do is documented on the same page that you downloaded it from. —Jeffrey

— comment by Josh on December 26th, 2017 at 9:26am JST (10 months, 21 days ago) comment permalink

Is it possible to add an additional variant of the {Lens} token: the one without “/” (as Lightroom itself does in its filename templates), since the existing one creates unnecessary subfolders (i. e. 24-70 F/2.8 becomes two folders: “24-70 F” and “2.8”)? Many thanks in advance.

I just pushed an update to the Collection Publisher plugin that adds filters such as “F2S” (turns forward slashes into spaces) and “F2X” (turns forward slashes into nothing), so try {Lens:F2X} or the like. I’ve not yet updated the documentation, though. —Jeffrey

— comment by Aleksej on March 5th, 2018 at 1:10am JST (8 months, 11 days ago) comment permalink

First off… brilliant plugin!

here’s the major question… is there ANY way to preserve the custom order while creating the mirror the FIRST time?

The custom order is such an important part of the process for delivering large galleries, that frankly, I don’t even care about the “mirror” part, so much as I want to just be able to export the hierarchy, just once, with my custom order preserved into folder structures on disk.

It would also be really helpful to turn off the automatic adding of “mirror” to the file name on disk for us advanced users. 😉

thanks again for a brilliant step in the first right direction, hopefull theyre’s a way to make this work for the many of us who need custom order more than we need a “mirror”


When the mirrored collection is created, it should be populated with photos in the exact same order as the source collection is at that time. Lightroom doesn’t give a plugin this kind of control, but it seems to happen that way. I just did a test and it worked that way…. —Jeffrey

— comment by Josh Reiss on April 25th, 2018 at 3:42pm JST (6 months, 20 days ago) comment permalink

From Regina, Canada

I have set up Collection Publisher and it appears to be working properly. However, I have an extra folder iPod Photo Cache which is populated with a large number of sub-folders; F00, F01, F02, etc.

Can you explain?


That has nothing to do with Lightroom or the plugin…. it’s, as the name implies, related to Apple. —Jeffrey

— comment by Brian on May 2nd, 2018 at 2:07am JST (6 months, 14 days ago) comment permalink

Collection Publisher:
I have a Smart Collection with “Keywords” “contains words” “2018 Jun 18” and images with “2018 Jun 18” as keywords. Collection publisher will not find them. If I change the Smart Collection to “2018 Jun 19” and the image keywords to “2018 Jun 19”, all works well. Seems like Collection Publisher has a problem with both 2018 and 18 being used at the same time.

A quick and dirty work-a-round is to add a “+” to the Smart Collection keyword search parameter (“2018 Jun 18+”) and leave the image keywords as “2018 Jun 18” .

Am I missing something?

Thanks, George

If you’re referring to the rule used to populate the collection, that’s all done by Lightroom before the plugin has any access to it (and the plugin has no influence on it). So whatever it is is either a bug in Lightroom or in your understanding. I’m tempted to say it’s a bug in Lightroom, but given that I’ve never been able to understand Adobe’s idea of keyword-search, it’s probably a misunderstanding of what they intend “contains words” to mean. We look at “contains words” and intuit it to mean “contains words”, but they could well have some wild meaning in mind that has nothing to do with “contains” nor “word”. /-: —Jeffrey

— comment by George Kindt on June 11th, 2018 at 4:22am JST (5 months, 5 days ago) comment permalink

Thanks, Jeffrey, That was what I thought, but was not sure if you did anything with the search function. Guess I get to blame it on LR. Gleaned from the LR Queen, the “contains words” search is an “AND filter” for “whole matching words”. Second guessing this filter, the “2018” gets a match (OK) with 2018, then the next word “Jun” gets a match (OK) with Jun, and the last word “18” sees the 2018 and gets a failure to match, since it is not a “whole matching word”, never looks farther. I would have thought it would have found the last “18” OK, but seems not to get that far.

Adding the “+” to the end of the 18 means “ending in”, so the “2018” ends in 18 and gets a match (OK). Since all the other search words matched OK, it works. It would depend on the logic they use to parse the string. I suspect that adding the “+” will allow it to fail a different way with different strings.

Thanks, George

It turns out that it’s truly a bug…. it used to work the way we intuitively think, but that changed somewhere along the line between Lr6 and Lr7. I’ve reported it to Adobe, so let’s keep our fingers crossed…. —Jeffrey

— comment by George on June 12th, 2018 at 10:59pm JST (5 months, 3 days ago) comment permalink

I am using the plugin extensively. I found that the option to ‘explicitly set date/time of newly exported pictures to photo’s capture time’ is not working reliably and it is setting most pictures’s modification date etc to the date of the export. I had to resort to alternative tools, i.e

– Include the photos capture date/time in the filename of the exported file
– then use a tool like advanced-renamer on windows to write the correct time stamps on the files based on the file name content.

I am happy to provide more info to get this resolved! Best, Maik

Could you please send a plugin log immediately after an export that you notice didn’t work properly? Thanks. —Jeffrey

— comment by Maik on July 8th, 2018 at 7:13am JST (4 months, 8 days ago) comment permalink

Hi Jeffrey, I’m from Singapore and I’ve been using your plugins since like LR3 or something.

Well, in the latest CC Classic, I found out that when I tried to publish, it would always get stuck (“hang”) at “Updating Published Collection” or such.. I had sent you logs as well.

But I have been playing around, and I realised that this is because I had disabled the “AdobeStock” plugin. Once I reenabled it, everything worked fine again. This is true even for the default Hard Drive publisher as well. So now I have AdobeStock enabled, but hidden. Clearly, this is a problem in Lightroom, why must AdobeStock be enabled/required to export pictures to a local folder (or any other destination in fact)?

Anyway, I just wanted to comment here for anyone else who might have hit this issue, and incorrectly attributed this problem to your plugin (as I did, thousand apologies!)

Thanks much and appreciate your wonderful work!

— comment by Patrick on August 4th, 2018 at 9:55am JST (3 months, 12 days ago) comment permalink

Hi, I have been using this great plug-in (ond others) for some time, though once per several months. I have noticed that the current version have problems with LUA when using Enhanced File Renaming.

It worked perfectly, I did not change my LUA code, but it now fails every time. Currently it is enough to put any LUA expression there, like
and during publishing the following error is shown:
An internal error has occurred: Spec:867: bad argument #1 to ‘?’ (number expected, got nil)

This doesn’t seem to be an issue on my end, but if I do something wrong, please let me know.

Could you make sure that you have the most recent version of the plugin, and then if you encounter the error again, please send the plugin log. Thanks. —Jeffrey

— comment by Vit Kovalcik on October 28th, 2018 at 2:53am JST (2 weeks, 5 days ago) comment permalink

Hi Jeffrey

Is there a way to publish multiple ‘top-level’ folders at once ?

e.g if I create a collection publisher and populate it with a structure like the following, I only seem to be able to publish ‘top_folder_1’ or ‘top_folder_2’ by selecting them individually.

If I select them all and click the ‘publish’ button it only does one folder, and there’s no ‘publish’ option from the publisher itself to let me output everything in one go


(in reality I have about 20 top-level folders)

I don’t want to create a parent folder above these because that will be created on disk as well, and I’m publishing to the root of a hard drive (my Synology’s photo station root) so can’t point the publisher at the drive’s parent folder because there isn’t one

I’d think that Lightroom would publish all the collections that are selected when you hit the [Publish] button. It does for me…. —Jeffrey

— comment by Nick on October 30th, 2018 at 3:28pm JST (2 weeks, 2 days ago) comment permalink

Hi Jeffrey. First, thank you so much for your work : it makes LR much more valuable !! I have a minor issue with the Collection Publisher.

Situation :
– One sub folder
– Inside the sub folders, several smart collections of the “Part of its parent” type : the smart collection use “AND”, so the folder gathers Smart Collections with a kind of “OR” and I get a disjuntion of conjunctions, which is extremely valuable
– Let’s assume a picture which appears in several Smart Collections

Clicking on the sub-folder lets the common picture appear only once, but when publishing, the common pictures appears multiple times, with “-2” ou “-3” suffixes.

Is it a bug or feature ? If it is a feature then what would be your recommendaton in my case ? I’d like to publish every picture only once per subfolder, subfolders agregating different criterions.

Thanks for your help,

I hadn’t thought of that situation, but now that you mention it, I see what you mean. Unfortunately, at this point it would be difficult and risky to try to update that code to handle that… the name-generation code is already a really dicey area. Sorry. )-: —Jeffrey

— comment by Pierre Gérard on November 2nd, 2018 at 11:35pm JST (1 week, 6 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 basic HTML; be sure to close tags properly.

Subscribe without commenting