WP Manifestindependent plugin directory
manifest / ecommerce / codeon-core

CodeOn Core WP Registry grade A. No security issues foundWP RegistryNo security issues foundOpen the reportA

Codeon Core Free Plugin

★ 0stars
174release downloads
v0.3.19latest · 5mo ago

Install

Download codeon-core-v0.3.19.zip From the v0.3.19 release on GitHub, May 21, 2026

Upload it under Plugins → Add New Plugin → Upload Plugin, then activate.

Install straight from GitHub with WP-CLI:

wp plugin install https://github.com/samsiani/codeon-core/releases/download/v0.3.19/codeon-core-v0.3.19.zip
Updates itself. It ships its own updater (Plugin Update Checker), so new versions appear under Dashboard → Updates.

Georgian Locations for WooCommerce — cascading Region → Municipality → Settlement address picker. 4,394 settlements bundled.

Description

WooCommerce out of the box has no idea what a Georgian city is. Customers type their settlement name freehand, with five different spellings, in three languages. Reports are useless. Couriers reject orders.

CodeOn Core ships the entire administrative hierarchy of Georgia — 13 regions, 77 municipalities, 4,394 settlements (cities, towns, villages) — as a structured, cascading checkout dropdown.

Customers select Region → Municipality → Settlement. Validated server-side. Stored as structured order meta. Filterable in the admin orders list. Compatible with classic checkout (block checkout in v0.2.0).

What you get

  • Cascading address picker on classic WooCommerce checkout (block-checkout coming in v0.2)
  • 4,394 Georgian settlements, fully bilingual (Georgian + Latin transliteration)
  • Region dropdown aligned with WooCommerce's existing Georgia state codes (TB, AJ, IM, …) — no breaking changes for existing orders
  • REST API for typeahead search & cascade lookups
  • HPOS-compatible structured order meta
  • Custom Georgian address format on emails, invoices, and the My Account page
  • Toggle to hide occupied territories (Abkhazia, Tskhinvali region) — hidden by default
  • Display mode setting: Always Georgian, Always English (transliterated), or Bilingual ("კონდოლი (Kondoli)")

What you don't get

  • No upsells in the checkout flow.
  • No phoning home.
  • No mandatory account creation.

About CodeOn

CodeOn Core also acts as the canonical home for the CodeOn family of premium WooCommerce plugins (TBC Card, BOG Card, Flitt, and others). When a CodeOn premium plugin is installed alongside Core, both share a single tidy admin menu instead of cluttering the sidebar. Premium plugins are sold separately at codeon.ge — they are not required for the locations feature.

Installation

  1. Install via Plugins → Add New → search for "CodeOn Core" → Install → Activate.
  2. WooCommerce → CodeOn → Locations to configure display mode and toggle occupied territories.
  3. That's it. The checkout cascade activates automatically when a customer selects Georgia as their country.

Frequently Asked Questions

Does it work with the WooCommerce Checkout block?

Block checkout support arrives in v0.2.0 (next release). v0.1 supports the classic shortcode-based checkout.

Does it conflict with my existing Georgia state codes?

No. We preserve WooCommerce's existing 12 GE state codes (TB, AJ, IM, …) and only add TS for the Tskhinvali region. Existing orders continue to validate.

Will villages I'm missing be added?

The dataset comes from ka.wikipedia.org categorized by municipality. Open an issue at our GitHub if a village is wrong or missing — we re-sync on every plugin release.

Are occupied territories included?

Yes — Abkhazia and the Tskhinvali region are in the dataset but hidden by default. Enable them in the settings if your store ships there.

Screenshots

  1. Cascading address picker on the WooCommerce checkout — Region, Municipality, Settlement.
  2. Diagnostics tab showing dataset size and version.
  3. CodeOn hub menu with installed plugins listed underneath.

Changelog

0.3.19 — 2026-05-21

  • 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.

0.3.18 — 2026-05-21

  • 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.

0.3.17 — 2026-05-21

  • 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.

0.3.16 — 2026-05-21

  • 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.

0.3.15 — 2026-05-21

  • 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.

