Module creates invalid config dependencies

Definitely a good catch! Thanks for reporting that @justcaldwell

Glad to help. I don't have time to dig too deep, but it looks to me like line 358 of blockClassPreSave will always execute and save config, even if all block_class config is empty. Maybe that's where the dependency is created?

One approach to resolve this could be to add a condition before saving the configuration to check if any `block_class` settings are present. If not, we could skip the save operation to prevent unnecessary dependencies.

Agreed @pooja saraah, but it seems like the current code is already attempting to do that. At the top of BlockClassHelperService::blockClassPreSave(), each possible setting is checked and unset if empty. I'm not sure why that doesn't address the issue.

Okay, seems the issue is:

1. blockClassFormValidate() is setting ThirdPartySettings for block_class, even if the values are empty (e.g., no classes or id were set). This creates the potential for a dependency.
2. Core's Block::preSave() method runs and calculates dependencies, creating the dependency on block_class based on the (possibly empty) settings above.
3. blockClassPreSave() unsets any empty values (see #6), BUT it's executed by a hook after the preSave method, and the dependencies don't get recalculated.

We can either 1) refactor blockClassFormValidate() to avoid setting empty values, or 2) just recalculate the dependencies in the pre-save hook. The MR implements #2 as it's the simplest, and includes an update hook to remove any invalid values.

This wasn't an issue previously. I don't know what changed to make it start occurring now.

Updating IS.

This is still an issue in 4.x.

The fix proposed in the MR still works in 4.x. The MR will need a re-roll for the update hook.