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 )


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

Hi Jeffrey,

I want to change a collection but got the following error message (2x):
1. message:
Error with your “jf Folder Publisher” Publish Service named “Export Internetgröße”: the root of the publish tree does not exist. Perhaps you need to mount a removable drive? If you have moved the root folder, you can point the plugin at the new location in the Publishing Manager.

I have access to the folder. The folder is on my nas.

Can you please help me?

Best regards!

Is it possible that the location of the root, as seen by your OS, has changed? E.g., on Windows, maybe it got mounted via a different drive letter, for example. —Jeffrey

— comment by Gunther on August 25th, 2017 at 6:43am JST (1 year, 4 months ago) comment permalink

When I try to change the settings in the manager I got an “internal error” message in german language
What went wrong?

It’s impossible to guess with so little information. Perhaps send a plugin log. —Jeffrey

— comment by Gunther on August 25th, 2017 at 7:31am JST (1 year, 4 months ago) comment permalink

Hi Jeffrey

I am very interested in your Folder Publisher plugin and I am about to download it. However, I wonder if it would be possible to go “one more step”. I would like to overwrite the source files. That is, do what your plugin does, but put the photos in the source folders/subfolders instead of in a different location.

I know this goes against the LR philosophy of always keeping the original (the “negative” as they call it), but I do not operate that way. I dump all my originals into a Hard Disk, then work on a copy of them. Then I can delete all I want, adjust, add metadata etc and thus keep my entire collection SMALL and easily TRANSFERABLE to other platforms (I work in different locations). Once I have worked on a photo, I practically never go back to it to change adjustments for ex. But should I ever need to do it I would extract it from my “original dump”.

Do you think that your plugin could be tweaked to do that ? I would gladly make a donation if this became possible.

Cheers from France, Pierre (

Sorry, that’s just too “wrong” (from a Lightroom philosophy point of view, as you mention) for me. —Jeffrey

— comment by Pierre-Yves Bely on August 31st, 2017 at 11:51pm JST (1 year, 4 months ago) comment permalink


Writing from France!
Using W7 64, Intel I7 with 16 G ram. Using LR CC up to date. And plug in up to date also.
LR catalog on an internal SSD, picts on an external HD (2 TO). More than 100 000 picts on the LR database.

Here is my issue:

I have a “folder publisher service” with more thant 1 000 picts coming from 7 “basic” LR folders.

1. I select my folder pblisher service.

2. I add some new picts in the “folder publisher” service place, to update my target folder.
The service is highlighted.

The pictures to be published or re published show up in the main window.

3. Before publishing, I go to any folder in the LR library (example: “Truc”) just to check for more picts to be added to the publish service .
The “folder publish” service remains Highlighted (strange?).

4. Going back to the “folder publisher” service does not show the picts to be published (clicking on the service name or on the line below witch mention the number of picts to be published).
The folder I was working on (“Truc”) (and its picts) remains displayed on the main LR window.
This folder is Highlighted.
The “folder publisher” service is also still highlighted.

Strange, isn’t it?

Impossible to change that, except with closing and restart LR.

This strange behavior happened with previous versions of LR and of the plug in, but, as I use the plug in more often, it becames more anoying!

Any idea?

Thanks for your help.


I’ve seen this before, rarely. It’s just a bug in Lightroom (that has nothing to do with the specific publish service you’re using). When I see it, a restart has always fixed it and I don’t see it again for a long time (months or years). If you’re seeing it a lot, I’m not sure what to say. Maybe first do an integrity check on your catalog? Maybe optimize it? Maybe reset your preferences? It’s frustrating. I’d suggest that you report it to Adobe, but I don’t think you’d get a reply )-: —Jeffrey

— comment by Jerome on September 10th, 2017 at 6:48pm JST (1 year, 3 months ago) comment permalink

Hi Jeffrey,

Thanks for this plug-in. I needed something like this because the LR publish does not mirror to disk. So awesome.

Is there a way to NOT use the LR folder structure ? I’d like a single folder with all the photos in the collection


You can do that with my Collection Publisher plugin. —Jeffrey

