Separate OneupFlysystem and league/flysystem-bundle in the docs

[tacman]

I find the docs somewhat confusing regarding flysystem. My recommendation would be to document league/flysystem-bundle first, and have a separate page for OneUp. I used to use OneUp, but during some Symfony upgrade I switched because I couldn't get something to work. So I wouldn't even know how to document OneUp, I just really want to get it out of the way, the names are so similar it's difficult to cut and paste when they're on the same page.

Regarding theleague's bundle, version 3 had some substantial changes, we should document against that. In particular, visibility / privacy is handled differently.

[dbu]

both seem still to be actively maintained. https://symfony.com/bundles has no entry for flysystem directly (searching symfony for flysystem mainly finds LiipImagineBundle documentation :-) )

i agree to cleanup the documentation to only have examples with league/flysystem-bundle. i suggest we just put a note somewhere saying that we only depend on flysystem itself, and one can use whichever bundle one prefers to configure the flysystem services, but for simplicity we show examples for league/flysystem-bundle.

[tacman]

Can you reopen https://github.com/liip/LiipImagineBundle/issues/1500? Or should we have the discussion in this issue?

I'm trying to rewrite the documentation for flysystem-bundle, and am still stuck.

Is FlysystemResolver still necessary in v3 of this bundle, or is FlysystemResolverV2 sufficient?

[tacman]

Here's my first pass at it. The sad reality is that I don't understand resolvers, and the examples were always with OneUp (which is why I submitted #1500 ) . I should probably fix my own code first and then use it for the documentation.

Configuration

The value of filesystem_service must be a service id of class League\\Flysystem\\Filesystem. The service name depends on the naming scheme of the bundle. <-- this isn't clear to me.

# config/packages/flysystem.yaml
services:
    Aws\S3\S3Client:
        arguments:
            - version: '2006-03-01'
              credentials:
                  key: '%env(AWS_S3_ACCESS_ID)%'
                  secret: '%env(AWS_S3_ACCESS_SECRET)%'

flysystem:
    storages:
        storage.aws:
            adapter: 'aws'
            options:
                client: 'Aws\S3\S3Client'
                bucket: '%env(AWS_S3_BUCKET_NAME)%'
                prefix: '%env(S3_STORAGE_PREFIX)%'

        storage.local:
            adapter: 'local'
            options:
                directory: '%kernel.project_dir%/var/storage/uploads'

        storage_filesystem:
            adapter: 'lazy'
            options:
                source: '%env(APP_UPLOADS_SOURCE)%'

# config/packages/liip_imagine.yaml
liip_imagine:
    loaders:
        flysystem_loader:
            flysystem:
                # this comes from flysystem.yaml
                filesystem_service: uploads_filesystem

    # default loader to use for all filter sets
    data_loader: flysystem_loader

    resolvers:
            profile_photos:
                flysystem:
                    filesystem_service: uploads_filesystem
                    root_url:           "https://images.example.com"
                    cache_prefix:       media/cache
                    visibility:         !php/const:League\Flysystem\Visibility::PUBLIC

There are several configuration options available:

• root_url: must be a valid url to the target system the flysystem adapter points to. This is used to determine how the url should be generated upon request. Default value: null
• cache_prefix: this is used for the image path generation. This will be the prefix inside the given Flysystem. Default value: media/cache
• visibility: one of the two predefined flysystem visibility constants (Visibility::PUBLIC / Visibility::PRIVATE The visibility is applied, when the objects are stored on a flysystem filesystem. You will most probably want to leave the default or explicitly set public. Default value: public

[dbu]

lets keep the discussion here.

the note about the service name: oneup creates different service names than the league flysystem bundle. imo we should best have a working example with league and where we explain that this is a service defined by flysystem bundle we could maybe mention how it would be named when using the oneup bundle.