silverstripe/silverstripe-elemental

`UploadField` inside inline-editable element doesn't update when saving parent record in a `GridFieldDetailForm`

Closed this issue · 10 comments

Module version(s) affected

5.1

Note: this worked in 4.13 but doesn't work in 5.0, so something broke in the major release.

Description

click to see original description I have a Elemental block, with a ElementalArea, so, so an ElementalArea inside another ElementalArea. If inline-editing a block on the 2nd level ElementalArea has an UploadField, on page save, the UploadField value doesn't update (nor any of the other fields). However, if you refresh the CMS the block editor re-renders with the updated information, so it's saving to the DB correctly.

This bug happens if you have a model being edited inside a GridFieldDetailForm (e.g. any model edited in a ModelAdmin), and it can have elemental blocks, and an inline-editable elemental block with an upload field inside that model's elemental area.

Any time you save the record using the "Save" button the gridfield detail form provides, it clears the upload field inside the elemental block, which makes it very difficult to save files in an upload field in this scenario.

Screen.Recording.2024-03-18.at.16.08.42.mov

How to reproduce

click to see original steps

Page with ElementalArea

Block with ElementalArea

class ArticleBlock extends BaseElement
{
    private static $table_name = 'ArticleBlock';
    private static $singular_name = 'Article block';

    private static $has_one = [
        'ElementalArea' => ElementalArea::class,
    ];

    private static $owns = [
        'ElementalArea',
    ];
}

Block with UploadField

class MediaWithCaptionBlock extends BaseElement
{
    private static $table_name = 'MediaWithCaptionBlock';
    private static $singular_name = 'Media with Caption block';

    private static $db = [
        'Caption' => 'HTMLText',
        'Setting_Alignment' => "Enum('left,right','left')",
        'Setting_ImageSize' => "Enum('small,medium,large','small')",
    ];

    private static $has_one = [
        'Image' => Image::class,
    ];

    private static $owns = [
        'Image',
    ];

    function getType()
    {
        return $this->i18n_singular_name();
    }
}

Have a model which can be edited inside a modeladmin. The model must have an elemental area:

<?php

namespace App\Model;

use DNADesign\Elemental\Extensions\ElementalAreasExtension;
use DNADesign\Elemental\Models\ElementalArea;
use SilverStripe\ORM\DataObject;

class MyModel extends DataObject
{
    private static $table_name = 'MyModel';

    private static $db = [
        'Title' => 'Varchar',
    ];

    private static $has_one = [
        'ElementalArea' => ElementalArea::class,
    ];

    private static $owns = [
        'ElementalArea',
    ];

    private static $extensions = [
        ElementalAreasExtension::class,
    ];
}

Add an elemental block with an upload field to the above record.

<?php

namespace App\Model;

use DNADesign\Elemental\Models\BaseElement;
use SilverStripe\Assets\Image;

class MediaWithCaptionBlock extends BaseElement
{
    private static $table_name = 'MediaWithCaptionBlock';

    private static $singular_name = 'Media with Caption block';

    private static $has_one = [
        'Image' => Image::class,
    ];

    private static $owns = [
        'Image',
    ];

    public function getType()
    {
        return $this->i18n_singular_name();
    }
}

Add an image to the upload field and save using the "save" button on the parent record (not the inline-editable save button)

Possible Solution

No response

Additional Context

Workarounds include using some other field type or always saving blocks using the inline-save button (and hoping nobody every needs to edit the parent record)

Validations

  • Check that there isn't already an issue that reports the same bug
  • Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)

PRs

Kitchen sink behat CI run with modules that might be affected by this change
NOTE There is one failure in that CI run - but it happens in kitchen sink even without the PR. It's not related to these changes.

Just to add, when using the individual block actions "save" button, this works correctly

image

It's a bit hard to tell from the description and the video is too zoomed in to tell - is this specifically related to nested inline-editable elemental blocks? i.e, editing an inline-editable block inside a block which is, also, inline-editable?

Marking as an enhancement - I don't think that's a use case that has been considered as supported so far.

There are quite a few existing issues (open and closed) referencing nested blocks (e.g. #775 / #824) and there's https://github.com/dnadesign/silverstripe-elemental-list too so I think it's probably used more than you think

#775 doesn't specify nested inline-editable blocks, and #824 ends with this:

Ah right, you can't inline edit inside another inline parent, but you can inline edit inside a non-inline parent. :)

ElementList is also explicitly not inline editable.

Nested blocks is one thing. Nested inline editable blocks inside other inline editable blocks is quite another.

Yes my page that contains the first element area isn’t inline editable, just the ArticleBlock that contains the nested Element Area is. So they’re not nested inline editable, but the nested elemental is if that makes sense? The rest of the blocks that don’t contain data relations (grid fields and upload fields) work fine inline editable.

In #824 @tractorcow did state “ Ah right, you can't inline edit inside another inline parent, but you can inline edit inside a non-inline parent. :)” which is what I’m doing here

Ahhh okay that changes things.

I've checked this - and also tried with a non-page model which has an ElementalArea (i.e. just a regular DataObject which is edited in a ModelAdmin and has ElementalArea) and it doesn't work there either, so it's more to do with the GridFieldDetailForm and nothing to do with nested elemental areas. Updating the issue to reflect this.

Just checked with previous versions - this worked in 4.13 but doesn't work in 5.0, so something broke in the major release.

Linked PRs have been merged. They will be released as part of CMS 5.3