— comment by Hans Douma on October 7th, 2017 at 11:16pm JST (1 year, 2 months ago) comment permalink

Hi Jeffrey
writing from Switzerland
Thanks for this great plugin (and others)!
Folder-publisher 20171019.87
Windows 10 V. 1703
after upgrading to Lightroom Classic CC (V.7.0.1) the plugin dosn’t work properly
All the Smart Collections are empty (0 fotos) and the plugin is trying to delete all formerly published fotos.
Filter setting is the same as in LR 2015, where the plugin still works fine

The same behavior with the jFlickr Plugin…

Thanks for any hint to resolve that problem

Sorry for the delay. There’s a bug in Lr7 related to smart collections and the “contains” rule. It’s unrelated to the plugin… it affects all smart collections that tickle that bug. Adobe is aware of it and I think a fix will be rolled out sooner than later. —Jeffrey

— comment by Wilfried on November 3rd, 2017 at 7:11pm JST (1 year, 2 months ago) comment permalink

Hi Jeffrey
Do you know whether I will be able to use the JPEGmini plug in with your publish service?
Best regards

Sure, it works fine. —Jeffrey

— comment by Richard on November 23rd, 2017 at 4:17am JST (1 year ago) comment permalink

For some photo and video, when they are published, the filename is completed with -2 suffix.
For example OriginalFilename-2.jpg.
There is no photo neither with the original filname, nor with -1 or -2 suffix present in the folder at the beginning.
I have tried to delete the files and republish them. Same files are published with same -2 suffix.
Do you think the problem comes from the plugin or from Lightroom ?

The “-2” comes from Lightroom because of complexities in how it works before it gives control to the plugin. They come back again with “-2” because the plugin works hard to maintain a relationship between a photo in Lightroom and the result of the plugin, so it keeps the filename from the first export. You can get around this by using the extended-renaming section to make your filename choice explicit. You might want to use “{LibraryFilename}“, for example. —Jeffrey

— comment by Olivier on December 10th, 2017 at 2:51am JST (1 year ago) comment permalink

Hello Jeffrey,
I have tried with {LibraryFilename}, but the filename always contains -2. Even if I remove the previous published file in the destination folder.
(I had uncheck the Lightroom built-in naming option in the publish service).
I have tried an other template (like CameraModel), just to see if the enhaced renaming works, and it works.
This behavior is not a big problem, but if you have any complementary idea…

Once a file has been published, it keeps its name forever. It would be a very bad experience for most people to have their files randomly change names. To get it to forget about the name, you have to remove it from the publish service, and then re-add it. That should disconnect the photo from the output filename. —Jeffrey

— comment by Olivier on December 11th, 2017 at 1:13am JST (1 year ago) comment permalink

Hi Jeffrey. I have an issue with deleted images that are not being deleted from the published folder.

I always use Synchronize Folder menu to import/update/delete my photos. If I delete some photos from the folder, then synchronize they get deleted from LR library and they do disappear from a smart collection tied to this plugin. But for some reason, plugin doesn’t detect the deletion and doesn’t offer to delete published images. What should I do in this case?

This is a bug in Lightroom; I’ve reported it to Adobe. I don’t see a workaround other than to delete photos from the library via some other method, since other methods seem to properly invoke a publish service’s delete hooks. One idea would be to use the “File Currently Available” item in my Data Explorer plugin to isolate missing files into a collection, then select them all and from a thumbnail’s context menu select “Go to Folder in Library”. Now you’re back at the folder, but with all should-be-deleted photos selected. Now delete normally and publish service hooks are invoked. —Jeffrey

— comment by Maxim Rubis on December 14th, 2017 at 6:59am JST (1 year ago) comment permalink

Hello Jeffrey,
I am using your plugin to export a complete copy of my folders to DNG format, so that I’m not stuck with a bunch of unreadable file formats in future years. Functionally, all is going well, however the process is very slow – I have about 50,000 photos in my collection and at the current rate it’s going to take about 50 days to export all of them. This is on a PC with 4 cores x 2 threads @4GHz and the CPU is running at about 20%. There’s no memory shortage. Perfmon says:

