Jeffrey’s “Folder Publisher” Lightroom Plugin

This Lightroom “Publish” plugin allows you to export copies of your Lightroom photos to disk in a folder hierarchy that mimics the folder hierarchy in your Lightroom catalog. I've found it very useful in mirroring my Lightroom catalog as small JPGs on my wife's computer.

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 Collection Publisher plugin (which is similar to this plugin, except that plugin mirrors a collection hierarchy instead of a folder 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”.

The plugin is normally used in the following pattern:

  1. Initial setup of the publish service.
  2. Populate the default collection with image you want to mirror, or create a smart collection that identifies the images you want to mirrors.
  3. “Publish” them, causing copies of the images to be reflected into a hierarchy on disk matching the folder hierarchy in Lightroom.
  4. 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, you can drag images into the default collection, or you can create your own collections, including “smart collections” that identify images to include via rules (e.g. “all five-star images”).

The default publish location for any image in any collection is that its folder structure in Lightroom is replicated and placed starting at the root folder chosen when you set up the publish service. However, you can modify aspects of how image locations are mapped when you create/edit a collection:


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 )


Reworked the Keywords token to better accept filters.


Fixed the plugin crashing in the face of a failed video render.


Try to work around filename issues on Windows when trying update the filesystem time.

working around 'constant table overflow' error

Added the ImageViewDirection and ImageViewBearing tokens.


Added the PF filter to turn typographic fractions into plain-ASCII fractions.


Updates for Lr10

Be more aggressive in trying to figure out the capture time of photos when trying to set the export file time to the capture time.

Added the SpeedKnots token.

Worked around an "unknown key captureTime" error.

Added the {PlusCode} and {GeoHash} tokens.

Handle FTP errors better.


Added some extra debug logging.


Oops, one wasn't offered the ability to change the root of the publish tree if the original folder no longer existed.


Fixed a reporting error with the new find-misshing-published-photos feature.


Added the ability to find missing published photos and have them marked for republish.

Some of the filename-related tokens could be incorrect in rare situations.


Fixed a bug WRT database access while moving the destination root.

Work around a Windows bug related to canceling out of the registration dialog.

Added some extra debug logging to note whether the plugin is enabled.


Upgraded to the embedded copy of ExifTool to version 11.70.

