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 6/CC (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 Lr5 to Lr6, 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 )


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

Hi Jeffry, I am using the Folder publisher regularly and it generally works fine for images. I am exporting to a Synology external drive, so have to keep refreshing the export address, as the plug in often fails to find the volume. However after “changing” the export address by navigating back to the Sinology volume folder and then clicking “visit” it works.

However, what doesn’t work is the video export. If I select convert to h.264, the plugin converts one video and then invariably freezes permanently. Is this a problem with the converter? I’ve tried exporting as “same file format”, which was more successful but it seems unable to export ‘MOV” format files. Any explanation or suggestions would be welcomed!

Lightroom handles all the encoding, just passing it off to the plugin once done, so I’d guess that either you’re not waiting long enough for it to complete (though “permanently” does sound like a long time), or a problem with Lightroom. What happens if you try the same export with a vanilla “Hard Disc” export? —Jeffrey

— comment by Steve Long on November 6th, 2015 at 8:59pm JST (1 year, 8 months ago) comment permalink

I had my laptop hard drive die so had to migrate over to an old desktop for the time being running Vista. I installed my Lightroom 4 and downloaded the folder publisher plugin version 20150831.74 however when I try to install it in Lightroom I get “An error occured while trying to load this plugin”. Is it maybe that this version of plugin is not supported with the old lightroom?

It should work. I don’t think there’s a limitation on which version of Lr4 can be used, but just in case make sure you’re using the latest version of Lr4 (4.4) via “Help > Check for Updates”. —Jeffrey

— comment by Robert Norman on November 9th, 2015 at 8:18am JST (1 year, 8 months ago) comment permalink

I have run into the same “MOVE” error many times when trying to export a large collection (4000+) images NEF+JPG’s… destination folder has plenty of disk space and the image files are not corrupt. In fact, the next time I hit publish – it exports that file and moves on like nothing happened. Sometimes it will run to completion.. other times, it fails on another image later on.

Very frustrating because I can’t just leave this running overnight… wake up to find only 5 images published instead of 3,000..!

Can you help please?? It is very frustrating because then I must restart the publish and LR takes about 20 minutes to just pass control off to the plugin before it starts exporting again (LR catalog is about 90,000 images.. published collection is about 46,000 thus far).

I am using your plug in because the normal LR export sucks and is slower than my old C64!! But – the crashing is making this whole process so much more difficult than it should be…. I just want to export my LR images to 90% JPG to a new disk so I can catalog them with IMatch….

yeah, the failed move error is quite a pain… the plugin is not given any insight into why the move might have failed. I figured out a way to have the publish operation continue… at the end, errors will be summarized. I just pushed out a new version of the plugin. Hopefully this makes better use of your overnights. By the way, to publish smaller chunks at a time, should you find it useful to do so, you can select a bunch of images and then hold the option/alt key down, and the [Publish] button becomes [Publish Selected]. —Jeffrey

— comment by Andy on November 14th, 2015 at 2:22am JST (1 year, 7 months ago) comment permalink

Hi, Jeffrey,
I think, your plugin makes things even more dificult for me. What’s the workflow to return to the status before? Probably LR’s export tool is sufficient for my purpose…
Simply going back in LR with deactivated Plugin is not enough. I can’t delete pictures from LR without the plugin. The “target” for export (external HDD) is actually disconnected…
Robert, Vienna

If you want to stop using the plugin, you can just delete the publish service (by right clicking on its header in the lower left of Library). You can then disable or remove it from the plugin manager, or leave it… if there are no publish services, it shouldn’t have any impact. —Jeffrey

— comment by Robert on November 24th, 2015 at 8:38pm JST (1 year, 7 months ago) comment permalink

Hi Heffry,

will it be possible to use dynamic watermarks during export, let me know explain my problem. LR watermarks positioning is static, and different photos might need watermark positioning in different corners. I use your folder publisher plugin to auto-export whole set periodically, but i face problem with photos which need watermark in different place. I export them manually specifying exact watermark to use.

