2 Replies Latest reply on Mar 13, 2011 7:54 AM by clvrmnky

    Access to plugin metadata from publish deletion callback

    clvrmnky Level 4

      I'm using publishServiceProvider.deletePhotosFromPublishedCollection() to hook into publish deletions and ran into a bit of a snag.  I'm also using photo:setPropertyForPlugin() to set plugin and LrPhoto specific metadata that I'd like to nil out on deletion, but I can't seem to grok getting the LrPhoto ref while in the deletion callback.


      Basically, given a set of plugin properties and a simple array of photoIds, I can't figure out how to clean up my metadata for a specific LrPhoto item.


      Any suggestions?

        • 1. Re: Access to plugin metadata from publish deletion callback
          johnrellis Most Valuable Participant

          Interesting -- publishServiceProvider.deletePhotosFromPublishedCollection()  doesn't provide the LrPublishedCollection from which the photos are being deleted.  Seems like a design oversight.

          Here's brute-force solution for creating a table on the fly that maps remote ids to LrPhotos for your publish service:


          - Get the plugin's LrPublishService via



          - Enumerate all LrPublishedCollections and LrPublishedCollectionSets in the service via publishService:getChildCollections() and :getChildCollectionSets().


          - Enumerate all the LrPublishedPhotos in the published collections via publishedCollection:getPublishedPhotos().


          - For each LrPublishedPhoto, call publishedPhoto:getPhoto() and :getRemoteId() to get the LrPhoto and remote id, which you can add to the table.



          1 person found this helpful
          • 2. Re: Access to plugin metadata from publish deletion callback
            clvrmnky Level 4

            I was trying to figure out what path to take to take to get something like this.  Thanks.


            Actually, since I might need to know if a photo is still in some other publish collection for the same service, this might be even more useful. Enumerating just the removed items [oh, there's publishedPhoto:getPublishCount()], and in a timely manner will be the real challenges. I almost want a parallel worker thread (if such a thing existed) that listens for deletions and removes the metadata on its own schedule.


            No worries though, I'll poke at this more closely later.


            Thanks again.


            Edited to correct my assumption this is a blocking call; it isn't.


            Edited to add ref to publishedPhoto:getPublishCount().