Added special {AbsSequenceFirst=####"} and {AbsSequenceAppend=####} tokens.

Added the LensInfo template token.

Updated the Exposure token to allow customization.

More token work: added {Urls}, and updated {ISO} and {Copyright} to allow customization.

Added the {RelativeFolder} token.


Work around a bug in Lightroom related to filename conflicts (where two exported files have names that differ only in lettercase).

Fixed the SST1 and SST2 tokens.


Fixed a bug in the name-change scan.


Updated the PublishCollectionName token (and CollectionNames and CollectionFullNames) to remove the MIRROR: prefix from the name that mirrored collections within my Collection Publisher plugin automatically get.


Newline token.

Fixed a problem related to template tokens and photos without capture times.

Upgraded to the embedded copy of ExifTool to version 11.50.

Added functions uc(), ucFirst(), lc(), and lcFirst() to the LUA token.


Added the ability to notice when files have their filename or folder changed.

Fixed an issue with {SequenceFirst}.

Work around a bug that sometimes causes plugins to be disabled when starting Lightroom via clicking on a catalog file.

Fix an "Unknown key: captureTime" crash.

Added the GPSCoords token.


Updated the keyword-related tokens to accept standard filters.


Upgraded to the embedded copy of ExifTool to version 11.30.


Added the {Exiftool=...} template token.


Added some extra debug loging.

If the plugin's attempt to create a folder fails, try again a few times before actually reporting the failure.

Added the PEOPLE variable to the LUA token.

Fixed a problem with the SpeedKPH token.

Added the TempC and TempF tokens.


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.


Added some extra debug logging.

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.

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

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


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 Lr7.

Better handle some character-encoding issues related to template tokens.

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 extra debug-logging to track down a timing issue.


Added the Newline template token.

Enhanced the FolderName token

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


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.


Better support for network shares on Windows.


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


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

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

Added more debug logging to track down some issues.


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.


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.


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.


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

20141215.67 Added a bit more debug-logging for when a file copy can't be done.
20141019.66 Windows Only: Add a one-time check for the POODLE security vulnerability, and alert the user if it exists.
20141005.65 Clicking on the blank area next to the upper-right [Publish] button caused an error dialog to display.
20140923.64 Added the LrMD5, LrLocalization, LrSystemInfo, and LrMath packages to the {LUA} template token.
20140922.63 Workaround for a Lightroom bug that causes the plugin to croak on certain folder names.
20140920.62 Some extra debug logging to track down a problem.
20140902.61 New build system

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

20140731.59 Registration fix for Lr5.6
20140720.58 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.55 Sigh, had a bug in the Creative-Cloud support.

Now supports Lr5.5+ Creative-Cloud Installs.

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

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

20140612.50 Under some error conditions plugin would crash instead of presenting the proper error message.

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.48 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.

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

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


Added an option to limit the overall depth of the publish tree.


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.43 Added {PublishCollectionName}, {PublishCollectionDepth}, and {PublishServiceTitle} tokens to the preset templates. See template-token web page for important restrictions.
20131102.42 Update for OS X Mavricks
20131010.41 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.40 Oops, fix a bug introduced in the previous update

The 'Template Examples' dialog had been broken. Deprecated 'Folder' and 'Path' tokens in preference to 'FolderName' and 'FolderPath' tokens.


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

Additional debug logging.


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.

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

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

20130708.35 Fixed a crash during certain file-renaming attempts where originals no longer existed.

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.33 Allow published copies to remain on disk even if a photo is deleted from Lightroom.
20130613.32 Better support for plugin revalidation.
20130612.31 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.29 Yet another Lr5 update
20130610.28 Final update for Lr5
20130513.27 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.26 Update for Lr5
20130412.25 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.22 More build-system maintenance
20130206.21 Tweak for my registration system
20121210.19 Added some extra debug logging.
20121024.18 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.16 Oops, the 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.

20120810.13 Added some debug logging to try to track down an error
20120722.12 More debugging for the "choose a root folder" bug that seems to still affect a few folks.
20120531.11 Oops, I was moving the original XMP file (when the Publish format was "Original" instead of copying it. Fixed.

Finally tracked down why the plugin had problem with Windows network shares. Ended up filing three separate bug reports with Adobe, but in the end was able to work around the bugs, so hopefully it's working now.

Update to handle the Mac App Store version of Lightroom.


Tweak for Lr4.1RC2.

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}

20120330.8 Update to handle 4.1RC
20120315.7 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.

20120224.4 A few bug and Lr4 fixes, and some extra debug logging.
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 226; see all), most recent last...

Hi Jeffrey,
Love the idea of this plugin thanks!

Quick question –
Think I’m doing something wrong… I have created a smart collection and would like it to reflect the file path hierarchy of all folders within it-

/top-folder – folder has photos
/top-folder/middle-folder – folder has photos
/top-folder/middle-folder/bottom-folder – folder has photos

However it publishes all folders with any photos inside it into my chosen destination but does not hold the hierarchy, just puts all the folders go into the 1 folder destination.
It does not put folders in a folder if that makes sense?

Please help 🙂

Thank you for your time 🙂

When setting up each collection within the publish service, you can set various parameters as to how photos published through it should end up on your disk, including having it remove leading sections of the path. It looks like that’s what you’ve done. Right click on the collection name, “Edit Collection”, and make sure the settings are as you want. —Jeffrey

— comment by Dave on January 22nd, 2020 at 2:33am JST (1 year, 3 months ago) comment permalink

Hi, I am from Belgium and very grateful for your excellent plug-in !
I have seen several questions about maintaining the folder hierarchy of the export and also the suggestion to correct the setting for removing leading and trailing sections of the path. I still think something is not working here, either because of Lightroom, either because of the plug-in.
I have the impression that things don’t work properly whenever the path has more than 2 levels (not including the root)
In my example the root is “/Volumes/photo/shoot/”
I filter on source map equal to “6-SNT”
One of the actual images is located in “6-SNT/4-product/DCS2100.NEF”
I expect the folder to be published in “/Volumes/photo/shoots/6-SNT/4-products” but instead it is published in “/Volumes/photo/shoots/4-products”. So, I loose one of the intermediate levels.
Any idea ? I am doing something wrongly ?
Thanks !