Resource Overview

Component Status Utilization Details
CPU Normal 21 % Normal CPU load.
Network Idle 0 % Busiest network adapter is less than 15%. Nic Intel[R] I211 Gigabit Network Connection _2 using 169,504 bits and has 1,000,000,000 bits capacity.
Disk Idle 62 /sec Disk I/O is less than 100 (read/write) per second on disk 7. Reads 41.9/sec + Writes 19.9/sec
Memory Normal 53 % 7680 MB Available.

When I use Publish to Hard Drive, the whole process goes about 100 times faster (and is pretty much limited by the disk at that point – the disk queue is something crazy, like 25), though it is still doing the same source format to DNG conversion (but obviously not creating the folder tree). Do you have any ideas on how this could be made to go faster, please ?

I suspect that the delay is within Lightroom. The built-in Hard Drive publish service doesn’t actually use the same plugin infrastructure that my plugin has to use, so maybe it has some advantage that manifests itself in this speedup. Still, I’d like to check it out, so let me ask you to do the following: restart Lightroom, select a dozen images in Grid, hold down the alt/option key to turn the [Publish] button into [Publish Selected] and click that. Once it’s done, send the plugin log (being sure to include a note to remind me what it’s about) and I’ll look to see where it’s spending its time. —Jeffrey

— comment by Frank on December 19th, 2017 at 5:27am JST (1 year ago) comment permalink

Hello Jeffrey,
Thanks for the “Folder Publisher” plugin. It definitely fills a gap in Lightroom offering.
I am using it to export ~100,000 photos/videos to a folder that gets indexed in my NAS and thus make all of them available from anywhere in a nice and fun browsing environment.
I initially started slow until I got the hang of things and then triggered an export of all photos. All went well, it took 3 days but result was as expected.
Then I added videos in small chuncks and things also went well.
But at some point I lost control of things. Clicking on the publish button led to no activity at all despite the fact files needed to be published.
Yesterday I decided to start from scratch and thus deleted the plugin, the exported files and reinstalled the plugin.
Unfortunately things do not work well anymore.
My question will be simple: How do I make sure I delete all history of the plugin? Isn’t deletion of the plugin sufficient?

Deleting the plugin doesn’t delete any of your data… that’s all in the Publish Service in the catalog. Deleting the publish service should be sufficient. As to the problems you faced the first time, if you encounter them again, please send a plugin log and I’ll take a look. —Jeffrey

— comment by gijom on January 23rd, 2018 at 3:39am JST (10 months, 27 days ago) comment permalink

I use your plugin for years now, with great success.

Just one thing really bothers me : it seems that whenever I come back in a folder inside lightroom to watch old pictures (all are DNG’s) it triggers something that makes all the pictures of the folder I’ve been into to needs republishing.

That’s a little bit annoying…

The problem seems to occur only when watching photos I have not accessed for a long time and LR needs to regenerate some previews. For example if I go and come back in my latests pictures it does not triggers a republishing event, but if I go back in my folder structure to a 2014 folder I have not accessed for 2 years, it triggers the republishing event.

In the plugin configuration, there is nothing checked in the “metadata that triggers republish” section.

Any idea?

PC / LR 7.1 (classic CC) / DNG and exported jpegs are on a shared drive (server under Windows)
Writing from France.

Yeah, this is a real pain, and Lightroom has been buggy like this since Publish was introduced. Please see this FAQ for more commiserating. —Jeffrey

— comment by Olivier on February 8th, 2018 at 12:58am JST (10 months, 12 days ago) comment permalink

Hi Jeffrey,
This plugin seems like it may be what I need, but frankly, I’m not technically advanced enough to understand what it does for sure. I use LR Classic on Windows 10. My photos, both original and edited, are on my computer. I need a second backup location for edited photos, since LR only backs up the catalog of original photos to my hard drive, not the edited ones. I plan to use a cloud service too, in case both computer & hard drive are lost. Will this plugin allow me to easily select only my edited images in LR and send them to my hard drive? I could choose all 4-5 star images, that’s mainly what I’ve edited; the unedited photos are fewer stars. Thank you! Hope this makes sense..