0.3.14 — 2026-05-21

  • 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.

0.3.13 — 2026-05-21

  • 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.

0.3.12 — 2026-05-11

  • 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.

0.3.11 — 2026-05-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.

0.3.10 — 2026-05-11

  • 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.

0.3.9 — 2026-05-11

  • Surroundings-picker pill polish per merchant feedback:
    • Removed line-height: 1 from the scoped remove-× rule so the × is no longer cropped vertically (was overriding the natural pill line-height).
    • Neutralised Select2 v4.1.0-rc.0's default border-right: 1px solid #aaa on .select2-selection__choice__remove — the ugly faux-separator between × and pill text is gone.
    • Bumped the choice's padding-left to 20px !important so the × has visible breathing room from the pill's left edge.
  • Headless-verified the three computed values before tagging (paddingLeft: 20px, borderRight: 0px none, lineHeight: normal).

0.3.8 — 2026-05-11

  • Surroundings picker pills no longer spill outside the box. Root cause was twofold:
    1. Select2 v4.1.0-rc.0's containerCssClass option silently dropped on init — so every CSS rule I'd scoped to .codeon-tbilisi-picker never matched the rendered container, and Select2's tight defaults applied unmodified. Now adding the scoping class manually via $sel.next('.select2-container').addClass(...) immediately after init, guaranteed to take effect.
    2. The fallback CSS used float: left on pills with a display: block parent <ul> — classic float-containment problem (parent height collapses, pills overflow downward). Switched to display: flex; flex-wrap: wrap; gap: 6px on the <ul> with float: none; flex: 0 0 auto on the pills. Parent now grows organically as pills wrap.
  • Typed text in the search input is now unambiguously visible. The search <li> is flex: 1 0 100% so it always wraps to its own line below the pills. The <input> inside is width: 100%, min-height: 40px, font-size: 14px, color: #0b0f19, background: #fff, with a 1px visible border and brand focus ring. No more typing into invisible 0-px inputs.
  • Headless verified before tagging. Built a puppeteer rig that loads the picker with 10 pre-selected pills, then types "gant" into the empty-state search field. Measured: 0 pills outside the container bounds, search input box is 684×40px, typed text colour is rgb(11,15,25), background rgb(255,255,255), font size 14px. Both screenshots inspected (/tmp/picker-1-initial.png, /tmp/picker-2-typing-empty.png) — pills wrap inside, typed text is clearly readable.

0.3.7 — 2026-05-11

  • Surroundings picker UX polish, modelled after WooCommerce's country selector.
    • Search input now sits on its own full-width row below the pills with a visible white background + light border. Typed text is unambiguously readable — fixes the "I can't see what I'm typing" report.
    • Container background is light grey (--bg-muted) so the white pills + white search row read as distinct surfaces inside the picker.
    • Container grows downward smoothly as pills wrap; no more pills falling outside the visible border.
    • Dropped the redundant " — Muni, Region" suffix that the picker was appending to every result. The dataset's name_ka already disambiguates similarly-named villages with (<muni>) in parens — appending the slugs on top produced labels like "არაშენდა (მცხეთის მუნიციპალიტეტი) — მცხეთის მუნიციპალიტეტი, მცხეთა-მთიანეთი". Now you just get "არაშენდა (მცხეთის მუნიციპალიტეტი)".
  • Area field repositioned on checkout. Was rendering at priority 47 (between Company and Address line 1). Moved to priority 11 — sits immediately after Country / Region as the merchant requested. Hidden state field moved to priority 12 to stay paired with country in case any theme renders hidden rows.
  • The customer-facing Area dropdown labels also lost the redundant " — Muni, Region" suffix for the same dataset-disambiguation reason.

