Cms: Cannot delete matrix blocks

Created on 18 Mar 2020  Â·  4Comments  Â·  Source: craftcms/cms

Description

Upgraded to 3.4.10 and cannot delete Matrix blocks or fields inside matrix blocks. Flash message says it has but upon reload after save they appear again.

Reverted to 3.4.9 and working again

Steps to reproduce

  1. Delete Matrix block or block -> field and save field
  2. They are not deleted and remain in place

Additional info

I am not using project config

Most helpful comment

3.4.10.1 is out now with the fix for this.

All 4 comments

I have some additional info on this (or a workaround for now @john-henry) If you toggle the top-level "use values as keyword search" before saving, it'll take your changes I think I had it re-save earlier with a change to the top-level description fields too. Seems like it's just not watching for block-level field changes unless there's also a field-level change. HTH

Edit: it's not just deleting block fields that's broken, it's any editing, adding fields, editing existing fields and so on.

Edit: Additionally, if you have nested supertable fields and want to update those within the top level matrix, the same workaround is required as per the top level matrix block on the supertable-field level. Need to edit the instructions field or toggle the 'searchable' checkbox on both the top-level matrix field _and_ the block-level supertable field to save that too.

Probably the same cause/issue: I cannot add fields to matrix blocks in 3.4.10.
In 3.4.9 everything works fine. (I am using project.yaml config)

_edit:
If I add my new field to an existing matrix block on 3.4.9, I see that there are also many keys added in project.yaml for existing fields:

  • byteLimit
  • showUnpermittedFiles
  • showUnpermittedVolumes

Maybe the 3.4.10 version already expects these values?_

We’ve tracked this down to bc2cdab938d000c19d92883a0529cd4db1acc716 being the culprit, which is preventing field types’ afterSave() methods from getting called, which is where Matrix & Super Table do all their block type saving. We’ll get a hotfix out ASAP, but in the meantime, if you change any of the top-level field settings (Name, Handle, etc.) at the same time, then the block type settings will be saved as well.

3.4.10.1 is out now with the fix for this.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

davist11 picture davist11  Â·  3Comments

darylknight picture darylknight  Â·  3Comments

RitterKnightCreative picture RitterKnightCreative  Â·  3Comments

mccombs picture mccombs  Â·  3Comments

angrybrad picture angrybrad  Â·  3Comments