[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).
• ConfigMigrationHelper (new utils class): Contains all config migration logic, keeping PixelChat.java uncluttered and making future migrations easy to add:
  • migrate() — public entry point; reads the stored config version key and skips all work if it already matches the running plugin version. Dispatches to per-version methods for any steps that apply to the detected version range.
  • migrateTo1_3_0() — private method handling the 1.2.0 → 1.3.0 changes: moves chatguard.notify-user (flat) to chatguard.notify.user (nested), preserving an explicit false; adds chatguard.notify.admins: true when absent.
  • isConfigVersionOlderThan() — private semver comparison helper; treats null/empty as older than any target and trailing .0 segments as equal (e.g. "1.3" == "1.3.0").
  • Logs "Configuration migrated to the <version> format." (version read dynamically from the plugin descriptor) when any change is made.
• PixelChat: Startup migration reduced to a single call: new ConfigMigrationHelper(this).migrate().
• 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, skips all migration work on already up-to-date installs, and establishes a clean, scalable pattern for future config restructuring — new migrations only require adding a migrateTo_X_Y_Z() method and a corresponding version guard in migrate().

[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)

[ToothyDev]

@copilot Split the entire migration logic into a seperate helper class, and in there, split the different version migrations into their own methods so it remains readable over time, and the main plugin file doesn't get cluttered

[Copilot]

@copilot Split the entire migration logic into a seperate helper class, and in there, split the different version migrations into their own methods so it remains readable over time, and the main plugi...

Done in 183f0fd. All migration logic now lives in utils/ConfigMigrationHelper.java:

• migrate() — public entry point; reads the stored config version, short-circuits if already up-to-date, and dispatches to version-specific methods
• migrateTo1_3_0() — private method handling the 1.2.0 → 1.3.0 key changes; returns true if anything was written
• isConfigVersionOlderThan() — private semver comparison helper

Future migrations just need a new migrateTo_X_Y_Z() method and a corresponding if (isConfigVersionOlderThan(...)) block in migrate(). PixelChat.java is now a single line: new ConfigMigrationHelper(this).migrate();