If the “6-SNT” folder appears in the Library folder list as a child of the “/Volumes/photo/shoot” root, then the result should be as you expect, unless you’ve told the plugin to remove one leading level from the photo path. So there might be a bug somewhere…. please send a plugin log after a small publish operation that exhibits the problem, being sure to be clear in the comment about what exactly did happen, and how that differs from what exactly you expected… —Jeffrey

— comment by Dirk Colaert on February 12th, 2020 at 7:23pm JST (1 year, 2 months ago) comment permalink

Hi Jeffrey,

Thank you for your essentiel plugin. Essentiel at least for me. 😉 The only problem i have: Is it possible to let the plugin overwrite files? Have lots of pictures, that i haven’t edited yet, but exported them already, to have access to them on a certain platform. Edited or not. Now I want to edit set by set and export this via folder publisher to the platform. Unfortunately I run into the same thing as Rob den Braasem (see comment above). “Newly” exported pictures get always a number behind.

My filename template looks like: {FileYYYY}{FileMM}{FileDD}_{LIBRARYFILENAME}

How can I make folder publisher to overwrite existing files, without appending a “collision”-number? Thank you in advance!

If the only files in the target hierarchy were put there by the plugin (by this publish service of this plugin in this catalog), then republishing changes should update the files in place. Otherwise, no, pre-existing files won’t be clobbered by the plugin. This is a safety feature. —Jeffrey

— comment by Georg on March 31st, 2020 at 8:48pm JST (1 year ago) comment permalink

Ah, now I see! I have this sets (translated, sorry):

* All pictures
* All videos
* New or changed today
* New or changed within the last 30 days
* Created within the last three months
* Manual

So, all of the pictures (and videos) will be exported via your plugin. So, if i export all the pictures with set ‘All pictures’, i get the “collision”-numbers in filenames, when exporting afterwards via set ‘New or changed within the last 30 days’, because there is (obviously) a intersection? Correct? Then, in my case, it would be better to use just one set for all pictures? The other sets are not necessary?

Sorry for that question, i could just try it out. But it took me two days to export all pictures…

Would be glad, if you could point this out. Thank you again in advance!

The various sets you have… are they sent to different target locations (via different Publish Services)? If not, I don’t see the point of having them, since “all pictures” and “all videos” encompass everything. It looks like you simply want one smart collection “all stuff” that includes everything in your catalog. —Jeffrey

— comment by Georg on April 3rd, 2020 at 1:10am JST (1 year ago) comment permalink

Hi Jeffrey,

First off, thank you for an excellent plugin. I have been using it with great success for a long time.

I have a question: Somehow I screwed up and had to re-install the plugin and re-make the smart collection sets for about 120,000 pictures which have already been published. So now when I re-write a smart collection the plugin wants to publish them again as new photos. Any way I can mark those photos as already published? Thanks in advance for your comments.

No, sorry, once you deleted the original sets, the connection is lost. If you can revert to a backup of the catalog from before the deletion, that would solve that problem. Deleting/reinstalling the plugin has no impact on your catalog data, so that wouldn’t have required remaking your sets, so I’m a bit confused as to what might have happened… —Jeffrey

— comment by Robert Schroeder on April 13th, 2020 at 1:30pm JST (11 months, 27 days ago) comment permalink

I just upgraded Lightroom to the build 202004070813-7699d98a.

For the Folder Publisher plugin

I’m getting a message saying a new version is available, but when I click to upgrade, it says that the plugin does not seem to be installed in a location where Lightroom can write to it

I’ve manually upgraded it and the version number under Status is exactly that shown under NEW VERSION AVAILABLE, that is 20200414.106

I still get the message about a new version being available, after closing LR Classic, doing the manual install, and restarting it

That’s weird. If you do a “check for new version now” (in the upper-right of the Plugin Manager), does it perhaps get rid of that message? —Jeffrey

— comment by Steve Leggettq on April 15th, 2020 at 1:47am JST (11 months, 26 days ago) comment permalink

The message about a new version being available persisted until I rebooted the Mac, even though I had manually installed it and the number under status was correct, matching that under the ‘available’ message. All seems fine again now.

— comment by Steve Leggett on April 18th, 2020 at 2:20pm JST (11 months, 22 days ago) comment permalink

Hi Jeffery,
I have just updated to LR Classic and your new folder publisher plugin v106, and I’m re-publishing my pictures, but I note that as I’ve created a new smart collection it states they all need to be re-published. But setting LR off publishing all my jpgs, once it has finished it then reports that there are many modified pictures that need to be published, even though it has just published them all. So I set it publishing these modified pictures and after a couple of cycles of this then it decides they have all been published correctly, is there a bug here?

Yes, there’s a bug… Lightroom has been flakey in this respect since Publish was introduced. I’ve seen no rhyme nor reason as to when it gets this way. It’s often fine, but sometimes wants to republish a lot. )-: If you know that they’ve all just published, you can select them an “Mark as Up-to-Date” to avoid the incessant republishes. —Jeffrey

— comment by Paul Johnson on April 21st, 2020 at 11:57pm JST (11 months, 19 days ago) comment permalink

Hi Jeffery,
Thank you for the answer to my constant re-publishing issue, but I cannot find the “Mark as Up-to-Date” option in LR classic, so can you tell where I can find it, or is this only an LR CC option?

Select the thumbnails in the “Modified Photos to Republish” section, then right click. —Jeffrey

— comment by Paul Johnson on April 22nd, 2020 at 10:46pm JST (11 months, 18 days ago) comment permalink

Hi Jeffery,
Please ignore my previous message, I found that mark as up-to-date is only available on photos under the modified banner, which is sensible, so all sorted.
Your folder publisher is a great, and it is an essential part of my workflow, so thank you for making it available and maintaining it.

— comment by Paul Johnson on April 22nd, 2020 at 10:55pm JST (11 months, 18 days ago) comment permalink

Hi Jeffrey,

Thank you so much for developing the Folder Publisher Plugin. It is perfect for my workflow and generally working very well.

I have just been running into one small issue. While the majority of what I publish is photos, I have a few video files that are amongst them. When I run the publisher, as soon as it gets to a video file, it publishes it correctly but then seems to freeze and be unable to publish the remaining photos or videos. In fact, I can cancel the publish operation and even when I click publish again it does nothing. When I restart lightroom it works perfectly until it reaches another video file when the same issue repeats. The video files are just short (usually less than 10 seconds) .mp4 files.

Have you ever run across this issue before or is there something which you think I may be doing wrong.

Thanks again for all your hard work,

Ps. writing from the UK

Are you sure that there’s not a larger video in there? Lightroom can seem to be locked up for hours on end when it’s trying to export a large video. —Jeffrey

— comment by Chris on April 25th, 2020 at 2:01am JST (11 months, 16 days ago) comment permalink

When I change the name of a FOLDER, the mirrored folder hierarchy does not update, nor does the new (i.e. renamed) folder propagate to the mirrored set. Is this the expected behavior? If so, is there a suggested work-around?

Thank you for your excellent plug-ins.


It’s expected, but, of course, not great. It’s all very kludgy under the hood, as Lightroom doesn’t provide many hooks here. If you make a folder name change, you’ve got to deal with changes to mirrored items manually. —Jeffrey

— comment by Art Held on April 26th, 2020 at 11:44am JST (11 months, 14 days ago) comment permalink

Hi Jeffrey,
Thank you so much for this very useful plugin!
Is it somehow possible to publish only one single image or a selection instead of publishing the whole collection?
In my case I’ve created a jf folder publisher collection for every year to separate them and keep it rudimentary overseeable, to have a mirror of my library as jpgs on my harddrive. So if I there are a lot of images waiting for the publish, I don’t see any way to get a certain folder exported / published prior to the rest.
Do you have any tip for me?

