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 )


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

Hi Jeffrey

I’ve been using a number of your plugins here in London, UK for years and they’re great! I’ve just started using the Folder Publisher one and I’m having a problem though.

I have LR5.6 with a catalogue containing 560,000+ images all under one root folder on my disk. I’m trying to use your plugin to publish a lower resolution, JPEG only copy of the entire folder and I noticed things get very slow. I set up the plugin with a single smart collection that includes my entire catalogue (but excludes any images smaller than 250px). I have a fast PC with 32GB RAM, but I noticed that when “Preparing to Export”, LR was using 40GB of RAM with a working set of 30GB, which I suspect is leading to a lot of disk swaps which, even with my SSD, slows the export (and the PC) to a crawl.

It did seem to be working though, until about 23,000 images into the export when it failed with a “cannot move from C:\Users\xxx\Temp\blah-blah” error. My disk was nowhere near full, so it couldn’t be that the Temp file wasn’t created/copied.

I might try splitting up the catalogue into a set of collections in the publisher as a workaround, but this isn’t an ideal workflow for me, so any assistance would be appreciated.


The “preparing to Export” stuff is Lightroom itself, before it hands off control to the plugin. I can imagine that preparing info on half a million photos does take quite a bit of resources. You might consider selecting a group of images (try 10k to start) then then hold down the alt/option key to turn the [Publish] button into [Publish Selected], and then clicking that. As for the move failing, Windows gives no info to the plugin why it fails… the plugin just notices that the file is not where it was supposed to have been copied to, so it’s hard to speculate as to the reason. )-: —Jeffrey

— comment by Steve Insley on September 16th, 2014 at 7:02pm JST (1 year, 8 months ago) comment permalink

Hi Jeffrey,

Not sure if this helps or not but I figured out that if I get the moved fail error as shown below, I just filter by filename to quickly find the file in question, change one minor item within develop module (brightness, etc.), re-export and it doesn’t fail on that file again. On the surface there doesn’t appear to be any commonality for files that do fail to be transferred by Folder Publisher. However at least now there is a quick way to get past the files that cause issues.

“jf Folder Publisher”: Moved Failed:
returns unknown error

Jeff Wilkinson

— comment by Jeff Wilkinson on September 19th, 2014 at 12:33pm JST (1 year, 8 months ago) comment permalink

I currently use the folder publisher to export the images, I then use either FTP or rsync to copy them to my server. I have tried the FTP from within the Folder Publisher Manager, works about the same except I avoid opening another terminal window and is easier to see total progress.
Any chance for an enhanced version of the Folder Publisher which skips the step of writing to my local disk and just publishes on the server remotely?


No, sorry, though I believe there’s an FTP plugin available as part of the Lightroom plugin SDK. —Jeffrey

— comment by Timothy Spear on September 22nd, 2014 at 5:04am JST (1 year, 8 months ago) comment permalink


The Lightroom SDK sample is export only, and does not retain the folder structure. Oh well, I will just have to “waste” the space on my local machine.


— comment by Timothy Spear on September 22nd, 2014 at 6:40pm JST (1 year, 8 months ago) comment permalink

Hi Jeffrey

I resolve my earlier issue of large collection publishing by publishing in batches as you suggested. However, after while I have now noticed another odd behaviour that I think might be a bug.

As I mentioned, I have 560,000+ photos over thousands of folders. Inevitably, some of those photos have the same file name. I realised that when the file names are the same, the export process is suffixing a hyphen and number to the file name, even though the files are in different folders, hence not strictly duplicates. In some cases, I have as many as 60 photos with the exact same name in different folders, so I’m ending up with IMG_2043-60.jpg.

For clarity, I have only run the publish process once for each batch of photos by selecting 30K at a time and using Alt+Publish, so I doubt this is “re-publishing” logic error.

This is a problem for me as it’s imperative that ALL photos in the target publish folder have the identical name to the source. Please can you advise?


