- Issue created by @justcaldwell
- 🇧🇷Brazil RenatoG Campinas
Definitely a good catch! Thanks for reporting that @justcaldwell
- 🇺🇸United States 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?
- 🇮🇳India pooja saraah Chennai
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.
- 🇺🇸United States justcaldwell
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.
- Merge request !31Issue #3419337- Prevent and remove invalid block_class dependencies. → (Open) created by justcaldwell
- Status changed to Needs review
4 months ago 5:06pm 27 February 2024 - 🇺🇸United States justcaldwell
Okay, seems the issue is:
- 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.
- Core's Block::preSave() method runs and calculates dependencies, creating the dependency on block_class based on the (possibly empty) settings above.
- 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.