Suffix image sizer option causes focus change to not generate new variation

[Toutouwai]

Short description of the issue

Normally every time the focus area for an image is changed in Page Edit a new variation is generated and visible on the front-end (browser cache may need to be cleared to see the changed variation).

This can be seen in these front-end screenshots before and after the focus area is changed (browser dev tools are open to disable caching).

<img src="<?= $page->image->size(200, 300)->url ?>" alt="">

But if a suffix is passed in as an image sizer option then the variation no longer updates after a focus change.

<img src="<?= $page->image->size(200, 300, ['suffix' => 'test'])->url ?>" alt="">

Expected behavior

Suffix has no impact on focus change generating new variation.

Optional: Suggestion for a possible fix

It would be great if the focus area was included (perhaps in an encoded form) as part of the variation file name so changing the focus area would reliably result in a new variation being loaded on the front-end regardless of suffix and would take care of cache-busting.

Setup/Environment

• ProcessWire version: 3.0.113

[ryancramerdesign]

When someone uses a suffix, the idea is that they've done so intentionally to create some kind of custom variation (via $options). At that point it's no longer managed by PW as an auto-generated variation, because it doesn't have the information necessary to re-create it.

[Toutouwai]

At that point it's no longer managed by PW as an auto-generated variation

I'm not sure what you mean by "auto-generated variation". I thought the admin thumbnail was the only variation automatically generated by PW. Other variations are created manually/deliberately by size() calls in template files, etc, possibly with various image sizer options passed in that are expected to affect the resulting variation.

I think that between this issue and the other one relating to changing the focus area there is a bug. Which part is the bug depends on what is supposed to happen if a user changes the focus area of an image.

Changing the focus area of an image could be treated in one of two ways:

1. The changed focus is an important change and should result in new variations being created and shown on the front-end. In which case unrelated image sizer options such as suffix shouldn't be a factor in whether this happens or not (there is already an image sizer option to ignore focus if that is desired). I'd prefer this option, but if the variation is to be regenerated as a result of a change in focus then it should be regenerated at the time it is requested by size(), where all the relevant image sizer options are known. At the moment it seems that PW is recreating (some) variations at the time the focus is changed, but I don't see how that is going to work well because PW cannot know the relevant image sizer options at that time.

2. The changed focus is not an important change and new variations do not need to be created if a variation at that size already exists. In which case the situation described in the other issue shouldn't occur. I think this option would be confusing for site editors, because if they are experimenting with the focus area to achieve a particular crop framing on the front-end then they need/expect to see those changes on the front-end.

It seems like going with option 1 would be simplified if the focus data is reflected in the variation filename. Then a change in focus automatically results in a new variation, which I think is what users and devs expect. And it takes care of cache-busting on the front-end too. As I've mentioned in an earlier request, I think it would be good to make it configurable to include more of the image sizer options that have affected a variation in the variation's filename. This could be done via $config settings, but maybe a config screen would be nicer:

That screenshot is from an unreleased custom module but I think it would be better to include at least some of this in the core.

[Toutouwai]

This issue is related: #702 (closed to minimise the number of open issues in the repo)

[teppokoivula]

My comment from the now closed related issue, for reference:

When focus change in admin triggers variation recreation, this happens without knowledge of settings that the developer provided via code when first creating that variation, and as such may result in a very different outcome than what was originally intended.

For this reason I think that we should either store every setting available via code somewhere so that we can reuse them for that new variation, or alternatively we should not attempt to recreate variations and rather let the (developer defined) code perform that task – otherwise we will end up with unexpected results.

[knoedelsalat]

This also seems to be an issue when using "cropping" => "false" in image size options. If I use

$img_large = $image->size(1200, 1200, $options = [ 'cropping' => false ]

in a template, the image will be generated within 1200x1200 px limits without being cropped, working as expected.

Then, if the focus point is being changed afterwards, the image variation will be instantly recreated as a 1200x1200 cropped version. Then on page call the cropped version will be displayed. Gave me a bit of a headache last night :)

In this case I actually resorted to using a suffix to prevent PW from recreating my image variations for that particular template

[reminders]

@netcarver set a reminder for Mar 12th 2019

[ryancramerdesign]

@Toutouwai @teppokoivula You've both mentioned including every option in the filename at some point, and I think that would resolve what @knoedelsalat mentioned as well. However, I can't just introduce that because it would potentially wreak havoc on existing installations. What I could do though is make that behavior another option to the size() call, and/or a $config option, and/or make it enabled for new installations automatically. I'm thinking most probably don't need this, and it might also result in some pretty verbose filenames, but I think it'd be a useful option to have so long as one can choose to enable it or disable it.

[reminders]

@netcarver set a reminder for Mar 15th 2019

[teppokoivula]

@ryancramerdesign, while I think that including every option in the filename would be a possible solution, I'd like to highlight one part from my comment:

... alternatively we should not attempt to recreate variations and rather let the (developer defined) code perform that task ...

What do you think about this – does it make any sense? Personally I think that this re-creation feature is a nice touch, but also not necessary – so unless there's an easy way to make it aware of all the options, it would be much better to simply disable it. I'm not sure if that's currently doable, but if not completely, at least we could provide a toggle for it, so that it's disabled by default in new setups.

If it was indeed configurable, it would be relatively safe to assume that if the developer has switched it on, they should be aware of potential side effects.

[Toutouwai]

I agree with @teppokoivula that regenerating variations at the time the focus is changed is not necessary - the variations should be recreated next time they are requested via a size() call.

I like the idea of a $config option to include more/all sizer options in a suffix to the variation name because as a general rule if I change any size() option I want to see that change reflected on the frontend. I already have my own solution for this (the module I mentioned above) but would welcome seeing it as an option in the core.

As for the filenames being overly verbose, my module produces a suffix like the one below which I don't think is excessively long:

frog.400x400-u0i1s1q90f1t420l710z0.jpg

That suffix would decode as:

• upscaling: false
• interlace: true
• sharpening: soft (I assigned an integer to represent each sharpening option)
• quality: 90
• use focus: true
• focus position top: 420
• focus position left: 710
• zoom: 0

[ryancramerdesign]

@Toutouwai Nice job with the module. I think this is good having this solution available as a module like this for the people that need it. If it turns out over time that the audience is significant then I'd suggest we copy your addVariationSuffix() method into Pageimage/Pageimages directly if you are open to it (enabled by another option or config('installed') date). Except that rather than using a selectable set of options to affect the suffix, it would just use any option that differs from a defined set of core defaults, or any in config('imageSizerOptions') that differs from those defaults.