CB helpers logic not great for compound objects

[dcnb]

Current Behavior

Currently, it looks at format, but then for mutiples and post cards we don't typically use those. I suggest changing the featured image logic either to look at something other than format? Maybe display_template or to see if there's a certain extension in the object_location field

Basically, if it's a pdf, mp3, or mp4, then you'd go to the image/small but otherwise you should use object_location

Steps To Reproduce

No response

Anything else?

No response

[evanwill]

For multiples and compound_objects the docs say they should have format or display_template at min, which makes sense for the metadata and works for the current logic which checks format or display_template.

The challenge with checking extensions is that a lot of API links don't have an extension in them, so you can't really confirm from the url what the thing is--so the logic as it is defaults to image_small (with is required to be an image), unless it can confirm (via user telling it via format or display_template) that the object_location is an image.

[evanwill]

@owikle agreed that multiples should have format or display_template, and that it is actually required in CB-GH to work--> In the docs I changes should have to must have format or display_template. I think I cleaned up the metadata examples where multiples had no format. I think that makes more sense anyway, and resolves this issue.

[dcnb]

So what if you select the objectid of the parent record of a compound object or multiple for the featured image? That seems like a common scenario, but it would drop the image_small in there. Requiring format is fine, but still think this logic needs to be adjusted for that use case specifically. I just tried this with the demo data, and the featured image is a small. Idid not express that in the initial "bug" report but this was what drove me to post initially. My thinking is that it if it checked display_template and sees "multiple" or "compound_object" then if there's an included "object_location" in the parent record it uses that, otherwise it uses the "object_location" of the first image, which can be determined by display_template or format ...

It gets rather complex here, so the other alternative, and maybe the easiest, is to indicate to folks that they should add a representative object_location as well, just as we have them do for the representative small and thumb?