Select the thumbnails to publish and hold down the alt/option key to change the [Publish] button into [Publish Selected], and click… —Jeffrey

— comment by Steffen on April 26th, 2020 at 7:14pm JST (11 months, 14 days ago) comment permalink

Hi Jeffrey,

I am a long term fan of you plugins!
I just encountered an issue with file naming if I publish a smart collection including photos with virtual copies. Sometimes the master photo will not be published with the correct name or even worth a “-x” gets added where x is e.g. a number increased from the last published version of the file.
I also use MetaDataWrangler for the publishing service.
If you need anything to dig further in the details just let me know. Any help is appreciated.



Lightroom adds the “-#” suffix if any of the filenames in a current publish would conflict (which is what would happen if you have virtual copies and a file nameing pattern that doesn’t differentiate). The plugin adds the “-#” suffix if there would be any conflicts with any previously-published image. You can avoid Lightroom’s “-#” suffix by using the plugin’s “Extended File Renaming” feature. —Jeffrey

— comment by Heinfried on May 17th, 2020 at 7:56pm JST (10 months, 24 days ago) comment permalink

Hi Jeffrey,

Firstly, great work, the plugins you provide are awesome and appreciated!

I have an issue with this folder publisher plugin however. I have source and destination on D: (Raid 10 array). Lightroom and its catalogue are stored on C: (SSD). Whenever I run the plugin for a large collection it has continual high throughput on the SSD and completely fills it (right up to 0 bytes free). This seems to be due to LR Preview Cache. Both the filling of the SSD (main concern) and very high SSD usage/throughput (secondary concern) seem unnecessary. Is there some way to avoid this occurring?


Unfortunately, this is all Lightroom’s doing. The plugin accepts the files as Lightroom produces them, and moves them to their destination right away. The plugin takes almost no time to do this, so it should always be caught up with what Lightroom is producing (and just in case, the plugin tells Lightroom not to work too far ahead), so this buildup, which I’ve heard of before, makes no sense to me. I suppose you could reduce the size of your Camera Raw Cache (see the Performance tab of Lightroom’s settings), and perhaps that would help??? —Jeffrey

— comment by Fraser on June 1st, 2020 at 10:59am JST (10 months, 9 days ago) comment permalink

Hi Jeffrey – thank you for your prompt reply!

I’ve managed to track down where the build up is located, it’s in one of the temp folders (located in C:\Users\xxx\AppData\Local\Temp) that seems to contain photos being published (i.e. the post conversion photo). It’s in a folder with an alphanumeric string but no {} around it like the others in there. The number of photos in there is constantly moving but overall tracking up whilst CPU load is max and only tracking down once CPU load drops (presumably once all the JPEGs have been created) the number just tracks down.

Incidentally, I note your log file for the folder publish running right now is up to 95mb and increasing slowly.

Does that give you any ideas or help narrow it down? 🙂

I’ve pushed out a new version of the plugin that includes some extra debugging. I’ll ask, please, to install the new version, turn on the “enhanced debug logging” feature in the Plugin Manager, start a big publish operation and let it go for a while, then send the log and I’ll take a look. (Note that I found a bug in Lightroom whereby it continues publishing even after the publish operation has been canceled, filling up that temporary folder that should have been deleted. So you may want to shut down Lightroom after sending the log, then manually go and delete that temporary folder.) Thanks! —Jeffrey

— comment by Fraser on June 2nd, 2020 at 12:08pm JST (10 months, 8 days ago) comment permalink

Hi Jeffrey

I’m evaluating your folder publisher plugging as I hope it will solve a problem for me. I realized that it handles paths case *in*sensitive (I use version 20200516.108 on Lightroom Classic version: 9.2.1 [ 202004070813-7699d98a ]). As I am on MacOS (which has a case-sensitive filesystem), this worries me because it can cause filename collision in the published catalog that were not there (obviously) in the original file tree. I see these things that could happen:

1. inter-drive collision

Some files on (drive)/pictures/…
Some files on (other drive)/pictures/…

