v0.3.19

• No-op bump so sites already on v0.3.18 see a fresh update line. The v0.3.18 icon-injection fix now propagates on the next force-check.

v0.3.18

• Fix: plugin icon + banner now actually show on Dashboard → Updates and in the "View details" modal. The artwork has shipped inside the plugin ZIP since v0.3.14, but WordPress couldn't see it — PUC (the GitHub-update bridge) doesn't auto-discover assets/icon/* files. Added a puc_request_info_result-codeon-core filter that injects the icon + banner URLs into the update payload. Previous attempts (v0.3.15 / 16 / 17) were no-op version bumps that couldn't have fixed this — the URLs weren't in the response at all.

v0.3.17

• Third no-op bump so installs that already pulled v0.3.16 see a fresh update line on Dashboard → Updates. No code, asset, or config change.

v0.3.16

• Second no-op bump to flush WordPress's plugin-card cache. v0.3.15 didn't re-paint the icon on some sites because WP also caches the per-plugin transient that holds the icon URL — bumping the version a second time invalidates that secondary cache layer.

v0.3.15

• No-op release to flush WordPress's plugin-card cache so the refreshed v0.3.14 icon + banner artwork shows up immediately on every merchant's Dashboard → Updates and Add New screens instead of after WP's next scheduled metadata refresh.

v0.3.14

• New: refreshed plugin icon + banner artwork. Glyph is now a stylized "C" with the CodeOn brand-mark dot inside its opening — reads as "the canonical CodeOn plugin" instead of the previous location-pin (which was misleading: CodeOn Core is the free hub for the whole plugin family, Georgian Locations is one feature among several planned). Family-consistent: deep-blue gradient + CodeOn corner mark held invariant per CODEON_PLUGIN_ICON_SYSTEM.md.
• Update: banner subtitle now reads "The canonical hub for the CodeOn plugin family" with a feature strip that covers the broader scope ("PLUGIN HUB · GEORGIAN LOCATIONS · CHECKOUT FIELDS · MORE TO COME") rather than implying the plugin is locations-only.

v0.3.13

• Hygiene: bump bundled codeon/framework from 0.3.16 → 0.3.18 for parity with the rest of the CodeOn plugin suite. No behavioural change — CodeOn Core is free and has no license enforcement to gate.

v0.3.12

• Area position survives WC's client-side resort. The previous releases had Area at the correct DOM position (right after Country) — but assets/js/frontend/address-i18n.js (shipped by WooCommerce itself) re-sorts checkout fields by data-priority on every country_to_state_changing event, reading the priorities from wc_address_i18n_params.locale.default. Those localised priorities still carried WC's untouched default city: 70, so on every country pick WC's own JS re-tagged Area with priority 70 and moved it to between Address-line-2 (60) and State (80). That's what the merchant kept screenshotting.

  Fix: also set the unprefixed default.city.priority and default.state.priority in the woocommerce_default_address_fields filter, AND add a priority key to the GE-specific override in woocommerce_get_country_locale. Both filters feed wc_address_i18n_params directly, so the JS now reads Area at priority country_priority + 1 and the resort puts it back where the PHP rendered it. Reads country's actual priority at filter time so it works under any theme (Woodmart, default, custom) that may have re-mapped country.

• Plugin survey: also reviewed every other active hook on woocommerce_checkout_fields / woocommerce_default_address_fields / woocommerce_get_country_locale on the live install. The Personal-ID field plugins (balance-sync, fina-sync) add fields without specifying a priority for the filter callback — they don't re-order, no conflict with Area positioning. Woodmart's checkout-fields-manager hooks at priority 99999 but its frontend JS only modifies the "required" badge, not the DOM order.

v0.3.11

• Area now sits truly right-after-Country, even when a theme remaps Country's priority. On artcase.ge a live WC_Checkout::get_checkout_fields('billing') dump showed:

  • billing_first_name priority 10 (was 20 by default — Woodmart / Personal-ID plugin remapped it)
  • billing_city (Area) priority 11 (our v0.3.10 value)
  • billing_country priority 40 (was 10 by default — also remapped)

  My hard-coded priority = 11 put Area between first_name (10) and last_name (20) — visually "right after first name", not what the merchant wanted. Fix: read whatever priority Country ended up at AFTER all other filters have run (we still hook woocommerce_checkout_fields at priority 100000, and the WC 10.7 source confirms uasort() runs AFTER our filter) and set Area to country.priority + 1. State (hidden, auto-filled) gets country.priority + 2. Now Area renders immediately under Country regardless of what other plugins decided Country's priority should be.

• Shipping-zone "Add region" no longer hides 10 of the 13 Georgian regions. v0.3.2's Tbilisi-mode override trimmed woocommerce_states['GE'] to only the merchant's allowed area codes — which also applied to WP-admin → WC → Settings → Shipping → Add region. Removed the filter; the GE state catalog stays intact globally. The state field at checkout is still hidden via CSS + auto-filled, which is all Tbilisi mode actually needs.

v0.3.10

• Area field now renders immediately under Country / Region on checkout. Previously the priority = 11 change was applied in enforceFinalFieldSetup (hooked at woocommerce_checkout_fields priority 100000) — but WC's WC_Checkout::get_checkout_fields() runs uasort() on each fieldset BEFORE applying that filter, so the late priority change had no effect on render order. Moved the priority assignment to the earlier woocommerce_default_address_fields + woocommerce_billing_fields / woocommerce_shipping_fields filters, which run before WC's sort, so Area now lands right after Country exactly as configured.
• Admin Surroundings picker is Georgian-only. No more redundant labels like "ნორიო (გარდაბნის მუნიციპალიტეტი) (Norio (gardabnis munitsipaliteti))" — the trailing Latin transliteration is dropped both for pre-rendered selected pills AND for AJAX search results. The customer-facing Area dropdown still honours the merchant's display_mode setting; this change only affects the admin picker.