Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

DOC Document always inline saving elements #542

Merged
merged 1 commit into from
Jul 24, 2024
Merged

DOC Document always inline saving elements #542

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions en/08_Changelogs/5.3.0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ title: 5.3.0 (unreleased)
- [Features and enhancements](#features-and-enhancements)
- [High-level API for converting files](#file-converter)
- [Improve customisability of rendered images](#image-rendering)
- [Validation for elemental content blocks when saving individual blocks](#elemental-validation)
- [Validation for inline-editable elemental blocks](#elemental-validation)
- [Define scaffolded form fields for relations to `DataObject` models](#scaffolded-relation-formfields)
- [Support for `JOIN` in SQL `UPDATE`](#sql-update-join)
- [Other new features](#other-new-features)
Expand Down Expand Up @@ -73,12 +73,14 @@ You can also choose to have different rendering logic for `HTMLEditorField` imag
- Add a `SilverStripe/Assets/Shortcodes/ImageShortcodeProvider_Image.ss` to your theme to control images added to an HTMLEditorField.
- Add a `DBFile_Image.ss` file to the root of your theme to control only images invoked in templates.

### Validation for inline-editable elemental content blocks {#elemental-validation}
### Validation for inline-editable elemental blocks {#elemental-validation}

Elemental content blocks now support validation when saving or publishing individual content blocks using the "three-dot" context menu in the top-right of the block.

Validation can be added to a content block using standard [Model Validation and Constraints](https://docs.silverstripe.org/en/5/developer_guides/model/validation/#validation-and-constraints) by implementing a [`DataObject::validate()`](api:SilverStripe\ORM\DataObject::validate()) method on a content block, or by using [Form Validation](https://docs.silverstripe.org/en/5/developer_guides/forms/validation/#form-validation) where there are several options available.

Elemental data is no longer sent when saving the parent `DataObject` (usually a `Page`) that contains an [`ElementalAreaField`](api:DNADesign\Elemental\Forms\ElementalAreaField). Instead, when saving the parent `DataObject`, all the child inline-editable elements that have unsaved changes are inline saved at the same time. This change was done to consolidate the saving process down to a single code path. The code that was previously used to process any element data sent with the parent data has been removed.

### Define scaffolded form fields for relations to `DataObject` models {#scaffolded-relation-formfields}

Most `DataObject` classes will rely on some amount of automatic scaffolding of form fields in their [`getCMSFields()`](api:SilverStripe\ORM\DataObject::getCMSFields()) implementations. However, it's common for modules to provide a specialised form field which is intended to always be used with a specific `DataObject` class. In those cases, even though you always want to use that form field with that class, you have to copy some boilerplate code from the module's documentation to set it up.
Expand Down
Loading