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 )


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

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 (11 months, 25 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 (11 months, 6 days 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 (11 months, 6 days ago) comment permalink

Hi Jeffrey,

I’m having trouble in publishing folder from Win10 to a NAS
During the publish process a Warnig message is displayed: jf Folder Publisher: Can’t create target folder

The NAS is mounted as a network drive in WIN10, with NAS user login saved (different from WIN user, but stored in OS credential), and perfectly working from Windows Explorer, it’s possibile to write file and create folder on the destination folder on NAS.
In fact, if I create in advance the destination folder tree, the publishing process is correctly performed.

I suspect it can be an access rights problem occurring, but why Lightroom file management is not using the access right provided by WIN OS? is it running with different credentials?

Daniele from Italy

I’ve pushed out a new version of the plugin that has more debug logging… give it a try, and send a plugin log if you encounter a failure. Do note that if there’s already a file of the same name where the plugin needs to create a folder, there’s no way the plugin can resolve that conflict and you’ll have to either delete the file, or change the folders of the photos you’re trying to publish. —Jeffrey

— comment by Daniele Capizzi on January 15th, 2019 at 7:23am JST (10 months, 7 days ago) comment permalink

Hi Jeffrey. Thanks so much for the Folder Publisher. A question please. I use the publisher to create a second copy of all my DNG and RAF raw files to DNG. When doing my Publish, I have noticed that the DNG files (to DNG) “come out” around half the original file size, and the RAF (to DNG) files around 70% of the original file size. It may be that the efficiency of the export is doing it, but just wondering if I am “losing” anything in the export?
I have, in file settings, Image format DNG, JPEG Preview Medium size, Embed Fast Load Data ticked, and unticked are Use Lossy and Embed Original +RAW file.


The plugin doesn’t have any impact on how Lightroom creates the DNGs, so your question is more a generic Lightroom question. I don’t know the answer, but if your master DNGs have the original raw file embedded, the resulting DNG will of course be much smaller (about half), so that sounds likely. Perhaps use my online Exif viewer to inspect the before and after files, looking for big changes? —Jeffrey

— comment by Richard Histon on January 24th, 2019 at 7:03am JST (9 months, 29 days ago) comment permalink

Hi, great plugin

I use for publishing all my favourites to my phone via GoogleDrive.

However, I’d also like to publish everything (15000 photos) in relatively low quality (1000×1000 px) to GoogleDrive for sharing with my PCs and browsing from anywhere. I set this up and it ran quite successfully.

However, I Then noticed that my previews folder Lightroom Catalog-2 Previews.lrdata had grown to 11GB and my C: drive almost ran out of space.

presumably as the plugin accesses each picture it will cause lightroom to generate a preview.

Is this avoidable?

Lightroom needs the previews cache for displaying thumbnails, and all other non-Develop sizes. You can flush previews with my Bag-o-Goodies plugin, but then you’ll lose thumbnails, and Lightroom will need to rebuild them as you scroll around in the Library Grid. As you move around in Library with the full view, it’ll make bigger previews, so the cache will continue to grow back over time. (You can get some great performance benefits to put the catalog and its previews on a big SSD.) —Jeffrey

— comment by David Roberts on February 2nd, 2019 at 3:17am JST (9 months, 20 days ago) comment permalink

Hey, thanks for the amazing feature-rich plugin. I’m trying to use it in automated back-up solution to external disk – copy the originals with correct folder structure, but only these worth keeping (using star rating). Unfortunately – as written in “Metadata that triggers republish” section in settings – Develop always triggers republish. This is undesired because Developing does not change the originals.

Would it be possible to add settings to disable this behavior? Or maybe it should always be disabled if the folder is set up to publish the originals?

FYI, even when you set the image format to “Original”, it’s not actually just copying the original file… for reasons I can’t fathom, it actually means “original pixels with current updated metadata”. So this is probably not the solution for you. I could probably try to work out something to copy the original files behind Lightroom’s back, but it’s not currently possible with the plugin. There’s no way for a plugin to disable the republish-on-update stuff, but it may be possible to effect the same thing by working around it. I’ll give it some thought. —Jeffrey

— comment by Marek on February 2nd, 2019 at 9:00am JST (9 months, 20 days ago) comment permalink

Hi Jeffrey, reporting from China (Czech guy living in China).
I have this Folder publisher and publishing around 28000 photos to L drive and having the photo 5mpix size limit. Problem is that this plugin also creates photos on my C drive and filling all the free space there. Why is that? If I delete the temp files in c:\Users\Coudy\AppData\Local\Temp\E9B9514A-EBD1-4DAD-B9A2-15AC1F328347 the plugin stops with an error. Another problem is that in that temp folder it creates photos that are not publish to my L drive as per settings of the folder publisher. What information do you need from me to find the problem?

Lightroom creates the rendered copies for the plugin, and places them in a temp folder, then hands them off to the plugin to move to wherever you wanted them. The plugin work in moving the rendered copies should be relatively quick, so Lightroom shouldn’t be building up a bunch of waiting-to-be-processed items… but even if it were to, the plugin tells Lightroom not to build up too many. So I’m at a loss to explain where the temporary files are coming from. Perhaps you can investigate the exact contents and timing of the files, to get an idea of what is creating them, and for what purpose? —Jeffrey

— comment by Pavel Desort on February 25th, 2019 at 3:02am JST (8 months, 25 days ago) comment permalink

Hi, it’s really a great and very helpful tool!

I need some help: I moved my LR to a new computer. In the new setup I imported a backup of the catalog from the old computer. So far so good. Now the folder publisher has lost all it’s previous state about already published photos and want’s to publish the full catalog again. And that are really many (90,000) pics. So it’s not possible to just let it happen and sit and wait.

Is there a way to just mark all pics as already published?

No. )-: In this case, it would have been better to simply use the moved-over catalog, rather than importing it. (Lightroom excludes all Publish info when importing or exporting catalogs). —Jeffrey

— comment by Riccardo on March 21st, 2019 at 4:36am JST (8 months ago) comment permalink

I’m running LR CC…does your plugin work with it?
I need something that will export my files from LR and keep the creation date/time as the file date/time.

Adobe has made the naming stuff so egregiously complicated I’m not sure what to call it. If your “Lightroom” product can use plugins, it can use my plugins. All other “Lightroom” products can’t use plugins. You can use Rob Perrin on May 8th, 2019 at 1:35am JST (6 months, 14 days ago) comment permalink

Hi Jeffrey,

thanks a lot for your plugin, which I use to keep ~100,000 photos synchronized to a Dropbox folder.
Recently, I have run into problems:
I moved several 100s of already published photos to other folders within LR 6.0, but the move was not reflected in the published files. Also renaming an already published folder is not reflected in the published version.
I cannot (and don’t want to) undo the changes I’ve made in my lightroom catalog, but now I’m left with the LR structure not synchronized to the published version. What should I do?
I’m hesitating to delete all exported files on Dropbox and publish everything again, since it will take days…


Lightroom doesn’t consider filename or folder changes with Publish, so this aspect is inconvenient. I just realized, after all these years, that I can have the plugin scan for changes, so I just added that. The plugin hadn’t kept quite enough data to make the first scan reliable — it might be overzealous and dirty photos whose filename hasn’t changed — but from then on, each scan will be reliable and should cause photos whose filename or folder has changed to be republished. —Jeffrey

— comment by Elmar on May 13th, 2019 at 6:02pm JST (6 months, 8 days ago) comment permalink

Hi Jeffrey,

wow – that’s quite impressive that you have integrated my comment so quickly and released a new version. Thanks a lot!
Just one more question: do I have to do a new Publish of all files with that version now, so that it will be able to detect filename or folder changes in the future?

Thanks, Elmar
(from Austria, since you asked)

Performing the scan the first time will accomplish the same thing, while it marks to republish items that it thinks might have had filename changes. —Jeffrey

— comment by Elmar on May 14th, 2019 at 10:35pm JST (6 months, 7 days ago) comment permalink

I’m very happy to learn about detecting filename changes. I was bothered by that as well, but was assuming it’s not possible to do this given Lightroom limitations. Very happy, thanks!

— comment by Iustin Pop on May 30th, 2019 at 4:19am JST (5 months, 23 days ago) comment permalink

Hi Jeffrey,

Using latest version of this plugin (20190514.99) I see some pictures being exported with some directories missing. E.g. instead of final path being drive:\a\b\c\d\e.jpg, it will be drive:\d\e.jpg. However, only some pictures get this “treatment”.

I can confirm that editing the smart collection, the preview shows the path simplified, even though leading path components/trailing path components and overall depth limit are all set to none.

If I quit Lightroom and then restart it, the bug dissapears. And it seems related to pictures that have been renamed, or that are no longer part of a stack.

Does this all ring a bell?

Not at all, unfortunately. If you can identify a specific failure before restarting Lightroom, send a plugin log with specific info about it (which image, exactly when where, exactly, and where you thought it should go, exactly). Thanks. —Jeffrey

— comment by Iustin Pop on May 30th, 2019 at 7:33am JST (5 months, 23 days ago) comment permalink

From the UK

I like Folder publisher a lot but what it doesn’t seem to handle is when I have new folders created as a result of importing new pictures, it doesn’t pick them up. So I have Dave’s Pictures\2015, … Dave’s Pictures\2018 (with subfolders). Which I published using Folder Publisher. Now I’ve got some pix from 2019 which I imported into LR so I now have a new subfolder under Dave’s Pictures called 2019 (and subfolders thereof). Surely FolderPublisher ought to detect that (as after all I selected “Dave’s Pictures” as the thing I wanted published …

Cheers and thanks for the plugin

I’m not sure what you mean, by “I selected ‘Dave’s Pictures’ as the thing I wanted published”. Any Lightroom Publish Service, including Folder Publisher, includes one or more collections of photos that are populated either by you dragging specific photos into them, or via smart-collection rules that are computed on the fly. Whatever photos are there, however they get there, is what the plugin works with during a Publish operation, and the folders that those master images are in are what’s replicated at the Publish target. If you import new photos, and they’re not included via one of smart collections you set up in the publish service, you have to manually drag them in. —Jeffrey

— comment by David Partridge on June 8th, 2019 at 2:03am JST (5 months, 14 days ago) comment permalink

Just recently updated to the latest folder publisher plugin and I am having something happen that I’ve never experienced before. As my photos are publishing they are sending copies to C:\Users\rob\AppData\Local\Temp. The problem is as the temp folder fills up my computer eventually runs out of storage and the lightroom process shuts down. Then I have to delete all the temp files and start the publisher process from where it failed. In all my years of using Folder Publisher I’ve never had this happen. Any idea what might be available for a solution.

Lightroom has a mechanism specifically meant to stop a publish operation from doing that, but it becomes disabled if the plugin takes “too long” to process files. The plugin normally should be very quick, as it’s just moving files around, but if you have some other plugins as part of the publish stack, and they take a long time, then perhaps this is enough to trigger things? —Jeffrey

— comment by Robert Norman on June 12th, 2019 at 8:16am JST (5 months, 10 days ago) comment permalink

Hi Jeffrey,

I have been using Folder Publisher for about 7 years in my old LR 4.4.
Somehow today it told me that I have to register and will continue working with limited functionality.

I am pretty sure I registered years ago, but cannot find the registration code.
What do you recommend, should I (re-)register or is there a way to retrieve my code again?

Best regards

You can easily create a new code with a one-cent transaction, but my worry is why did the registration disappear to begin with. I worry that your Lightroom preferences file has started to go corrupt… please see this FAQ if it disappears again. —Jeffrey

— comment by Georg on June 23rd, 2019 at 9:04pm JST (4 months, 28 days ago) comment permalink

Hi Jeffrey,
Am I correct in understanding that this plugin doesn’t work as an Export plugin, which is to say I can’t use it when I click the Export button to export photos as JPGs?

Assuming so, do you have any plans to introduce an export plugin that provides this functionality, ie. the ability to export the photos to a chosen destination using the same folder hierarchy as that of the Lightroom catalog? I would find such a plugin to be absolutely invaluable!


You are correct… it supports only Publish, and there are currently no plans to extend it to Export. What’s your use case for this functionality in Export… how do you see it being used? —Jeffrey

— comment by Jeremy on July 18th, 2019 at 1:11am JST (4 months, 4 days ago) comment permalink

First of all, thanks for great plugin. Just started using it and that’s exactly what I wanted.
Have bug report, and I wonder if it is correct place for it.
When I’m publishing videos, creation date being lost.
I have .mov that have capture date/time set, but the resulting .mp4 file has “media create date”
set to date of the publish. Checked it with exiftool, no field with correct date.
Can you please have a look at that?
If needed, I can send the video file, but it seems that it will happen to any video.
Thank you!

Video dates are a minefield in Lightroom, and it’s not necessarily easy to even get the proper video date. But for what it’s worth, my Metadata Wrangler has an option to try to set the image/video date in exported copies to the capture date known to Lightroom. I’ve recently tested this on videos, and it seems to work. You could add that into the Publish pipeline. —Jeffrey

— comment by Roman Viskin on July 20th, 2019 at 12:31am JST (4 months, 2 days ago) comment permalink

Hi Jeffrey,

I’m trying the new functionality to scan for filename and folder changes but after a long time progress bar I get the following error:

jutil:1958: bad argument #2 to ‘?’ (number expected, got string)

Any hints?


Normally I’d ask you to send a log after encountering the problem, but in this case I was actually able to track down the problem and push out a fixed version. Thanks for the report. —Jeffrey

— comment by silviu on July 31st, 2019 at 3:05pm JST (3 months, 21 days ago) comment permalink

Yes, it’s fixed !

— comment by silviu on August 2nd, 2019 at 7:39pm JST (3 months, 19 days ago) comment permalink

I can’t see how you don’t understand – I store all my pix under D:\Dave’s Pictures\

That’s arranged by date with subfolders per year.

so .\2016\etc, .\2017\etc …

So lets say at the end of 2018 I used jFolder Publisher to export all pix under D:\Dave’s Pictures\ – all’s well. Now it is 2019 and I have a new set of images stored at D:\Dave’s Pictures\2019 and subfolders:

D:\Dave’s Pictures\2019>dir /ad
Volume in drive D is Data
Volume Serial Number is 2892-0083

Directory of D:\Dave’s Pictures\2019

13/08/2019 11:44 .
13/08/2019 11:44 ..
22/04/2019 09:35 04-21 River Wear
16/05/2019 19:02 05-14 Hastings
16/05/2019 19:02 05-15 Rye
07/06/2019 21:25 05-16 Richborough Saxon Shore Fort
16/05/2019 18:56 05-16 Sandwich
18/05/2019 10:13 05-17 Great Dixter, Northiam
19/05/2019 09:36 05-18 Rye, Bodiam
05/06/2019 16:56 05-19 Dungeness, Romney Hythe & Dymchurch Railway
05/08/2019 02:41 08-04
13/08/2019 12:33 08-05
13/08/2019 12:33 08-07
13/08/2019 13:33 08-08
13/08/2019 12:59 08-09
0 File(s) 0 bytes
15 Dir(s) 438,295,867,392 bytes free

All I’m asking is that folder publisher auto-detect the new subfolders and publish those as well, rather than needing me to delete the collection and recreate it.

As I replied before, the plugin doesn’t choose which photos are in its publish service collections. You specify what photos are there, either explicitly by dragging photos from the grid into the collection, or implicitly by writing smart-collection rules that identify the photos you want to be included. If you want those 2019 photos to be handled, you have to (yourself, somehow) get them into Lightroom, and then you have to (yourself, somehow) get them into one of the collections in the publish service. For example, if you have a non-smart publish collection, just select and drag-n-drop them all into that collection. In any case, only once they’re there can the plugin actually work with them. If you want the plugin to work with all photos all the time, consider a smart collection with a rule along the lines of “date later than 1900”. —Jeffrey

— comment by David Partridge on August 14th, 2019 at 1:11am JST (3 months, 8 days ago) comment permalink

I’ve been using your plug-in since LR 6. This time I decided to upgrade to LR classic while maintaining LR 6.
I’ll register your plug-in too but wonder what will happen if I register folder-publisher in LR classic.
Will it invalidate registration info of LR 6? If so how can I safely register folder-publisher in LR classic while having all previous settings untouched?
I want to use both copies.

It’s no problem to use plugins in both, and if the Lr8 install copies over your Lr6 preferences, it should even already be installed. You’ll need a separate registration code if you want them registered, but it takes just 1 cent to generate one, so hopefully it’s not such a hassle. —Jeffrey

— comment by SY Kwon on August 30th, 2019 at 4:12pm JST (2 months, 22 days ago) comment permalink

Hi Jeffrey,
I installed, registered and succesfully used your plugin with several folder hierarchies (in the range of thousand photos each) I had to replicate: everything went well and the processing time was reasonable (I dont’rimember long waiting times). Now I’m trying to replicate the process with another hierarchy (1200 photos) and Lightroom is stuck showing the message “Update of published collections” (I’m translating the message from the Italian version so I’m not sure about wording). I left Lightroom working overnight but nothing seems changed. I tried to leave videos out, still no results. I set up the plugin to leave file format (both photos and videos) as the Original but nothing apparently has changed. Any clue? I tried to investigate before getting in touch with you but I’m a Lightroom rookie so maybe there is something silly I’m not taking into account. Thanks for any support

My first guess would have been that a big video was being encoded, but if you’re sure you left videos out, that can’t be it. Perhaps send a plugin log after it’s been stuck for 10 minutes or so, and maybe that’ll have a clue. —Jeffrey

— comment by Ludovico Diaz on September 7th, 2019 at 4:47pm JST (2 months, 14 days ago) comment permalink


Sorry to pester you again, need a bit of advice on Folder Publisher.

1. I need to republish everything that has been republished already

Why – well it seems that MS OneDrive is not well behaved when it comes to Keywords (Tags in their vocabulary). Leave the image itself unchanged but alter the keywords on a file you have already uploaded.
A. If you are lucky then it uploads the file and does nothing else. Not even change the keywords listed on the browser interface so what is shown is not what is stored
B. If you are unlucky then it uploads the file, does nothing per A; but then downloads a version of the file with a copy of the original keywords – restoring any you have removed and deleting any you have added

Consequence is that my published copies bear little resemblance to the originals even though everything has been published/republished !!

I’m thinking that I could just hack the LR table and remove any rows with a publish count greater than 1 but I’m not sure whether I’d then end up with two copies of the published file

2. Is there any way of spotting that keyword synonym has changed and the image needs republishing?

Why – I realised that I’ve not been entering them correctly and am in the process of doing it properly. My manual process of using the filter and marking the resultant image for re-publish seems flimsy; one false mouse click yesterday and I marked 28,000 images to be republished !!

Kind regards
Steve Leggett

I’m afraid that I don’t have any good ideas. There’s no publish count, nor info on keywords at the time of publish, so no way to track what’s changed. Sorry. ;-( —Jeffrey

— comment by Steve Leggett on September 10th, 2019 at 4:06pm JST (2 months, 11 days ago) comment permalink

There is a column publishCount on table AgRemotePhoto (on which your data is also stored) that gets incremented every time an image is published. I could use this and remove the rows where the count is greater than one, feels safer just to remove everything and republish the whole lot.

Synonyms seem to have very limited support, e.g. although the keyword gets put in the xmp files, I can’t see the synonyms there, so moving an image between catalogs would require the catalogs to be coordinated. They do get shown on publish though, as separate keywords, but I can’t find a way to get these changes to trigger a publish, and there is no date data on the relevant table AgLibraryKeywordSynonym

If you manually edit Lightroom’s database out from under Lightroom, there’s a very good chance you will break things, as there are relationships among the data that are not necessarily readily apparent. It’s your data, so do what you like, but I won’t go anywhere near a catalog that’s been so modified. —Jeffrey

— comment by Steve Leggett on September 12th, 2019 at 4:46pm JST (2 months, 9 days ago) comment permalink

Question on publishing Video

I had this set as ‘Include Video Files’ – Original Unedited File. Although there is metadata in the catalog (Title, caption, keywords…), LR does not write the data back into the video file, or create a sidecar. Nor is it included on publish

I tried changing the format to h.264 on publish. Same result – no metadata in the file

So I assume there is no way to publish with this data.

Lightroom’s support for video metadata is pretty bad. Just looking at how it mishandles video dates during import is enough to drive one mad. —Jeffrey

— comment by Steve Leggett on September 12th, 2019 at 6:02pm JST (2 months, 9 days ago) comment permalink

Hi Jeffrey

I made a virtual copy of a photo and put both the original and the copy in a collection folder. When I published the folder using the 20190909.105 plugin version, only the original photo was published (but was given a “-2” filename suffix.) It used to be that both photos would be published, with the virtual copy taking the “-2” filename suffix, but now only one is published. Could you make it behave the way it used to be?

I would like to thank you once again for everything you do, I’m sure you’ve saved us all some 100,000 hours in aggregate


That “-2” is coming from Lightroom; I’ve no idea why it’s suddenly adding it to the first image published, instead of the second. I’d like to be able to suggest using {LibraryFilenam} in the plugin’s extended renaming, to let the plugin handle the “-2” and do so properly, but it seems a bit aggressive with multiple files in the same folder with the same name (as is the case with a virtual copy), so it doesn’t work correctly. I’ve been investigating this for some time, and have to be very careful about making any changes; it’s all really complex and I could easily break other things. So for the time being, I’m not sure what to suggest, beyond report it to Adobe. They can’t ignore your report until you submit it. 😉 —Jeffrey

— comment by CrisC on September 22nd, 2019 at 11:51pm JST (1 month, 29 days ago) comment permalink

My Lightroom Classic (latest) version with Folder Publisher seems to be stuck with a message “updating published collection”. Any suggestions?

Sorry, but that’s not much to go on. Is it during a Publish operation? Do you have some videos in there? (Lightroom can sometimes take very very long to process videos.) —Jeffrey

— comment by David on November 4th, 2019 at 8:39am JST (2 weeks, 4 days ago) comment permalink

Hi Jeffrey,
I hadn’t run the folder sync for a while. I was making a lot of changes to my catalogue. I create jpg copy of about 90,000 images on my NAS. Recently I decided to re-publish these files,but have run into a disk problem

The publish eats up my free space. I have about 80GB free on the drive with my catalogue (an SSD drive). After publishing about 5,000 images, LR stops publishing and I get a message that disk space is down to less than 20 MB.

Checking the drive, it is down to 20 MB. Once I stop the publish, all the space comes back.

I didn’t have this problem when I ran the publish 6 months ago. I don’t know if this is a LR 9 issue or a plug-in issue.

Thanks, … Jan

It sounds like a bug in Lightroom. The plugin doesn’t itself use any extra disk space, other than a minuscule amount used in the creation of the folders to hold the images. Lightroom creates the images and the plugin just moves them to where they need to go. Why it’s using 80GB of temporary space is beyond me. Worth reporting to Adobe, though it might be worth trying to replicate the problem with the built-in “Hard Drive” publish service, to take a third-party plugin out of the equation. —Jeffrey

— comment by Jan Schwarz on November 11th, 2019 at 1:27am JST (1 week, 4 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