Welcome Dialog

Welcome to the Community!

We have a brand new look! Take a tour with us and explore the latest updates on Adobe Support Community.


Metadata handling with several publish service providers

Community Beginner ,
Nov 02, 2021 Nov 02, 2021

Copy link to clipboard

Copied

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.

TOPICS
SDK

Views

54

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Adobe Community Professional , Nov 04, 2021 Nov 04, 2021
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.... ?

Likes

Translate

Translate
LEGEND ,
Nov 02, 2021 Nov 02, 2021

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Nov 03, 2021 Nov 03, 2021

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Community Professional ,
Nov 02, 2021 Nov 02, 2021

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Nov 03, 2021 Nov 03, 2021

Copy link to clipboard

Copied

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:

image.png

(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....

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Community Professional ,
Nov 04, 2021 Nov 04, 2021

Copy link to clipboard

Copied

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.... ?

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Nov 04, 2021 Nov 04, 2021

Copy link to clipboard

Copied

LATEST

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.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines