Migrate old configs to newest version automatically

[Copilot]

The 1.2.0→current refactor changed the notify config key from the flat chatguard.notify-user to the nested chatguard.notify.user. Since saveDefaultConfig() never overwrites an existing file, upgraded installs retained the old key. Bukkit's getBoolean() returns false for missing keys, silently suppressing all player notifications. Console logs were unaffected because that code path is unconditional.

Changes

• ConfigHelper: Added getBoolean(path, defaultValue) overload delegating to Bukkit's FileConfiguration.getBoolean(path, def).
• PixelChat: Added migrateConfig() called on startup that automatically migrates old config keys to the current format:
  • Detects the old chatguard.notify-user flat key, reads its actual value (preserving an explicit false), writes it to chatguard.notify.user, and removes the old key.
  • Sets chatguard.notify.admins: true as the default for the new key when absent from old configs.
  • Logs "Configuration migrated to the <version> format." (version read dynamically from the plugin descriptor) when any change is made.
• CHANGELOG.md: Added a 1.3.0 entry noting automatic config migration for upgraded installs.

# Old (1.2.0) config
chatguard:
  notify-user: true

# New (1.3.0) config — written automatically on first startup after upgrade
chatguard:
  notify:
    user: true
    admins: true

This approach correctly handles users who had explicitly set notify-user: false in their 1.2.0 config, and sets a reusable pattern for future config restructuring.

[ToothyDev]

@copilot So does this only apply for upgraded configs from 1.2.0 -> current? If so, do you think this is the best way to tackle this seemingly architectural problem, or should the way this stuff is handled change altogether? Or should there simply be a disclaimer in the changelog of 1.3.0 to make sure the config is changed or made to regenerate, and then changed appropriately? Pick what you think is best here and go ahead.

[Copilot]

@copilot So does this only apply for upgraded configs from 1.2.0 -> current? If so, do you think this is the best way to tackle this seemingly architectural problem, or should the way this stuff is ha...

The getBoolean(path, true) approach was a band-aid — it handled the missing key case but would silently override any user who had explicitly set notify-user: false in their 1.2.0 config, and it would need repeating every time a config key changes.

Went with proper config migration instead (commit 45b6e26). On startup, migrateConfig() in PixelChat.java:

1. Detects the old chatguard.notify-user flat key, reads its actual value (respecting false), writes it to chatguard.notify.user, and removes the old key.
2. Sets chatguard.notify.admins: true (the new 1.3.0 key) when absent from old configs.
3. Logs "Configuration migrated to the v1.3.0 format: notification settings updated." so admins know what changed.

The getBoolean(path, true) calls in ChatGuardHelper are reverted back to getBoolean(path) — the migration guarantees both keys are present before any listener reads them. This sets up a clean pattern for future config restructuring.

[ToothyDev]

Also add this as a changelog entry for 1.3.0 since this is a noteworthy addition

[Copilot]

Also add this as a changelog entry for 1.3.0 since this is a noteworthy addition

Added in b34664a under the 1.3.0 Changed section:

Automatic config migration on startup: upgraded installs from 1.2.0 will have their configuration keys silently updated to the current format (no manual edits required)