block_classes_stored setting only retains classes from most recently saved block

Elevating to 'Major' since this does cause some data loss. If that last block saved has no classes configured at all, the store class list will be wiped entirely, causing autocomplete to fail, list of classes use will be blank, etc.

Hi @RenatoG. Hope you're well, too. I really appreciate all the new functionality in the 2.x branch!

Just to be clear, I was using "Click here to see all the classes..." as a quick way to confirm the bug. I didn't intend to imply the the classes for a specific block would be lost. Just that the data from previously saved classes might be wiped from block_classes_stored. I'm probably off base, but I consider loss of config data loss, too.

That said, gitlab still seems to be doing odd things, so a patch is attached. Cheers!

One related potential problem that just occurred to me: I don't currently see anything that prunes the list of stored classes to what is actually in use somewhere.

For example, say I add 'backgrind-blue' to a block and save it. I immediately realize my mistake, go back and change it to 'background-blue'. Both 'backgrind-blue' and 'background-blue' will continue to appear in the list of classes and in autocomplete results.

That would be it's own issue if it's a concern. Same is true for attributes.

An interesting side effect of this bug is causing a problem during config sync for us. Probably a bit of an edge case, but documenting here in case anyone else runs into this.

We use Configuration Split to (among other things) enable Masquerade and the block it provides in our dev/local environments only. There is no block class configured for the masquerade block.

When we migrated from Block Class 8x-1.x to 2.x, the update code nicely examined all our existing blocks, and populated block_classes_stored accordingly. The updated code and config was deployed to production, and all was good!

Now, though, when we attempt to import production config to a local environment, all appears to succeed, but actually block_class.settings is immediately out-of-sync. Subsequent config imports unexpectedly indicate that block_class.settings has updates to import. Exporting config reveals that block_classes_stored is now empty in the active config.

Essentially, when config is imported, the masquerade block becomes enabled, and blockClassPreSave() is invoked. Since the newly-enabled block has no block class, that empty value is saved to block_classes_stored, wiping it's previous class list, and making the active config immediately out-of-sync with the staged config.

The patch resolves the issue.

While testing the patch in the context of the issue I described in #9, I realized the current code is storing empty values. The attached patch addresses that.

The interdiff is next to useless—the change is essentially to wrap all the class processing in a conditional:

// Only process non-empty values.
if (!empty($block_classes)) {
  // class processing move here...
}

Hi @RenatoG! Looks like this change (as well as #3320583: attributes_inline setting only retains attributes from most recently saved block and #3320580: Attribute values are not processed if id is empty) didn't make it into 2.0.8? Do you have a timeline for a next release?

Thanks @RenatoG -- much appreciated!