Yes, this’ll do exactly that. However, as an aside, I’ll suggest that you also (or instead) back up the Lightroom catalog often, as that, combined with the master images, is everything needed to re-create all the edited copies. —Jeffrey

— comment by lynn on February 27th, 2018 at 12:04pm JST (9 months, 20 days ago) comment permalink

Hi, the new version of Lightroom Classic (7.2) is incompatibile with Folder Publisher. Do you plan to upgrade it? Thanks


Perhaps you have a (very) old version…. any recent version should work fine. —Jeffrey

— comment by Davide on March 19th, 2018 at 2:16am JST (9 months ago) comment permalink

(UK). I’m having problems with folder publishing missing output files when virtual copies are involved. Within Lightroom everything looks fine, but when I look at the actual output files, I find some are missing, all ones which are virtual copies or have virtual copies.

I’ve tried some simple tests with just one master file and two virtual copies, and the first thing I notice is, the master version output file seems to get appended with “-3”, with one of the virtual copies getting the bare name, which seems the wrong way around. The other virtual copy gets “-2” which is fine.

I then delete the output files, “mark to republish” and publish again. Now in one of my smart collections, this produces same output files as before. But for another smart collection, seemingly identical but with a different output folder, I get just two output files, the “-3” one corresponding to the master file, and one with an odd “-2-2” suffix corresponding to one of the virtual copies. And when I watch the files being generated, I can see the missing virtual copy is actually generated first, with the “-3” suffix, but is apparently then replaced by the master version with the identical name when that is generated.

So it looks to me as if there is a semi-random problem arising from output naming with virtual copies, resulting in some output files getting overwritten when they should be retained.

Incidentally I am using a newly downloaded plugin, windows 10/64bit, lightrooom 6.14, and mostly using plugin defaults (with no renaming of output files).

All a bit frustrating ..

I’m going to guess that there are multiple issues at play here. During any particular publish operation for new photos, Lightroom comes up with some filenames, and the plugin preserves those names unless they conflict with filenames already in use (having been assigned to photos published earlier in the publish service). Lightroom itself doesn’t notice nor care about what filenames might have been used for other files… it cares only about the set of photos being published right now, and depending on what’s in that mix and the order they happen to be published, Lightroom appends these sometimes-weird suffixes. To avoid this, consider the “Enhanced File Renaming” section, whereby the plugin ignores the filename generated by Lightroom and uses one that you decide. In any case, once the files are handed over to the plugin, it has to make sure that there are no conflicts among any of the photos in the publish service, and no unexpected conflicts on disk, so it’ll add its own suffixes as needed to keep data consistent. If your enhanced renaming ensures that filenames will never collide, you’ll have perfect control over the names and there will be none of these issues. Consider using the virtual-copy name (“Copy Name”) as part of the filename. —Jeffrey

— comment by derek langley on May 1st, 2018 at 4:30am JST (7 months, 18 days ago) comment permalink

Hi Jeffrey, greetings from Italy.

I have a collection of 18100 photos dating from 1960, so publishing them with the desired hierarchy is a big task. I cannot thank you enough for this gem, that has saved me tenths of hours of tedious work.

Great job!


— comment by Ivano on May 6th, 2018 at 7:34pm JST (7 months, 13 days ago) comment permalink

I seem to have a problem with Folder Publisher. It’s fairly easy to set up, but I am unable to publish my rather modest 9000+ pictures to a folder on the local disc. It goes fine (although rather slow, but that’s LR’s fault) for about 3000-4000 pictures, but then it invariably aborts with an error saying something like “Unable to move …. does not seem to exist” or something to that effect. The first part of the message is the name of some temporary folder, and if I look into that I see some of the pictures that I’m publishing.
I hope there’s a cure for this problem, because Folder Publisher fills a large hole of missing functionality in LR.