In folder publisher plugin, instead of specifying fixed single watermark, will it be possible to pickup watermark name from image keyword / metadata. E.g. I can create 4 different watermarks for 4 corners, and specify which to use in image keyword/metadata. Folder publisher plugin can read this keyword and use similar named watermark, if watermark not found then it can use default one.

Unfortunately, no, Lightroom bakes the watermark into the exported copy before giving control over to the plugin. If the number of watermarks is not huge, you might consider a different publish service for each one. —Jeffrey

— comment by pman on November 28th, 2015 at 9:27pm JST (1 year, 7 months ago) comment permalink

Hi Jeffrey,

Awesome plugin, thanks.

I am using this to mirror my catalog in lower-res to a folder that also syncs to Google Drive (on OSX Yosemite, LR 6.3). This generally works well, but I’ve been noticing a bunch of stray duplicate files showing up in the sync folder, in the form IMG_0001(1) as a duplicate of IMG_0001. I think Google Sync sometimes creates these after I re-publish edited versions of previously-published photos.

Although this seems to be a Google issue, do you know of any way to “clean” the target folder structure of any extraneous files that may have shown up after publishing? That would be a good workaround to this issue. I could just delete the whole folder and re-publish, but it takes a lot of time (and upstream bandwidth) to re-sync to Google.

I don’t see an easy solution, sorry. If the plugin has to resolve conflicts it’ll do so with “-1”, “-2”, “-3″… endings, so the “(1)” endings that aren’t from the original filenames are likely spurious. —Jeffrey

— comment by DarthBrader on January 20th, 2016 at 10:29pm JST (1 year, 5 months ago) comment permalink

Have an issue with plugin – after source (raw) folders rename/move in LR, plugin does not get that info and no republish available for moved photos to be correctly placed into folders in publish directory.
Is there any way to republish moved photos, without republishing all or manually selecting such photos in publish plugin (may be hard to do).

Unfortunately, no, you have to manually mark the photos to be republished. I’ve asked Adobe to allow folder and filename changes to cause a republish, to no avail. —Jeffrey

— comment by Vladimir on March 2nd, 2016 at 5:43am JST (1 year, 4 months ago) comment permalink

Hello from Greece and congrats for the great work.
I just noticed that if you set a limit to the jpeg file size (say 1 MB) AND ask the plugin to include video files the plugin will fail to publish video files larger than the limit set (eg 1MB) complaining that the files are larger than that.
Video files should be excluded from the jpeg file size limit.

That “limit file size” stuff is all enforced by Lightroom prior to Lightroom handing the file over to the plugin, so there’s nothing I can do about it, unfortunately. Perhaps submit a bug report to Adobe, though they may consider it a “feature request”. —Jeffrey

— comment by Stepfen on March 7th, 2016 at 4:14am JST (1 year, 4 months ago) comment permalink

Hello from Calgary, Alberta, Canada.

Thanks to your very useful plugin I’m now able to free up gigs of room on my laptop by moving off thousands of raw images and leaving small jpegs in their place (with the same folder structure!).

This is breathing new life into my old laptop and is greatly appreciated!

— comment by Todd on April 26th, 2016 at 12:15pm JST (1 year, 2 months ago) comment permalink

Hello from Kent, England!

I have been using the plugin for many years and find it extremely useful. One thing that has me puzzled is that in a group of images, some of the output files have the addition of -1, -2 and so on in their name. So 2009-08-01 001.dng/2009-08-01 002.dng/2009-08-01 003.dng/2009-08-01 004.dng/2009-08-01 005.dng in Lightroom results in 2009-08-01 001-1.jpg/2009-08-01 002-1.jpg/2009-08-01 003.jpg/2009-08-01 004.jpg/2009-08-01 005-1.jpg following publishing. I have changed various setting in the publish settings with no success in removing the ‘-1’ in the filesnames of the examples given.