=> jfFP merges those into the same dir (published)/pictures

I don’t see a way how to fix this except for renaming the directory on one of the drives. This happens to me because I have pictures in my home folder under “pictures” and pictures on my NAS in the folder “pictures”. One solution is to make a trivial change in (one of) the directory names. But this could lead to issue 2:

2. case collisions

The above-mentioned problem still happens to me in this case:

Some files on (drive)/Pictures/…
Some files on (other drive)/pictures/…

(note the capital “P” in “Pictures”)

Published files are all stored inside a single folder named “pictures”. I expect two folder: “Pictures” and “pictures”.

=> I consider this a bug in jf FP. Could you do something about it?

I expect that this will also happen for directories (or filenames) on the same drive. I worry that

a) not all fotos are published (some fotos are overwritten)
b) oscillations or other strange behaviour will start. Such as when I change the original of the overwritten file. This will probably trigger a republish of that file which will replace the overwriting file with the previously overwritten file which could in turn (maybe) trigger a re-publish of the other file. and so on.

And if I may ask: Will I also have to worry about special chars (such as spaces or Umlauts) in pathnames?

Best regards,
Adrian from Switzerland

MacOS can support a case-sensitive file system, but its default is case insensitive, and you’ll have real problems trying to run any Adobe product on a case-sensitive file system. I speak from experience. As for name conflicts, the plugin will handle them properly and files won’t get overwritten… unique photos with shared names will get unique names (e.g. “foto.jpg” and “foto (2).jpg”). Lightroom itself had a bug WRT this, but it was fixed in the version that you have. —Jeffrey

— comment by Adrian on June 4th, 2020 at 4:34am JST (10 months, 7 days ago) comment permalink

> Added the ability to find missing published photos and have them marked for republish.

Is this a function menu or button somewhere?

Yes, in the “Publish Tree” section of the publish-service settings dialog. —Jeffrey

— comment by Chris on June 10th, 2020 at 12:43am JST (10 months ago) comment permalink

Hi Jeffrey,

Coming in from Vancouver, Canada! Thanks for this plugin, it’s a much-needed tool! Your work is awesome!

I’m running into problems with HEIC files. I have several that came from my wife’s iPhone. None of them successfully exported using this plugin. They produced log messages like this:

Filename = “IMG_7219.HEIC”
full_master_info = table:
| fileCreationDate = 622790008
| fileCreationDateTimezoneOffset = -25200
| fileModificationDate = 622790008
| fileModificationDateTimezoneOffset = -25200
| fileSize = 1654062
full_master_path = “REDACTED/IMG_7219.HEIC”
i = 75859

plugin processing time since prior render finished: 1.0 sec
render wait time: 0.0 sec

folder-publisher#109 +112137.6>041117 [x600005859388] @TreePublisher_Main line 204: result of waitForRender()

isVirtualCopy = false
master = “REDACTED/IMG_7219.HEIC”
rendered_image_attribs = empty table
rendered_image_fullPath = “openNegative: dng_error_bad_format”
success = false
viaMaster = false

I don’t have any other problems with these HEIC files, so I was wondering if it might be a problematic assumption about what’s in them?

Thanks for any help you might be able to provide!

(Also, would love to sync with you about some Lightroom-related tools I’m interested in building myself.)


