Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

relationships that refer to instances of File should default to UploadField in the CMSFields #8482

Closed
sunnysideup opened this issue Oct 16, 2018 · 5 comments

Comments

@sunnysideup
Copy link
Contributor

sunnysideup commented Oct 16, 2018

Affected Version

silverstripe/admin                1.2.1              SilverStripe admin interface
silverstripe/asset-admin          1.2.1              Asset management for the SilverStripe CMS
silverstripe/assets               1.2.1              SilverStripe Assets component
silverstripe/campaign-admin       1.2.1              SilverStripe campaign admin interface
silverstripe/cms                  4.2.1              The SilverStripe Content Management System
silverstripe/config               1.0.6              SilverStripe configuration based on YAML and class statics
silverstripe/errorpage            1.2.1              ErrorPage component for SilverStripe CMS
silverstripe/framework            4.2.1              The SilverStripe framework
silverstripe/graphql              2.0.1              GraphQL server for SilverStripe models and other data
silverstripe/recipe-cms           4.2.1              SilverStripe recipe for fully featured page and asset content editing
silverstripe/recipe-core          4.2.1              SilverStripe framework-only core recipe
silverstripe/recipe-plugin        1.3.0              Helper plugin to install SilverStripe recipes
silverstripe/reports              4.2.1              Reports module for SilverStripe CMS
silverstripe/siteconfig           4.2.1              Site wide settings administration.
silverstripe/vendor-plugin        1.3.3              Allows vendor modules to expose directories to the webroot
silverstripe/versioned            1.2.1              SilverStripe Versioned component

Description

When you add has_many / many_many Images then you get an unworkable gridfield rather than a perfect UploadField when you scaffold the CMS Fields.

@bergice
Copy link
Contributor

bergice commented Oct 23, 2018

It works if you write it like this:

    private static $many_many = array(
        'GalleryImages' => Image::class,
    );

    function getCMSFields() {

        $fields = parent::getCMSFields();

        $fields->addFieldToTab(
            'Root.Upload',
            $uploadField = new UploadField(
                $name = 'GalleryImages',
                $title = 'Upload one or more images (max 10 in total)'
            )
        );
        $uploadField->setAllowedMaxFileNumber(10);

        return $fields;
    }

But we should consider making the UploadField the default considering it is not possible to upload Images via the GridField.

@sunnysideup
Copy link
Contributor Author

Yeah - the key is that it just works out of the box without having to write your own getCMSFields, just like it does with Varchars, etc...

@kinglozzer
Copy link
Member

That works to the assumption that both assets (providing the file/image models) and asset-admin (providing the upload field) are installed. If only asset is installed, we can’t provide an upload field. If our form field scaffolding isn’t already extensible, this sounds like a good enough reason to add that functionality 👍

@robbieaverill
Copy link
Contributor

robbieaverill commented Jun 14, 2019

I've only had a very quick look at this, but I don't think the DBFile model has the ability to alter this behaviour. The fact that it's rendered by a GridField is initiated by DataObject::getCMSFields() which calls scaffoldFormFields() -> creates a FormScaffolder and passes fieldClasses as a param to it, which is where you can modify the default class that is rendered for a relationship.

Because it's a many many, it defaults to rendering as a GridField. You can adjust this on a per model basis like this:

# File: YourDataObject.php
public function scaffoldFormFields($_params = null)
{
    $_params['fieldClasses']['GalleryImages'] = UploadField::class;
    return parent::scaffoldFormFields($_params);
}

It's currently not possible to adjust this globally by the relationship's data model type. I'm not saying it shouldn't be changed to do so, but noting its current limitation.

As @kinglozzer noted, implementing support for this in core would require that we don't introduce any coupling - there isn't enough extensibility in this area at the moment, so we'd also need to add some extension points.

We may also consider adding a configuration API for relationship model types to default field classes for the form scaffolder - something like:

SilverStripe\Forms\FormScaffolder:
  default_relationship_field_classes:
    many_many:
      SilverStripe\Assets\File: SilverStripe\AssetAdmin\Forms\UploadField

If we went with the configuration approach then we could easily slot that into asset-admin and have it be safely decoupled.

@GuySartorelli
Copy link
Member

GuySartorelli commented Aug 7, 2024

This is done as part of silverstripe/.github#262

@GuySartorelli GuySartorelli closed this as not planned Won't fix, can't repro, duplicate, stale Aug 7, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

6 participants