There are two problems related to views filters schema:
1. The current schema definition found in duet_date_picker.filter.schema.yml is never used
2. The schema for search_api_date filter is missing
The module alters the existing date filter plugins, instead of creating new ones in duet_date_picker_views_plugins_filter_alter which means that the schema defined in the duet_date_picker.filter.schema.yml file is intended for inexistent views filter plugin IDs.
- Install config_inspector module
- Add a view with a date filter while the duet_date_picker module is enabled
- Inspect the views configuration using config_inspector and observe the missing schema error(s)
1. Since we are not adding new plugin IDs, and we are only adding a property to existing types, we can use the hook_config_schema_info_alter hook to define the property "duet" for the 3 views filter plugins.
2. The hook makes the duet_date_picker.filter.schema.yml file not needed anymore, so we can delete it.
3. And finally, we need to run an update hook on existing views configs to convert the existing duet property from integer to boolean because the existing value is stored as integer until the schema is fixed.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
bbu23Comment #4
classiccut commentedThank you for this @bbu23. You're correct about the schema, and the schema_alter hook takes care of adding the use Duet property. I'm just doing some testing to make sure everything looks good. So far, the update hook works well in updating existing configs.
One thing I'm concerned about is that while the config in the DB gets updated correctly, any exported view config still has the old/bad config. If the DB update hook runs first, and subsequently a config import is done (as is the order of steps in drush deploy), the config gets reverted back to the old config. Though this is not an isolated issue, and any update hook that updates config will be susceptible to this problem. I'll be sure to note this on the release notes, and I guess site builders/maintainers will have to plan accordingly.
Thanks again for your help in developing this module.
Comment #5
bbu23Hi @classiccut,
I wouldn't worry about the order of the Drush commands. This is a standard procedure, and the people in charge of maintaining their websites are supposed to know and follow the recommended steps when updating the module. Using
drush deployin this context would be a mistake on their end.While it's not your responsibility to worry about that, I can see why you'd want to add an extra note in the release notes, which is nice.
Comment #7
classiccut commented