Image Overrides not working
Closed this issue · 4 comments
Hello,
I'm having a really hard time overriding images from my templates:
{% set asset = craft.assets().id(913624).one() %}
{% set seomate = {
meta: {
title: entry.title,
description: entry.introduction,
image: asset.url
}
} %}
return [
'defaultMeta' => [
'title' => ['globals.seoTitle'],
'description' => ['globals.seoDescription'],
'image' => ['globals.seoFallbackImage']
],
'defaultProfile' => 'standard',
'fieldProfiles' => [
'standard' => [
'title' => ['seoTitle', 'title'],
'description' => ['seoDescription'],
'image' => ['heroImage']
]
],
]
This setup results in no image being output at all. If I remove image: asset.url
then the globals.seoFallbackImage
works fine.
I've tried various alternatives to this (removing image from fieldProfiles
etc) but I just cannot get it to work for the life of me, so I'm reaching out for some help.x
Adding 'returnImageAsset' => true,
to my config seems to have resolved it.
Hi,
Although 'returnImageAsset' => true
fixed this, it's kinda coincidental and may lead to other issues. The main error here, is that you pass the url to the asset to SEOMate, and not the asset itself. The following should work:
{% set asset = craft.assets().id(913624).one() %}
{% set seomate = {
meta: {
title: entry.title,
description: entry.introduction,
image: asset
}
} %}
And then you need to set returnImageAsset
to false
again.
Thanks for the reply. How about in a case like this?
{% set seomate = {
meta: {
title: entry.title,
description: entry.introduction,
image: url('share/' ~ entry.type ~ '/' ~ entry.id ~ '.jpg')
}
} %}
I'm generating my share images on the fly, and they only show in this case with 'returnImageAsset' => true,
.
@shifuma It's possible to override SEOmate's config from your Twig template, in cases where it's necessary to have the returnImageAsset
setting set to true
:
{% set seomate = {
meta: {
title: entry.title,
description: entry.introduction,
image: url('share/' ~ entry.type ~ '/' ~ entry.id ~ '.jpg')
},
config: {
returnImageAsset: true
}
} %}
What @aelvan wrote above still applies though, and I wouldn't necessarily recommend using returnImageAsset
to solve your issue. A safer approach is probably creating a custom meta template.