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 Lr4 to Lr5, 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 )


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


I just finished testing your enhancement with folder depth limitation. It works exactly as expected and your warning messages are super clear.

Tx for the unbelievably quick enhancement … if only Adobe would react this way :-)


— comment by Xtof on April 11th, 2014 at 12:42am JST (1 year, 6 months ago) comment permalink

Thank you for this great plugin!

20140410.45 Added an option to limit the overall depth of the publish tree.

I cannot find this. Is there a trick? Thank you very much!

It’s on a per-collection basis, so it’s in the create/edit-collection dialog. —Jeffrey

— comment by GK on May 14th, 2014 at 8:04am JST (1 year, 5 months ago) comment permalink

Thank you, Jeffrey! Now I am really happy!!!

— comment by GK on May 14th, 2014 at 6:52pm JST (1 year, 5 months ago) comment permalink


Your plugin saved me countless hours of managing exports! Just one quick question: would it be possible to run an external application once publishing completes?

I have a .bat file that rsyncs all the exports to a NAS on my home network.

Writing from Sibiu, Romania.

Sure, you can do that with my run-any-command plugin. —Jeffrey

— comment by silviu on June 10th, 2014 at 6:40pm JST (1 year, 4 months ago) comment permalink


I hope I’m not reading it wrong but “run-any-command” appear to run an external command after each file is exported. What I’m looking for is running a command after completing “Publish” from “Folder Publisher”

I guess I could copy each file to the nas one-by-one but I feel is more efficient to sync the exports root folder once.

Anyways it’s not a big deal, sync-ing the nas manually takes one minute, I can spare it from the hours your plugin saved :)


The plugin can do both (execute something after each image, or after the entire export/publish operation). —Jeffrey

— comment by silviu on June 12th, 2014 at 3:09pm JST (1 year, 4 months ago) comment permalink


I have just discovered your plugin and have been testing with it for a bit now and am finding it very well thought out in its features and execution.

I do have one question. Does the plugin support removable storage? I want to use it to create JPEG backups of all my photos in case something happens to Lightroom. I want to do a full backup to an external hard drive, then continue to work without the drive attached, reattaching it occasionally to refresh the backup. Is this workflow supported?



Sure, that’s fine, just make sure the drive is attached whenever you publish. Otherwise, it shouldn’t matter. —Jeffrey

— comment by Mike on July 1st, 2014 at 10:03pm JST (1 year, 3 months ago) comment permalink

Hey Jeffery,

Ever see a problem where a publish will fail with “Can’t update this collection”?

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

The destination is a dropbox folder, my guess is that has something to do with it? Maybe dropbox can’t keep up and returns a “full” event or something. The drive is definitely not full.

Anyways, feature request here : have the plugin continue the export if there is one failed file. It seemed to be working up until that point. I’m curious if it’s one file or if it would have continued on.

Whatever the case, THANKS ! Love these plugins.

The inability for the plugin to move a file is usually a pretty catastrophic error (target disk full? No permission to write there?), so continuing is probably not the best course of action. I don’t know what dropbox is doing… perhaps it’s locking the file temporarily? Without more details it’s hard to tell. —Jeffrey

— comment by Max Baker on July 28th, 2014 at 3:00am JST (1 year, 2 months ago) comment permalink

Does Jf Folder/Collection Publisher support removable / network drives without loosing the linkage between published images and original images in case the removable/network drive is not present?

The page says “.. export copies of your Lightroom photos to local disk in a folder …”.

Based on comments and changelog I could assume it works, but just checking.

Superb plugin! I love it.

It should work fine, though all chaos may ensue if you invoke a Publish operation while the target disk is not connected. — Jeffrey

— comment by Jarno on July 28th, 2014 at 9:16pm JST (1 year, 2 months ago) comment permalink

Dear Jeffrey,

thanks for your plugin, it just sounded to be what I was looking for…. only that I don’t really get how it works:
I have set up the “jf Folder Publisher” and it shows up in “publishing services”.
And I have organised my images inside a windows folder structure in LR5.

But I can not pull a complete folder (or multiple) over from the folder structure in LR into the jf Folder publisher: it won’t allow me. It only allows me to pull over a selection of images.

Wasn’t that the whole idea of the plugin? What am I doing wrong?!

The idea is that whatever images you do bring in to appear in the plugin will get exported to a folder structure that parallels that of their originals. If you want all the photos in your library to appear in the plugin automatically, just create a smart collection that refers to all images. —Jeffrey

— comment by Jan on August 22nd, 2014 at 6:08am JST (1 year, 1 month ago) comment permalink

I sometimes get the same error as Max Baker on 7/28/14 mentions.

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

I notice it more on extremely large publishing runs with multiple thousands of files. Latest error was during a publish I was trying to setup to Google Photos which uses a folder on harddrive to sync similar to drop box. However I also sometimes get the error just publishing to a regular folder. Otherwise I love this plugin!!!

Is there something I can log or provide to figure out the issue? I know that there is plenty of space on drive. I’m running Windows 7, 64bit.

You can try sending a log when you encounter the error, but with Windows there’s very little insight into why a move failed, so frankly it’ll probably remain a mystery. )-: —Jeffrey

— comment by Jeff Wilkinson on August 22nd, 2014 at 2:30pm JST (1 year, 1 month ago) comment permalink

Hi Jeffrey

I have been really enjoying the plug in for a while now, what a difference it has made. I have the latest version of LR5 and the plug-in. Not sure what is going on but when i added some photos from a holiday and told LR to publish it just hangs. I have the small status bar at the top left that something is happening but the bar itself remains empty, as no progress/export is occurring. I haven’t made any changes so not sure what the issue is. Have you come across this before?

I’ve not seen this before, but when strange things start to happen in Lightroom I wonder whether Lightroom’s preferences file has started to go corrupt. Clearing it out often solves these things. But in this case it could be an issue with your disk(?) You might check out the plugin log for hints, or send it to me. —Jeffrey

— comment by Graeme on August 24th, 2014 at 5:25pm JST (1 year, 1 month ago) comment permalink

Awesome plugin. It works great and is what I needed to create a lower resolution version of our images in the existing organized folder structure on a NAS for the family to access.

One request if possible: When exporting videos, could you add the option to embed the poster frame in the exported video?

I have a Seagate Central NAS that does not create thumbnails for videos but will use the embedded thumbnail/poster frame if it exists. I have a cumbersome workaround using an action in mp3tag to embed the poster frame from a jpeg exported from the videos using another utility.

Unfortunately, that’s all up to Lightroom and it gives no insight to a plugin. I’d think their video export would do that, so perhaps file it with Adobe as a bug (or feature request). —Jeffrey

— comment by Tom on September 2nd, 2014 at 1:55am JST (1 year, 1 month ago) comment permalink

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 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 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 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 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 (11 months, 16 days 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 (9 months, 20 days 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 (9 months, 7 days 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 (8 months, 14 days 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 (8 months, 7 days 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 (4 months, 24 days 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 (3 months, 27 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 (3 months, 21 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 (2 months, 7 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 (1 month, 9 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 (1 month, 8 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 (1 month, 5 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 (3 weeks, 4 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 (3 weeks, 4 days ago) comment permalink
Leave a comment...

All comments are invisible to others until Jeffrey approves them.

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

You can use the following tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Subscribe without commenting