First thought is whether the CSS of the site is affecting the rendered image size. For example, .summary-container img {max-width: 100px;} or similar.
Second thought is the exact rendering of images. Most I think now use <picture><source/><img/></picture>, but some of our older widgets still use simple <img>. Perhaps there’s some detail in the CSS rules where one approach is styled correctly, but this uses the other (somehow) which isn’t. (Seems unlikely in this case, but I don’t know your CSS.)
For the one argument, I think it is hide_date_header, going by documentation.
And hey Greg – one other possibility, is that an event coming from a linked calendar?
If it’s a linked calendar event with an external image (coming from the iCal ATTACH: entry) then widget settings aren’t able to change the size of that image, we just hot-link to whatever URL is referenced in the ATTACH: line.
Whoops, I didn’t see Karl’s response when I posted.
I don’t think it’s from a linked calendar, I’m pretty sure everything is coming from our LW events. And it does resize when I manually change it in the widget form.
Thanks Greg – feel free to paste or attach the current widget template here, if you can provide step-by-step instructions to reproduce, we can try it on our servers to help confirm if it may be a core LWC bug. Thanks!
Thanks, hm. When I save that to my own LWC server, I do see images being returned in the preview at 600x600.
(I also notice, you could remove <arg id="widget_template">featured</arg> from the widget template .xml file – that’s the line you use to call out to a widget template, and I don’t believe we support nested templates, so probably it’s best to avoid confusion by making it look like your WT might be calling out to another WT.)
Is it possible I might have changed something upstream accidentally? Any templates I should look at? I don’t think I touched core but maybe I did accidentally