The “dng_error_bad_format” error is coming from deep within ACR (which itself is deep within Lightroom)… it’s having trouble reading that file. Is it possible that file’s in a folder that’s something other than standard, such as on a remote server, or a Dropbox folder? This could explain intermittent issues. (For your tools questions, please email. —Jeffrey

— comment by Thad Hughes on June 30th, 2020 at 5:15am JST (9 months, 11 days ago) comment permalink

As a heads up for others, this plugin in not compatible with Lightroom Classic 10, getting errors:

Sorry about the delay… I pushed out new versions a few hours after Lr10 was announced. —Jeffrey

— comment by Jonathon on October 20th, 2020 at 10:59pm JST (5 months, 21 days ago) comment permalink

After upgrading to LC Classic v10.0, I had to do a fresh re-install of this plug-in. All fine except that I’m not seeing the “Mark as published” option anymore when I right-click with images selected. Without that option, I would have to re-publish my 20K+ old images. I hope I don’t have to do that. Any help? Thanks.

Lightroom allows the “Mark as Published” option only in the “Modified Photos to Re-Publish” section. Upgrading to Lr10 shouldn’t have required re-creating the publish services, but if you did recreate the publish services, you’d have to publish all as if starting from scratch, because that’s what creating a new publish service is. (On the other hand, simply re-installing the plugin files should have no effect on any of this.) —Jeffrey

— comment by Michael on October 27th, 2020 at 7:24am JST (5 months, 15 days ago) comment permalink

I have same issue as Chris from 25 April. Publisher works for a while but then seems to freeze and will not publish the remaining photos or videos. When I restart Lightroom (6.9, on Windows 10) it works for a while but eventually halts, or rather, Lightroom reports (when I try to quit) that a process is still going– I decide to wait it out but nothing happens and I mean 1-2 days later. Chris and others report issues on videos – could be, I have included videos in the Publish but they have been making it through to the backup disk and look fine (better than in Lightroom, which for some reason has taken to previewing videos with a hideous green cast).
The only clue I can add is that the CPU is in fact churning away, 70-80% via a process called amecommand.exe. Next morning it’s still going but by afternoon amecommand.exe has disappeared from Task Manager, and no CPU/disk/memory activity – though Lightroom still warns me upon quit that an (unspecified) process is still going. amecommand.exe is reported to be part of LR, though no one quite knows what it does.
So there you have it. I’ll keep pressing ahead, Publisher seems to make a little more progress each time I restart so perhaps I can eventually make a backup of the entire photos directory… and much easier than doing it manually. For which, thanks. But naturally I’ll check whether some could be missing.

I’ve no idea what “amecommand.exe” is, but these kind of delays are almost certainly videos. If it’s something that works with your workflow, you can have the original video file copied as the exported video (by setting the video format to “ORIGINAL”). Since Lightroom doesn’t have to render it, it’s as quick as a file copy. —Jeffrey

— comment by Michael on October 30th, 2020 at 6:19pm JST (5 months, 11 days ago) comment permalink

I heavily rely on “custom sort” ordering my pictures in Lightroom’s folders (I am not using collections) by dragging pictures among one another in Lightroom’s grid view. Is there a way to have the output filenames reflect this custom ordering?
Built-in Lightroom renaming features, as well as “AbsSequenceFirst” (and the likes), always generate a numbering that has the same order as the original files ordering, even if my custom sort is different.

Thanks (and congrats for this great plugin!)

The very first time that a publish-collection is published, the order of the photos in the publish collection should be reflected in the output filenames, but once files start getting added and deleted, the sense of order can get lost. —Jeffrey

— comment by Jérôme on November 19th, 2020 at 7:23am JST (4 months, 22 days ago) comment permalink

Jeffery, your http (i.e. not https) addresses don’t now play well with some browsers (eg Firefox) which have options for requiring https sites. FYI. … David

Yeah, I’ve heard. Those browsers shouldn’t be doing that. I’ve had separate content on the two servers for two decades; it’s not appropriate to assume that they’re the same. —Jeffrey

— comment by david on December 17th, 2020 at 9:38pm JST (3 months, 24 days ago) comment permalink

Is it possible to use template tokens in the elements of the path which will be prepend or append to the root path as provided in a given collection settings? I tried to use {YYYY} , but this template was not resolved into actual years when I kicked off publishing. What is wrong? Thanks!

No, sorry, template tokens are not supported there. I wanted to have them supported, but I ran into some technical problems in how Lightroom allows plugins to access photo data, and wasn’t able to resolve them. )-: —Jeffrey

— comment by Vladimir on December 30th, 2020 at 1:42am JST (3 months, 12 days ago) comment permalink

I want to report a bug with unicode folder names, and feature of setting file date.
To reproduce:
– Publish a video file that reside in folder that contains unicode characters (I suppose it also reproduces with jpeg).
– In publish settings, select “Explicitly set date to photo capture date”
– The exported file will get current date set as file creation date.
– In log, there appears error with “setdate: bad arg pair time”, I suppose due to file name.
Will be grateful if you look at it.

