Problem/Motivation
The module ships no default configuration. The gmap_polygon_field.settings config object does not exist until the settings form is saved for the first time, so the default values of the settings are hardcoded in ConfigService::get() and again as a fallback in the map script. It also means the settings form has to invalidate the config cache tag by hand, because core does not do it when a config object is created.
Proposed resolution
Add config/install/gmap_polygon_field.settings.yml with the defaults of all settings (the current hardcoded values, so nothing changes for existing maps).
Add a post update function that adds the missing keys to the existing configuration, without changing the stored values.
Read the settings directly from the configuration, remove the hardcoded defaults from ConfigService and the map script.
Use #config_target in the settings form (available since Drupal 10.3), which removes the custom submit handler and ConfigService::set().
API changes
ConfigService::set() is removed and ConfigService::get() no longer returns defaults for missing values.
Data model changes
The configuration gets all keys on install and by a post update on existing sites.
Issue fork gmap_polygon_field-3630644
Show commands
Start 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:
Comments
Comment #3
siva01 commented