FEAT: Additional Shared Schema Features and Updates

[WolfGreyDev]

This pull request adds additional functionality to the Shared Schema system in Syncify, allowing Shared Schemas to be used within the settings_schema.json config file. This also includes updates to strengthen the integrity of override values within Shared Schemas with performance gains.

Key Changes

1. settings_schema.json can now use Shared Schemas

   • Now Shared Schemas can be used in the settings_schema.json config file. This allows us to reuse common settings and spreads. With this addition, the Shared Schema functionality can now be utilized throughout a theme, wherever a schema setting could be used.

   Note: The logic for this has been included in the same file as the section/block logic. This will probably need a refactor in the future, however, the whole Shared Schema logic is almost big enough to have it's own file/s.

2. Sidebar Settings are now available in Shared Schemas

   • While the application of this feature is very niche, we can now have a Shared Schema for sidebar settings such as header and paragraph.

   • These settings can have their content and info modified with overrides and are included in the wildcard logic.

3. Explicit property allowance for overrides

   • The previous iteration of the overrides had a basic list of properties that could be modified or expanded on with wildcards. This posed issues with settings that would contain properties that were not valid for that particular setting. This was exposed with the introduction of sidebar settings. For basic and specialized settings, this isn't too big of an issue, since Syncify already disposes of properties that don't match the type.

   • Now ANY override property values will be passed all the way to the final singleton and checked against the type. Any property that has been passed down that doesn't belong to that type will be discarded. This means the final iteration of the shared schema system, will only contain override values that are valid for it's type. In turn this give us a performance boost over the previous iteration.

   • Currently, the overrides will only process values that are of string type. This does not yet include the new visible_if property.

How To Test

1. Add a shared schema (singleton or spread) to the settings_schema.json and see a valid setting.

2. Create a shared schema with a paragraph type and you'll be able to override it's values using the _settings object.

3. Add any property to the _settings object. Unless it's a valid property for the type at the final node, it will be discarded.

Additional Notes

• As mentioned above, the Shared Schema functionality has grown considerably since I first started to play with it. It's probably close to a point where we could move this logic into it's own file. This would help clear some of the confusing aspects such as having json related logic mixed with the sections logic. However, to keep pushing along with the development, it will still sit mixed in with each other. If you agree that we should look at refactoring this into it's own file, I'd really like some guidance on how you'd want this structured. In the next pass or two, I'll be able to begin that task.

• I can update the tests, however, these are really simple to check without needing to update the test files.