Lightroom is doing that because all exported copies go through a single (temporary) folder before being given to the plugin. You can get around it by having the plugin rename back to what you wanted, via the “Enhanced File Renaming” section of the plugin-settings dialog. In your case, if you want the exported copy to be named the same as the master image file (though with a different extension as needed), use {LibraryFilename} as your template. —Jeffrey

— comment by Steve Insley on October 20th, 2014 at 7:41am JST (1 year, 7 months ago) comment permalink

Hi Jeffrey,

Here is what I want to do. Will this plugin allow me to do this easily?

I have a very large lightroom catalog, with many years of folders organized by YYYY-MM (with subfolders for specific dates in each).

I have gone through and tagged a few thousand photos that are family photos, that I now want to export and publish to DVD(s) AND I want to retain the existing folder structure on the output DVDs for easy browsing by year, month (day subfolders).

This plugin looks like it will work, but, can it also write to DVD? How does it handle spanning multiple DVDs?

Thanks in advance!

The plugin will write to a disk on your system the way you want… you’d then have to (somehow) write the files to DVD. I suppose it’d be a manual process to break it up into individual discs. —Jeffrey

— comment by Amy on December 16th, 2014 at 12:10am JST (1 year, 5 months ago) comment permalink

Hi Jeffry, I’m a happy user of your Zenfolio plugin. Now I am wondering if your “folder publisher'” plug in will help with this task. I have duplicate copies of my raw files on three external drives as insurance against loss. The are organized in a YYYY-MM-DD hierarchy on every drive. The first drive is the drive on which my LR raw files are located. The other two drives have mirrored copies.

When I go from LR to edit a file in PSCC, I have PS create a tiff or psd. If I select all the newly created tiffs or psds in my catalogue after a day of working on them, can I use the plugin to export copies to the corresponding folders in my second and third external drives all at once? Hope this makes sense. It would certainly be a great convenience compared to making separate file copies and moving them to the corresponding location on my duplicate drives.

It can work… set up a publish service where the format is “Original” and use a smart collection to identify your PSDs. But realize that in a Lightroom export, “Original” actually has the very odd meaning of “original pixels; current metadata”, which makes little sense to me, but that’s what it is. Still, if your intention is to back up your originals, your best bet is to use a real backup solution so that the backup is complete and identical. —Jeffrey

— comment by Shirley Sanderson on December 29th, 2014 at 10:56am JST (1 year, 5 months ago) comment permalink

Hi Jeffrey,
First thanks for your nice job. I will try to use this plugin as a standard workflow for sharing pictures and video on a LAN NAS (qnap). Publishing video with the option “explicitly set the date/time …” to “The photo’s capture time” is not working (picture or video). It’s working on a local drive.

Unfortunately, I suspect you’re out of luck here. The plugin is launching a shell to launch a Perl script, which then tells your OS to update the time, but it seems that whatever filesystem driver is allowing the NAS to be seen on your OS doesn’t support the time-update thing. —Jeffrey

— comment by Thierry on January 21st, 2015 at 11:53pm JST (1 year, 4 months ago) comment permalink

Hey, great plug-in!
Having little problem – I need to export folders containing 72 photos each (for 360 innersphere photos), and when exported, these photos filenames should be from 1 to 72. When publishing one folder, everything is okay, but when exporting multiple folders, first’s filenames goes from 1 to 72, and the second folder goes from 73 to 144, which is not good for me.
How could I solve this?


The best I can suggest is to publish each folder’s worth of images at a time. Select them, then hold down the Alt/Option key… that turns the [Publish] button into [Publish Selected]. —Jeffrey

— comment by Saulius on January 28th, 2015 at 10:17pm JST (1 year, 4 months ago) comment permalink

Hi – do you plan to update for Lightroom 6. Very disappointed by Adobe when I opened my catalog in a new version and none of my old plugins work…

Versions of my plugins were ready for Lr6 since late last year. I suspect you haven’t kept up on updates. —Jeffrey