Best regards,
(writing this from the city of Skanderborg in Denmark 🙂

Next time you encounter this, please send a plugin log. —Jeffrey

— comment by Steen Kroyer on June 28th, 2018 at 5:49am JST (5 months, 21 days ago) comment permalink

Hi Jeffrey,
I am a big fan of your plugin but there’s something that doesn’t seem right. I have a single Smart Collection defined for the Publisher, which holds every raw photo in my collection. Every time I hit Publish, the plugin exports again EVERY single photo, regardless if it’s been modified since last time or not. It takes hours, each time. Any idea what I might be doing wrong?

Please see this FAQ —Jeffrey

— comment by Stefan on July 17th, 2018 at 3:47am JST (5 months, 2 days ago) comment permalink

Hi Jeffrey

Very happy with your plugin, which I use extensively. A question:

My “Published Photos” Collection is now quite big and I would like to get rid of the photos it contains since I do not have to rework them.

Is there a way reset the “Published Photos” collection (i.e. bring their number to zero) when they have all been published ?

I tried “Removing from collection”, but it actually deletes the corresponding photos completely from the target folder, not just from the collection of published photos.

“Deleting” does of course the same thing.



There’s a “Delete Options” section in the Publishing Manager that controls whether they’re deleted from the target folder; adjust that and you’ll be fine. —Jeffrey

— comment by Pierre-Yves Bely on July 30th, 2018 at 4:13pm JST (4 months, 20 days ago) comment permalink

I used this plugin to create DNG and TIFF archives on external hard drives. It worked fine. I am intending to update such archives maybe on a yearly basis (by connecting them and hitting Publish). Unfortunately, after moving the hard drives to a safe location, I am no longer able to delete photos from my catalog. As soon as I attempt to delete a photo from a folder, I am seeing an error: “Can’t update this collection. Error with your “jf Folder Publisher” Publish Service (…); the root of the publish tree does not exist”.

This is fine. I know I have disconnected the hard drives. But I would like to delete some photos. Is there a workaround?

The plugin should give you the option to proceed, so I’ll work on that, but please realize that if you completely remove a photo from Lightroom without first letting the plugin “Publish” the removal from the publish service, the previously-published DNG/TIFF remains, so you’ll end up with orphan files. —Jeffrey

Update: hah, I forgot that the option is already there. See the “Delete Options” section in the Publishing Manager. —Jeffrey

— comment by Tom on July 31st, 2018 at 5:28am JST (4 months, 19 days ago) comment permalink

Hi Jeffrey, thank you for pointing me in the right direction. The selected option was “Yes, delete published copies from disk when originals are removed from Lightroom”. With the Root of Publish Tree disconnected this was acting just like the last option: “Don’t allow photos in this collection to be removed from Lightroom; abort the delete operation”.

The option which lets me delete source images from Lightroom when the Root of Publish Tree is disconnected is “No, leave published copies on disk”. I am fine with the resulting orphan files in the archive. This approach should protect from accidental deletion of originals (which would propagate to backup drives), as long as the originals have been published to the archive drives.

— comment by Tom on August 1st, 2018 at 6:38am JST (4 months, 18 days ago) comment permalink

Can the plugin be updated to cleanup the TEMP directory as it publishes files? Right now, it retains all of the temporary files until the complete publish is done which is problematic for very large libraries, in particular Video libraries.

Alternative, can you at least add the ability to set the TEMP folder to the folder/collection publisher plugins like the Smugmug plugin has.

The default temp Directory of the folder/collection publishers is where the OS is which is typically a small drive and compounds the problem above.

Lightroom should take care of keeping it clean as files are exported, but on top of that just in case I do have the plugin delete the copy the moment the export has completed. At least for the normal exporter plugins… which plugin are you speaking of? —Jeffrey

— comment by Andrew on August 2nd, 2018 at 11:56pm JST (4 months, 17 days ago) comment permalink

I’m using the folder publisher when the TEMP drive fills up. If lightroom/the plugin are cleaning up after each file is published then I think the problem must be that every single filed is put in the TEMP directory before a single file is published because in order to publish i need the same amount of temp space available as all of the files i’m trying to publish in the folder publisher.

There is an option within Lightroom that the plugin can use to tell Lightroom to not render too far ahead of what the plugin has handled. It really shouldn’t matter for this plugin because the plugin “handling” is just moving a file, but let’s give it a try. I just enabled that option in version 20180803.91. Let me know how it goes…. —Jeffrey

— comment by Andrew on August 3rd, 2018 at 10:24am JST (4 months, 16 days ago) comment permalink

Is it possible to trigger republishing of images if the Foldername has changed. I tried „source“ in the “metadata that triggers republish“ menu but that doesn’t work.

If its not possible now, that would be a nice Feature for the Future, in the best case the plugin would simply rename the published Folder instead of republishing all images again…

Unfortunately, Lightroom doesn’t allow for this. )-: —Jeffrey