log = “Start of execution
ARG[D:\Pictures.publish\My Photos\2015-12-25 ???? ??????\MVI_0155.mp4]
No conversion needed for: D:\Pictures.publish\My Photos\2015-12-25 ???? ??????\MVI_0155.mp4
d:\Pictures\Lightroom\Plugins\folder-publisher-jfriedl.lrplugin\setdate: bad arg pair time[1451046154] file[D:\Pictures.publish\My Photos\2015-12-25 ???? ??????\MVI_0155.mp4]

status = 1

Can you send the full plugin log, as described here? Thanks. —Jeffrey

— comment by Roman on January 5th, 2021 at 3:11am JST (3 months, 6 days ago) comment permalink

I have problems to publish my photos of a sub-folder in the same personalized order, when I select different origins. I mean, I select for publication the folder of the year, with different months and topics inside. The customized order of my photos in each topic is lost during publication.
Is there some way to keep the photos in my custom order?
Thank you very much.

It’s almost impossible. The plugin publishes photos in the order that they’re presented in Lightroom, but the ordering that the copies are made for local disk is not usually reflected in how the OS (Finder or Windows Explorer) presents photos in a folder. Usually it’s done via filename sort, so if you arrange for output filenames that sort in the same order as the order you want, it’ll work, and this is pretty easy using the “Extended File Renaming” tools of the plugin, but then it all falls apart once new photos are added, since the plugin won’t rename older photos to account for the reordering. It’s a tough nut to crack. —Jeffrey

— comment by Federico on January 19th, 2021 at 8:33pm JST (2 months, 22 days ago) comment permalink


I sent a message before but I’m not quite sure if you got it. Using the watch folder system. Can I have one file go in and export the same file but with many different profiles applied to that one photo.

So another words. One photo goes in. 20 photos come out and each photo has a unique profile apply to it.


No, sorry, I can’t think of any way to do this. You’d need to make 19 virtual copies, apply the develop presets to them, and somehow (perhaps via keywords and smart collections?) get them into different publish collections for export. It might be possible with a custom plugin, but I’m not sure. —Jeffrey

— comment by Author on January 27th, 2021 at 7:59pm JST (2 months, 14 days ago) comment permalink

Is there a possibility to publish multiple folder trees with different image sizes? An example would be a full size export + a 4k export for quick browsing. Lightroom 9 introduced something called multi-batch exports – I wonder if that can work with a publisher plugin like this

Thanks for a great plugin, much better than anything else

You can do this by setting up multiple Publish Services, with the only difference between them the different image-size settings. It’d be nice if one publish service could do multiple sizes, but Lightroom doesn’t allow for it. —Jeffrey

— comment by Ashish on January 29th, 2021 at 1:03am JST (2 months, 13 days ago) comment permalink

Hi Jeffrey,

first of all – thanks for your work, the Folder Publisher plugin is exactly what I have been looking for.

However, after a few successful runs with small data sets it failed when I tried to apply it to a collection of ~25K items. It only published the very first item (which was a video incidentially) and then kept running and running without adding new items to the target folder on my external drive. It kept adding new converted items to the internal temp folder, however – I stopped the publishing process when this folder reached 1.3K items / 11.3GB. The temp folder name is a UUID without the enclosing {} that most other folders have.

I am running LR 6.14 on Windows 10. The issue seems very similar to the one Fraser reported on 2020-06-02. Did you find a solution for that one?


I’m going to guess that the 2nd item is a video that the system is crunching away on at the same time that less-crunch things are being generated by other threads. Lightroom can take a VERY long time on videos….days. Perhaps try without videos first? As for the buildup, the plugin instructs Lightroom to not render so far ahead, but Lightroom seems to ignore it. (If trying again without videos doesn’t solve it, perhaps send a plugin log with another recap once it’s gotten into that stuck state.) —Jeffrey

— comment by Martin on March 15th, 2021 at 3:20am JST (3 weeks, 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