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.
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.
Edited to correct my assumption this is a blocking call; it isn't.
Edited to add ref to publishedPhoto:getPublishCount().