Clear description for link fallback SEO fields

For each model, I can provide the fields “Title field”, “Image preview field” and “Excerpt field”. These are used in the admin UI to control what fields are used to describe models. And also as fallback values for SEO. For “Title field” and “Image preview field” a link field can be given as a value.

When it comes to the admin UI, linked fields work well. For instance, the “Title field” from the linked model instance B will be used when “Title field” points to a linked field for model A.

When it comes to values used for SEO (title, description, image), link values do not work as well. Instead of using fields from the linked model instance, the ID of the model instance is used and an image doesn’t work at all. This doesn’t really support good SEO.

I assume this is intentional and a way to avoid a cascade of complexity that might follow otherwise. I can also see the argument that the content model should be designed in such a way that core data, such is often used for SEO, is included within the content model itself.

However, maybe this limitation could be highlighted in the UX? As of now it appears that a link value is supported for both the admin UI and SEO, but as far as I can tell, it’s not supported in the latter case.

This is a really minor ask and 50% of my motivation here is just to leave something behind that other people can find when they are trying to find details about how linked fields work as fallback values.

Hi @jaakko.jokinen,

Thanks for the detailed report!

Hmm, to be honest with you, I’m not really sure what the intended behavior is here either… I’ll check with the devs to see if this was on purpose. I actually didn’t even know you could use a linked record to serve as another model’s title/excerpt/image fields… you’re the first person to have mentioned it :sweat_smile:

It does seem like we should be consistent about it, though. If we’re going to follow that relationship in the UI (or not), the API should probably do the same, or it does get confusing like you said.

Thanks for bringing this up; I’ll check with them and let you know.

@jaakko.jokinen,

Thanks again for this report. I double-checked with the devs, and long story short, this current behavior is just a holdover from the past. We’ll be improving the SEO and preview fields in the near future, and this behavior will likely end up changing anyway. We’ll try to be more explicit then about how their respective inheritances work – the SEO inheritance rules won’t necessarily be the same as the preview field inheritance rules, but we’ll try to be clearer about that.

In the meantime, I think it would be safer to consider them separate even now, and to use the separate “SEO” field at the model level, or the global SEO settings, to set your fallbacks.