— comment by SM on May 12th, 2015 at 1:41am JST (1 year ago) comment permalink

I would like to Publish all jpg and video files “as-is” and only convert non-jpg images to jpg. Is this possible with your plugin or any other way you know about. Thanks.
You can do this if you use two separate Publish Services, one set to export JPGs with format “ORIGINAL” (the metadata is updated to match your Lightroom catalog, but the pixels are unchanged). —Jeffrey

— comment by JohnB on June 7th, 2015 at 9:36pm JST (11 months, 18 days ago) comment permalink

Hi Jeffrey.

I’m having a problem publishing with your Folder Publisher. I hope you can help.
I get an error pop-up titled “Can’t update this collection” with a message “Can’t move Z:\terry\Win7\AppData\Local\Temp\47260281-7F3A-… it doesn’t seem to exist”.

I’ve watched the temporary folder while it does this and; the folder gets created, the next image file get placed in the temp folder, then the folder gets deleted, then the error message pops up.

Any ideas? It’s very confusing.

Could you send a plugin log the next time you encounter this? Thanks. —Jeffrey

— comment by terry on June 13th, 2015 at 4:10pm JST (11 months, 12 days ago) comment permalink

Looks like there is an issue with video publishing tags.
I use dropbox, which read creationDate tag to sort video by time.
For some reason this tag is set to the time I run the publisher instead of being the capture time.
This is very anoying as all video are flagged as ‘Today’ in dropbox 🙁
Can you help?

Yeah, Lightroom’s handling of dates is buggy to begin with, and utterly pathetic for videos. I’ve just gone ahead and added a new option to my Metadata Wrangler plugin that allows you to set the date-related metadata fields. It’s at the very bottom of the plugin’s dialog section. (I’ve not updated the screenshot on its page yet) —Jeffrey

— comment by Julien on July 29th, 2015 at 12:17am JST (9 months, 28 days ago) comment permalink

Hi Jeffrey,
Not sure what I am doing wrong.
I downloaded your Folder Publisher plug-in and it shows up in the plug-in manager dialog. It also shows being enabled.
However when I try to Export (on one or more pictures), I can’t find nor select the Folder Publisher.

I run LR6 client version (no CC) on an iMac running Yosemite.
What to do?
Thanks for any suggestions.

It sounds like you’re looking in Export, as opposed to Publish. “Folder Publisher” is a Publish-only plugin. —Jeffrey

— comment by Chris on August 27th, 2015 at 3:07am JST (8 months, 30 days ago) comment permalink

Is there a way to use the folder publish plug-in to only publish select photos, like photos with 4 stars or more?

Sure, just use a Smart Collection with the criteria you want. &madsh;Jeffrey

— comment by Benjamin Wiles on August 28th, 2015 at 10:15am JST (8 months, 29 days ago) comment permalink


I do have the same problem that Adam described (March 26th):
>Hi and thank you for this great plugin!!!
>I have a question:
>How do I manage this (example):
>Source folder:
>Publish folder:
>When selecting D:\2_OUTPUT\ as publish folder I get:
>Thanks in advance!!!

(I think, Adam just forgot a few backslashes in the last line, which led to some confusion…).

So I want to omit “2_OUTPUT” at the beginning of the result folder, it should just be “D:\2_OUTPUT\2014\2014_03”

Is there a way to make the plugin working that way?

Sure, when you create a collection within the service (or, if you edit the default collection made), set the “Leading path components to strip” option to “1”.

And then I have a 2nd question: Is there an option NOT to update existing files in the target folder? That would be helpful for me, because I’m doing an rsync backup over the web and I do not want to have all the files updated (and gigabites of data re-distributed over the web)… I know, this is somehow against the philosophy of publishing services of LR… An option to include the folder publisher plugin in the export settings (like in the zenfolio plugin) would also help!

Thanks in advance,

If you don’t want to update images that have been changed in Lightroom since last published, I guess you just need to select them and “Mark as Up-to-Date” (in the context menu after making the selection within a Publish Collection). Or, if you never want to publish updates, just delete them from the publish collection after they’re first published. —Jeffrey