Do you have any idea how I can resolve? I don’t fancy manually renaming 600+ filenames (of a total of 60,000+)!


This happens in two situations: the first is if the name that Lightroom calculates (e.g. “2009-08-01 001.jpg”) already exists on disk where the plugin had intended to place it, so the plugin adds “-1” to the base name to keep from overwriting the other photo. Another case is if you have a publish operation that includes, say, “flower.psd” and “flower.dng”, both would result in “flower.jpg” so Lightroom itself adds “-1” to one of the JPG names to keep them from potentially colliding. (This would also apply if you have virtual copies and a file-naming template that doesn’t include the copy name or other unique component.) If they end up in different target folders, there’s no actual collision; Lightroom still adds the “-1”, but you can use the plugin’s extended-renaming section to get around it. —Jeffrey

— comment by Richard on May 1st, 2016 at 4:26pm JST (1 year, 2 months ago) comment permalink

Hi, greetings from london, UK
I want to publish images from 3 separate catalogs (with the same folder structure) into the same pre-existing folder structure.
catalog 1 has images from 2010 in folder structure 2010 – 01, 02, 03 – 1st – 10th, 10th – 20th, 20- 31st. etc
catalog 2 has different images, but still from 2010 , still in the same folder structure – 01, 02, 03 etc
catalog 3 has more image, again same folder structure.
each catalog has a different metadata template working on it, so cant combine the catalogs
Id like to publish each of the different catalogs to the same folder structure, so all the images from 2010 are in one master folder, but stil in the same structure (2010 – 01, 02, 03 – 1st- 10th, etc)
In total each catalog has approx 10,000 images.
Is this possible using this plugin?
Thank you for your help.

I’d think it should work, but your best bet to ensure it works exactly as you like is to test it under your specific conditions. —Jeffrey

— comment by Tim on May 5th, 2016 at 6:01pm JST (1 year, 2 months ago) comment permalink

Hi Jeffrey,

I’m trying to use the plugin to export my folder structure but for some strange reason I’m getting mixed results. My folder structure is as follows:

/Personal/Cities/New York/photo.nef
/Client Photos/Client X/Photo7.nef

When I set up the publisher I get mixed results. Some photos go the appropriate locations (i.e. Portfolio) but then the Personal folder doesn’t maintain the folder structure and reflects only “New York” or “Paris”… My take is the plugin is not handling correctly different depths in the folder structure so when it finds “Portfolio” without any subfolders it makes some assumption on the rest of the photos.

Could you help?


The plugin looks not only at the folder structure on disk, but how much is exposed in the “Folders” panel of the Library Module. If “Personal” is shown there, under which you’ll find “Cities” and “Friends”, then this should all (Personal + City/Friends) be maintained in the export. If, however, “Cities” is presented as a top-level folder in the Library Modules, that’s how it’ll be exported. If this doesn’t clarify it, perhaps send a plugin log the next time you encounter problems, being sure to give a specific example of a specific photo that ended up differently than you expected (being sure to give the exact path of both where it ended up and where you thought it should have). &madsh;Jeffrey

— comment by Jorge on June 4th, 2016 at 9:15pm JST (1 year ago) comment permalink

Lightroom CC 2015.6 fixes the issue I brought up on September 9th, 2015 above.

— comment by Warren Young on June 10th, 2016 at 8:39pm JST (1 year ago) comment permalink

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 (11 months, 8 days 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 (9 months, 29 days 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 (9 months, 29 days 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 (8 months, 28 days 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 (8 months, 12 days 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 (7 months, 20 days 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 (7 months, 7 days 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 (6 months, 18 days 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 (5 months, 11 days 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 (4 months, 13 days 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 (3 months, 20 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 (3 months, 19 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 (3 months, 16 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 (2 months, 11 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 (2 months, 10 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 (3 weeks, 2 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 (1 day, 7 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