Allow configuration of all ImageSharp options

[matthewcare]

Prerequisites

• I have added steps to test this contribution in the description below

This PR updates the ImageSharpMiddlewareOptions configuration so that all of the options are configurable.
Registering your own imaging options allows you to override or extend upon the default methods.

To test, create a new implementation of IAdditionalImagingOptions

In this example I'm verifying that the requesting browser supports webp, and remove the command if it doesn't. I extend the default options so that they can also be executed.

public class CustomAdditionalImagingOptions : AdditionalImagingOptions, IAdditionalImagingOptions
{
    public CustomAdditionalImagingOptions(IOptions<ImagingSettings> imagingSettings)
        : base(imagingSettings)
    {
    }

    public new Task OnParseCommandsAsync(ImageSharpMiddlewareOptions options, ImageCommandContext context)
    {
        context.Commands.TryGetValue("format", out var format);
        var acceptsWebP = context.Context.Request.GetTypedHeaders().Accept
            .Contains(new MediaTypeHeaderValue("image/webp"));

        if (string.Equals(format, "webp", StringComparison.InvariantCultureIgnoreCase) && !acceptsWebP)
        {
            context.Commands.Remove("format");
        }
        
        return base.OnParseCommandsAsync(options, context);
    }
}

In your startup class you set the default options like this

public void ConfigureServices(IServiceCollection services)
{
    services.AddUmbraco(_env, _config)
        .AddBackOffice()
        .AddWebsite()
        .AddComposers()
        .SetDefaultAdditionalImagingOptions<CustomAdditionalImagingOptions>()
        .Build();
}

Remember, when you're testing, your image might be cached.

[github-actions]

Hi there @matthewcare, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[ronaldbarendse]

Hi @matthewcare, although this does look really well written, we don't want to tightly couple with ImageSharp even more than we do now. Plus you can already add IConfigureOptions<ImageSharpMiddlewareOptions> implementations to the DI container or use Configure() calls to do the same:

public class ConfigureImageSharpMiddlewareOptionsComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
        => builder.Services.Configure<ImageSharpMiddlewareOptions>(options =>
        {
            // Capture existing task to not overwrite it
            var onParseCommandsAsync = options.OnParseCommandsAsync;
            options.OnParseCommandsAsync = async context =>
            {
                // Custom logic before

                await onParseCommandsAsync(context);

                // Custom logic after
            };
        });
}

[matthewcare]

Hi @ronaldbarendse
I was mainly building on your existing PR #12376
The coupling with ImageSharp is already quite tight in that regard, and so I figured extracting the more complex options to a separate interface would clean up the file somewhat.

I understand if this isn't desired though, feel free to close.

[ronaldbarendse]

The coupling with ImageSharp is already quite tight in that regard, and so I figured extracting the more complex options to a separate interface would clean up the file somewhat.

All the related interfaces currently don't use ImageSharp specific types, which this PR does introduce with IAdditionalImagingOptions and therefore tightly couples the abstractions to a specific implementation. We're looking into moving the ImageSharp implementations to a separate project/package in the future, which wouldn't be possible if we'd merge this. Combined with the fact you can already configure all ImageSharp options using the beforementioned method, I'll close this.