Metadata handling with several publish service providers

[martinvb1]

Wrote a plugin to upload images from LR to WordPress and created a Publish Service Provider as a Plugin. This works. But now I wanted to use several 'instances' of this Publish Service Provider in LR to handle different websites with different WordPress installations.

The 'lightroom-plugin-metadata-handler' stores e.g. the WordPress-ID and other data. But that data is overwritten by the latest in use 'instances' of my Plugin. 

How to handle the Metadata for this approach? Any help welcome, hope the problem description is understandable. Thank's in advance.

[johnrellis]

I've never looked much and export and publish services.  But the section Remembering User Choices on page 59 of the SDK seems to address how to store key/values unique to each instance of the publish service.

[martinvb1]

I tried to find your hint in the 'Lightroom Classic SDK - Programmers Guide' from october 2021. Couldn't find anything about that topic. Page 59 ends with the chapter 'Remembering user choices'. Did you mean that? Maybe, I'm to stupid to understand it.

I just expected that with 'Create Another Publish Service via....' another table for metadata is generated. That is not the case. The metadata is identified by 'photo' and 'LrToolkitIdentifier'.

So, my poor solution as process is now:

(0. Backup your LR database)

1. Create a new directory in the directory where the plugin code resides.

2. Name this new dir to 'plugin2.lrdevplugin' or 'plugin2.lrplugin' or so.

3. Change in Info.lua the string for 'LrToolkitIdentifier' to something like 'com.plugin2.wordpress.....' different to the one in plugin1.

4. Load and activate the plugin in LR.

5. Define the settings for that copy of the plugin to your 2nd / 3rd / ... WordPress site.

6. Done.

7. To avoid confusion one might deactive the other plugins currently not in use. The metadata pane will be somehow overloaded.

[john beardsworth]

The WordPress ID would normally be stored as the Remote ID of the published photo, so not in a custom field which is a property of the photo.

[martinvb1]

Yes, you are right. Thank's for that reminder, maybe I have to come back to that.

But the WP-ID was just an example. Currently I'm storing the data shown in the screenshot below:

(List of posts using the image is still to be implemented)

And, when I started in march 2020 I couldn't handle the RemoteID, probably my knowledge was to low....

[john beardsworth · Accepted solution]

The remote ID and URL are the only built-in fields that are unique to the publish service instance.

catalog:setPropertyForPlugin( plugin, fieldId, value ) can store structured data if you add JSON encode/decode steps, but I don't really think I'd use it for something like this.

If you really need to record this data in the catalogue, maybe use a hierarchy of non-exporting keywords like PluginID / ServiceLocalID / PhotoRemoteID / Field / Values.... ?

[martinvb1]

Thank you very much. Very helpful information.

I skip now the requirement (stakeholder is me) to support several websites programatically. Too, much effort for me. If I need it at all, I will use my procedure from above. Not nice, I know.