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

Hi Jeffrey,

I love your tool!! But one thing I miss (or cannot find it). Can I add paramters to the output path just like I do for filenames? I have a folder of pics I’d like to export in a sepearate folder per year and month like d:\output\{yyyy}\{month}\picture.jpg


It sounds like my Collection Publisher plugin is what you need. It lets you do exactly that. Folder Publisher (the plugin on this page) keeps the original folder structure. —Jeffrey

— comment by Lula on July 17th, 2016 at 9:59pm JST (1 year, 7 months ago) comment permalink

Hi Jeffrey,
I’ve just installed this plug-in to my LR CC install. I’m trying to set up the enhanced File Renaming section which will use the image title with a sequence number added to it.

I am entering the template “{Title}_{SequenceAppend=#}” (without the quotes obviously) but I get the error ‘Unknown token “SequenceAppend”‘. The same thing happens with ‘SequenceFirst’. What am I doing wrong – if anything?


Doncaster, UK

I’d guess you’re using an old version of the plugin, though you say you just installed it so I dunno. Just to make sure, perhaps delete the one you have and install the one I just put out (which adds some unrelated tokens)? —Jeffrey

— comment by REB on August 27th, 2016 at 9:36pm JST (1 year, 6 months ago) comment permalink


An update: If I remove the Sequence token, leaving just {Title}, I can save the the settings and publish a photo. I can then go back into the settings and it will accept the {SequenceAppend=#} token. It appears that you need to have at least one photograph in the publisher for the tokens to be valid (I also tried {FileSS} with the same results).


Doncaster, UK

Oh, okay thanks, I’ll have to look into that. —Jeffrey

— comment by REB on August 27th, 2016 at 10:04pm JST (1 year, 6 months ago) comment permalink


First off, awesome plug-ins!!!

Is it possible to have multiple publish services?

For example:
I have two NAS drives, on NAS_1, I want to sync everything. On NAS_2, I only want to sync photos that have a certain keyword.

Is this possible?

thank you,

Sure, as with any Publish Service, the context menu for its header includes “Create another…”. —Jeffrey

— comment by Curt Scott on September 27th, 2016 at 5:22am JST (1 year, 5 months ago) comment permalink

Am I wrong to think that this tool should be able to export edited images, i.e. the final version? I only seem to get my original unedited photos, but I need to copy them to my work computer which does not have lightroom. Is there a setting configuration I’m missing?



I’m guessing that you have the “Format” set to “Original”, which despite the obvious meaning, doesn’t actually mean “use the original format”, but rather, Adobe has inexplicably used this wording to mean “export the original pixels (with updated metadata)”. Set the “Format” to “JPEG” and you should be fine. —Jeffrey

— comment by Elizabeth on October 14th, 2016 at 1:52am JST (1 year, 4 months ago) comment permalink

OK, I’ve got the publish service setup.
And I have created a smart collection with 3 (match all) rules:
capture date after 1900-01-01
label color is not red
folder contains Lr5 originals
Everything seemed to be working fine because the plugin has published 15,086 photos for me. Great!
Recently I added a few photos to my Lightroom catalog. They meet the criteria for the smart collection, however, they are not being picked up as needing published. So, I went in and changed a few metadata fields that would trigger a republish and that worked.
Why aren’t “new” photos that are added to the catalog triggering a publish? – Mike

This is unrelated to the plugin (Lightroom handles all this), but I’d guess it could just take some time for Lightroom to calculate the membership of all the photos when there’s a change. This is not a satisfying answer, but it’s the best I can think of. —Jeffrey

— comment by Mike on November 5th, 2016 at 12:24pm JST (1 year, 3 months ago) comment permalink

It seems like Folder Publisher is ignoring one level of the root folder setting for some reason. It is publishing one level below where it has been, and no setting has changed on my part. The only way I have been able to fix it is by republishing EVERYTHING and there are lots of photos. Plus, it keeps happening. Any ideas? I can send you a screenshot.
Rather than a screenshot, please send a log that includes the publish one one photo (hold down the option/alt key to turn the [Publish] button into [Publish Selected]), and include a note with exact info about what happened and how it was different from what you wanted. In this case, “exact” means full paths. —Jeffrey

— comment by jm on November 19th, 2016 at 1:53am JST (1 year, 3 months ago) comment permalink

I have the Lightroom Publishing Manager “File Settings” section set as such:
Image format = JPEG
Color Space = sRGB
Quality = 100

I have some RAW images in my Lightroom catalog. These files are Panasonic “RW2” raw format.
Lightroom appears to have no problem working with these raw images.
When the plugin publishes these files I end up with RW2 files in my Publish Tree instead of JPGs.
Is there another setting that I’m missing that forces the export to convert the RW2 to JPG ?

It sounds like you’ve got the export “Format” set to “Original”, rather than “JPEG”. —Jeffrey

— comment by Mike on December 7th, 2016 at 7:38am JST (1 year, 2 months ago) comment permalink


Is there a limit to the number of photos I can publish using Folder Publisher run LR 5? I’m publishing about 6,000 photos, and halfway through everything just stopped. I had to quit LR. First time using this plugin, and now am concerned whether it will be OK with this number of files.

I theory it should be fine, but in practice, Lightroom can get bogged down with large Publish operations. 6,000 isn’t all that large, though. Still, perhaps select some smaller number (2,000?) in the to-be-published grid, then hold down the alt/option key to turn the [Publish] button into [Publish Selected], and publish that way. —Jeffrey

— comment by Broadway on January 14th, 2017 at 7:44am JST (1 year, 1 month ago) comment permalink


i installed the Jeffrey’s “Folder Publisher” Lightroom Plugin, but it stalls (blocks) all the time not publishing any new pictures anymore.

I have simply filter of rater one star or more.

There are also movies that are rated one star or more.

Any idea what the cause can be?


I’d guess that Lightroom is churning away rendering the movies. It does this silently, without offering any clue that it’s doing something, much less that there’s progress. (The best indication that this is happening is that your computer turns into a space heater.) You might try removing the movies, or using different export settings so that movies render more quickly…. —Jeffrey

— comment by Steven on February 12th, 2017 at 6:36pm JST (1 year ago) comment permalink

I’ve got this plugin to make previews of my collections, just to keep jpeg’s. But when you publish the folder, plugins thinks that some photos have been modified and you basically have to republish 50% your collection for the second time. For example, out of 4442 photos plugin thinks that 2688 photos have been modified, but they weren’t

This is a really frustrating bug in Lightroom that seems to come and go randomly. I’ve reported it to Adobe many times, to no apparent avail. The best I can suggest is after publishing, select everything that found its way to the “to be republished” section and then “Mark as Up to Date” in the right-click context menu. Or, consider this plugin that will do it for you. —Jeffrey

— comment by Joe on March 5th, 2017 at 8:49pm JST (11 months, 14 days ago) comment permalink

This is really a great plugin.

I do have one question:
I like to publish the pictures with 3 or more stars with a high JPG quality, and the others with only 50% to save space. Therefore, I set up two export publisher services, one with 50% and one with 95% quality. In Each service, I created a smart collection filtering by stars. When I now change the rating of one picture from 3 to 2 (or vice versa) and start the two sync services in the wrong order, the picture will be created by the service to which selection it belongs now and this picture will be deleted by the service, it belonged before later. As result, it is gone. One solution is to republish again. But this takes very long since I have about 70000 pictures in the library.
How can I avoid this problem?

About the only thing I can think of is to ensure the target files have different names between the two publish services. One way to do it would be to use the “Enhanced File Renaming” feature to prefix the star rating to the filename, e.g. via “{Rating}-{Filename}“. —Jeffrey

— comment by Claus on March 6th, 2017 at 4:54am JST (11 months, 13 days ago) comment permalink


at the end of the sync job, I am getting the error message that the collection can’t be updated. ‘Can’t move “C:\unser\..\appData\Local\XYZ.jpg.” it doesn’t seem to exist.

How can I fix it?

I’ve gotten a clue about this error lately… I bet among all the photos in the Publish Collection you have two with a filename that differs only in letter case (e.g. “xyz.jpg” in one folder, and “XYZ.JPG” in another). Lightroom screws up in this situation. I’ve reported the bug to Adobe. —Jeffrey

— comment by Claus on March 9th, 2017 at 10:28pm JST (11 months, 10 days ago) comment permalink

Hi, seems your plugin is what I need. I guess it is an advanced renaming I want but is this possible?

I want to copy images from original folderstructur to a simpler structure with renaming of folders at the same time.



\2016\12.24 – christmas\
\2017\01.14 – birthday\
\2017\02.21 – consert\

– Terje

— comment by Terje on April 14th, 2017 at 9:24am JST (10 months, 5 days ago) comment permalink


I found it and I have now donated and registered the plugin.

Smart plugin with sub-folder “{YYYY}\{MM}.{DD} – {FolderName:After=_}”

Work as I wanted. Excellent!

– Terje

— comment by Terje on April 15th, 2017 at 8:12am JST (10 months, 4 days ago) comment permalink

I really love your tools and appreciate the your work!
There is one thing I would love to get with the help of the folder-publisher:
I do concert photography and have a folder hierachy like “acts/act_name/date_event” on a network drive I mounted to my working laptop. I remove files from the catalog if I don’t need them to be in there anymore, to keep it clean and lightweight. On the local SSD, i want to store preview images for fast use on social media and so on. They should be in the same folder structure as the original photos, but with “LowRes JPG” and “Social JPG” folders in them so I have fast and easy access to my rendered images.
It would be really great to not only being able to *limit* the amount of folders included, but request *at least* two folders above the file (If existing, to not run above the drive root if something is weird) or specify a root folder from which all paths should go if the files are underneath it (That would be the “acts” folder in my case.
This way I could ensure all my files are always in the same structure without having to keep a placeholder file in my catalogue so the tool gets the right root path.
Best regards from Germany
Leonhard Kreissig

— comment by Leonhard Kreissig on June 2nd, 2017 at 6:49am JST (8 months, 17 days ago) comment permalink


I noticed that when I move pictures from a Lightroom folder into another (doesn’t matter if the new folder is also published or not), the published pictures at the old place are not deleted.



I think it’s an unfortunate choice, but Lightroom doesn’t allow “master image has moved” to be something that marks a published photo to be republished, so you have to do it manually. Right click on the photo (in the Publish Collection) and “Mark to Republish”. When you actually then invoke the publish operation, the plugin should delete the old published copy as it puts a new copy at the new location. —Jeffrey

— comment by Claus Tropitzsch on June 24th, 2017 at 9:00am JST (7 months, 25 days ago) comment permalink

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 (5 months, 25 days 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 (5 months, 25 days 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 (5 months, 19 days 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 (5 months, 9 days 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 (4 months, 12 days 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 (3 months, 16 days 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 (2 months, 26 days 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 (2 months, 9 days 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 (2 months, 8 days 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 (2 months, 5 days 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 (2 months 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 (3 weeks, 6 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 (1 week, 5 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