|resize filename not functionning

Known Issues
#1

Hello!
this:
<img src="{{'assets/images/footer/EMS_Notre-Dame_Espaces-commun-Batiment.jpg'|theme|resize(800, 600, { filename: true }) }}" alt="plantamour" class="img-fluid">

returns me
<img src="//ndm.test:3000/resize/e21c21b8dbcdbaf4f70e4ec811f97afd-1" alt="plantamour" class="img-fluid">

shouldn’t it be the filename? Am I missing something?
OctoberCMS 3.6.22

#2

After a refresh it should be the correct filename :slight_smile:

1 Like
#3

You were right. a cache::clear did help.
But I still have a uuid after the name:
<img src="//localhost:3000/storage/app/resources/resize/392_207_0_0_crop/test_b8a8387d8c39ced1400668852dec1caf.jpg" alt="test" class="img-fluid">
Is it possible to have only the name?

#4

Yes, but not yet.

In the next version (v3.7) we will add a group option that will remove the uuid. A unique group should be specified to avoid naming collisions.

#5

Hi,

I know this is an old topic, but …
What if the image to be resized is to be used in a META tag?

I have this problem where the resize endpoint url is generated, but since it’s never actually rendered, the endpoint just stands there until the bot try to extracts the image from the meta tag. Then, the url changes to the final url but the sharing doesn’t work since the harvested url is now invalid.

Is there a way to automatically force the resizer to perform it’s work and generate a valid url without a first access?

[October 3.7.12]

#6

Hi @froberts0n

Interesting. Doesn’t the endpoint still redirect to the correct location?

Could you tell us more about the situation where you would use a meta tag image that is never rendered and access by a bot in the first instance? Usually we assume the developer would check their work, which would render it.

1 Like
#7

Hi @daft ,

Well, we have page for models of houses and every page has a hero image but it also has a meta tag for SEO (OpenGraph for Facebook sharing) which reads like this (not really but close enough):

<meta property="og:image"
      content="{{ page.meta_image|media|resize(1200,600) }}">

which then renders as

<meta property="og:image" 
      content="https://mysite.com/resize/45288a3973d410c888d08d73f5546474-1">

And this is what is picked up by the Facebook bot since I never went on and browsed to that endpoint. If I do browse explicitly to the endpoint, then yes, it changes to something like this:

<meta property="og:image" 
      content="https://mysite.com/storage/app/resources/resize/1200_630_0_0_auto/myfile_88a916067c859d5ffff7885f15a2325d.png">

But if the bot tries to access the first rendered link (that it cached), it gets a redirect which I don’t think it likes much. Most of the times, unless I refresh the bot’s scraping by hand, it just shows up blank in the social medias, which my client doesn’t like very much.

Of course, the fallback would be to have each SEO image of every pages preformatted correctly and specifically to the correct size beforehand, and not dynamically, and then put the media URL without the need for the resize filter. But I just though it was a nice thing to be able to dynamically setup what settings we wanted to use for SEO images from big hero images, and not having to manage extra files by hand.

That being said, it’s pretty transparent for all other use cases since the first time it is accessed, it switches url and caches it, witch is all good. It’s just for this particular (edge?) case that it seems to cause problems. Hence my question. :man_shrugging:

Does that explain it better?

#8

I understand better now, thank you. I think a { force: true } option may work here.

#9

Yep, I think it may. :slight_smile:

The doc could state the downsides of having the processing done immediately upon rendering the link the first time without any apparent benefit, but I think for special cases such as SEO links, which are stored before being visited, it would make sense.

Thanks a lot! :+1:

1 Like