— comment by Timo on September 25th, 2018 at 1:51am JST (2 months, 25 days ago) comment permalink

Thank you for this great tool. I have a question about the best setup:

I’m using a MacBook with limited disk space. So I move older pictures to a NAS. I use the publisher to create low res images on the Mac for the screen saver from images on disk and from the NAS. So I regularly move images from the Mac to the NAS.

If I keep the directory structure on NAS and Mac the same, eq. Foto as the highest level, would this cause problems if I move a picture from Mac to NAS and edit it later? Name conflicts are not possible, as I move whole directories.

Or what would be the best setup for this use case?
Best regards Peter

I don’t quite understand what you’ve described, but what you face is a common problem. The usual way to solve it is to generate Smart Previews for the photos before moving them to the NAS (and off your local disk). In such a case, you can still edit and export within Lightroom, but you’re dealing with a low-resolution Smart Preview, and have to re-load the master file from the NAS if you want to work with the original. Another option is to change the root of your library from your local disk to the NAS and back, as needed, but this can be quite dangerous if you’re not careful to keep things straight. —Jeffrey

— comment by Peter Heuchert on September 25th, 2018 at 7:47pm JST (2 months, 24 days ago) comment permalink

This looks like one good tool to have.

— comment by Roston Chase on October 27th, 2018 at 3:57pm JST (1 month, 23 days ago) comment permalink

Thank you for this awesome tool. I upgraded to the latest version, but it seems I did something wrong. Whenever I publish some new photos, all existing file structure and files in the target folder are being deleted. I actually want the target folder structure to increase over time since I mirror this into the cloud. I tried the different “delete” options but hat did not change anything on this end. Thank you for helping.
Best Regards, Thomas

It’s difficult to guess the issue based on the limited info here, but the intent of the plugin is to make, after a publish operation, the target folder hierarchy exactly match the publish service. Random unrelated files in the target will be deleted. —Jeffrey

— comment by Thomas on November 26th, 2018 at 9:27pm JST (3 weeks, 2 days ago) comment permalink

Hi Jeffery,

Thanks for this plugin which i had been running with lightroom 6.8 for years happily.

I’ve recently moved to a different computer which runs another version of lightroom (classic cc 7.5) and started to experience some problem. The publishing is very slow, and at some point got stuck.

I have about 27000 images (including about 600 videos) to export. It used to take a few hours to export which is bearable. Now, on an AMD 8-core process and 32GB RAM, it only managed to publish 15000 pictures after 30 hours, and the process is now stuck with the number of published picture doesn’t move further.

I tried changing a few settings like skipping videos, adjusting JPEG compression ratio etc; none helped.

I tried using lightroom’s builtin export feature on the same machine and it works just fine, which seems to indicate the problem is with the plugin itself.

Could you please shed some light? Many thanks.

My first thought was video files getting stuck, but you then ruled that out. Leaving video out of it, could I ask you to send a plugin log once you think it’s stuck? —Jeffrey

— comment by Calvin on December 15th, 2018 at 5:35pm JST (3 days, 22 hours ago) comment permalink


in the last time I can’t update one folder. I always got the error message that folder publisher can’t write into that network directory. But that wasn’t rue, I tested it. Now I get the error message when I reconnected the root “RobustCopy 184 attemt to compare number with nil”.
What do I have to do to solve this? Thanks

Please send a plugin log when encountering either error. —Jeffrey

— comment by Claus on December 15th, 2018 at 6:10pm JST (3 days, 21 hours 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