— comment by Bernhard on August 31st, 2015 at 6:13am JST (8 months, 26 days ago) comment permalink

I’ve discovered a very strange bug in the way Folder Publisher copes with Person keywords in Lr6/CC when you have either “Write Keywords as Lightroom Hierarchy” or “exportable keywords” checked in the plugin settings.

A photo with such a keyword on it will export successfully, but instead of moving to the Published Folders section, will remain in the Modified Photos section if it was previously published, or will move from New to Modified otherwise.

There are three ways to get a photo out of Modified and into Published:

1. If you remove the Person keyword, the photo jumps immediately from Modified to Published.

2. If you uncheck either of the two checkboxes in the Publisher settings, tell Lr to Leave As-Is, then republish, the published copy gets regenerated unnecessarily, after which the photo finally moves from Modified to Published. (All as explained by the warning text in that dialog.)

3. Right-click the photo and say “Mark as Up-To-Date”.

I’ve uploaded as simple a test case as I can construct: one catalog with one photo, which has two keywords: one normal keyword and one Person keyword. The photo is in the Modified state now, so if you tell the plugin to Publish, it will stubbornly refuse to move it out of Modified. If you remove the “man” keyword, same thing. Only if you do one of the three numbered things above will you get the photo to move to Published.

Yes, I am using the current version of both Lr CC and your plugin. 🙂

From Aztec, NM, USA

Lightroom’s understanding of what is and isn’t modified is riddled with bugs, and has been since day one, unfortunately. The bugs long predate people keywords so you’re probably seeing some side effect of whatever the true root of the bug is. Sadly, my requests to Adobe on this have not produced a fix. )-: —Jeffrey

— comment by Warren Young on September 9th, 2015 at 1:26pm JST (8 months, 17 days ago) comment permalink

Hello Jeffry,
I am facing one problem, when i edit image or change meta data, plugin detects it and shows edited photos as “pending for publish”.

But when i just move images within my original folder structure (just for photos housekeeping), plugin does not detect it and exported file ends up staying in old path. I expect it to move automatically to new path.

Is this limitation in plugin or I am doing something wrong?

It’s a limitation of Lightroom… it doesn’t consider the move something that triggers republish. We wish it did, of course, and I’ve placed requests for it, but so far to no avail. —Jeffrey

— comment by pm on September 9th, 2015 at 8:28pm JST (8 months, 16 days ago) comment permalink

Hi there. I want to “publish” all my photos (thousands of them) – how would I do this via collections? I can create a collection outside of your plug in by dragging the root folder into the collection panel. But I can’t do that by dragging to your publish panel. As I can’t reuse existing collections what is the best way to create a collection of all my photos? Many thanks!
PS The reason I wan’t to do this is to create a mirrored version of all my photos (~170,000) but resized and sharpened. Hoping to do this with your plugin!

It sounds like you need just one collection, a smart collection with a rule that includes everything. Lightroom doesn’t handle such a huge Publish operation well, so it’s better to break up the initial publish into chunks by selecting some photos (~10k~20k?) in the collection, then holding down the Alt/Option key, which turns the [Publish] button into [Publish Selected]. —Jeffrey

— comment by Oliver on November 5th, 2015 at 5:08am JST (6 months, 21 days ago) comment permalink

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 (6 months, 19 days 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 (6 months, 17 days 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 (6 months, 12 days 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 (6 months, 1 day 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 (5 months, 27 days 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 (4 months, 5 days 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 (2 months, 24 days 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 (2 months, 19 days 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 month 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 (3 weeks, 3 days 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 (2 weeks, 6 days ago) comment permalink
Leave a comment...

All comments are invisible to others until Jeffrey approves them.

Please mention what part of the world you're writing from, if you don't mind. It's always interesting to see where people are visiting from.

You can use basic HTML; be sure to close tags properly.

Subscribe without commenting