0.3.6 — 2026-05-11

  • Surroundings multiselect now actually persists picked settlements. The framework's FieldValidator::process() explicitly skips Field::RAW entries (no built-in sanitizer / validator), so the picker rendered fine but the chosen settlement IDs never reached the option. Hooked Tab::beforeSave() to pull the raw POST array directly, sanitize each entry to a positive int + validate it exists in the dataset, and inject the result into the clean payload that gets persisted. Settlement IDs that don't resolve are silently dropped (defensive against tampered POSTs).
  • Bigger, clearer picker UI. Visible input box is now min-height: 120px (was Select2's default ~32px) so it reads as a proper multi-line picker. Search input inside is min-width: 240px, font-size: 14px, with placeholder colour and a transparent background so typed text is visible against the white pill area. Pills use the brand --brand-soft background + --brand-border border to match the rest of the dashboard.
  • Container grows dynamically as more pills are added. Replaced the earlier display: flex rule (which fought Select2's natural <li> flow and clipped pills below the visible border) with an inline-block layout + height: auto + overflow: visible overrides — the box now extends downward smoothly as the merchant adds more surroundings.
  • Scoped Select2 styling via containerCssClass: 'codeon-tbilisi-picker' + dropdownCssClass: 'codeon-tbilisi-picker-dropdown' so these overrides only touch the surroundings picker and never bleed into other Select2 instances elsewhere on the page.

0.3.5 — 2026-05-11

  • Fully self-contained Tbilisi-tab reveal logic — no FOUC, no framework dependency. v0.3.4 patched the framework's own inputValue(), but on stores with multiple CodeOn plugins co-installed, WordPress only registers the codeon-framework-admin script handle ONCE — whichever plugin loads first wins. If a co-installed plugin still ships the stale (broken) framework JS, codeon-core's patched copy is never loaded. v0.3.5 sidesteps the problem entirely:
    • Inline `

This README is longer than the copy stored here. Read the rest on GitHub →

Releases

Newest 25 of 45 recorded releases. Each count is every asset in that release; expand a row for the breakdown.

Tag
Published
Assets
Downloads
v0.3.19 latest
May 21, 2026 5mo ago
codeon-core-v0.3.19.zip
97
May 21, 2026 5mo ago
codeon-core-v0.3.18.zip
1
May 21, 2026 5mo ago
codeon-core-v0.3.17.zip
0
May 21, 2026 5mo ago
codeon-core-v0.3.16.zip
2
May 21, 2026 5mo ago
codeon-core-v0.3.15.zip
1
May 21, 2026 5mo ago
codeon-core-v0.3.14.zip
0
May 21, 2026 5mo ago
codeon-core-v0.3.13.zip
0
May 10, 2026 5mo ago
codeon-core-v0.3.12.zip
15
May 10, 2026 5mo ago
codeon-core-v0.3.11.zip
1
May 10, 2026 5mo ago
codeon-core-v0.3.10.zip
3
May 10, 2026 5mo ago
codeon-core-v0.3.9.zip
3
May 10, 2026 5mo ago
codeon-core-v0.3.8.zip
1
May 10, 2026 5mo ago
codeon-core-v0.3.7.zip
1
May 10, 2026 5mo ago
codeon-core-v0.3.6.zip
1
May 10, 2026 5mo ago
codeon-core-v0.3.5.zip
1
May 10, 2026 5mo ago
codeon-core-v0.3.4.zip
1
May 10, 2026 5mo ago
codeon-core-v0.3.3.zip
3
May 10, 2026 5mo ago
codeon-core-v0.3.2.zip
1
May 10, 2026 5mo ago
codeon-core-v0.3.1.zip
1
May 10, 2026 5mo ago
codeon-core-v0.3.0.zip
1
May 8, 2026 5mo ago
codeon-core-v0.2.9.zip
5
May 8, 2026 5mo ago
codeon-core-v0.2.8.zip
1
May 8, 2026 5mo ago
codeon-core-v0.2.7.zip
1
May 8, 2026 5mo ago
codeon-core-v0.2.6.zip
1
May 8, 2026 5mo ago
codeon-core-v0.2.5.zip
1
All releases on GitHub →
A grade

Security

CodeOn Core 0.3.19 · audited by WP Registry

No security issues found.

Audited release
0.3.19
Findings
none
Worst severity
—
Content hash
0c862f223a95e739e158a549…

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.