No, it sits alongside them. The standard Settings screens stay where they are. SleekView adds a cross-zone, cross-method table for audit, support, and bulk-update workflows that the default nested UI cannot do efficiently.

Yes for common fields (cost, title, tax status, enabled flag). SleekView reads the instance settings JSON from wp_options and writes back via WC_Shipping_Zone methods so the regular hooks (woocommerce_shipping_zone_method_status_toggled) still fire.

Yes. Third-party methods that store rates in their own table (for example woocommerce_shipping_table_rates) are exposed as additional sources. Build a separate view per rate table or join them through their instance_id.

Yes. SleekView triggers the same cache-clear logic that the standard shipping settings use — calling WC_Cache_Helper::get_transient_version or the equivalent CRUD path. Frontend shipping rates re-calculate on the next cart load just as they would after a manual edit.

Zone locations are stored in wp_woocommerce_shipping_zone_locations as one row per country, state, or postcode. SleekView either aggregates them per zone (one row per zone with a comma-separated locations column) or shows them as a separate location-level view.

Yes for table-rate-style methods. Shipping classes are stored as terms in the product_shipping_class taxonomy, and method settings reference them by id. SleekView resolves the ids to names so the class column shows real values, not numeric ids.

It reads costs as stored. If a currency switcher rewrites costs per locale, the source-of-truth value is what shows in SleekView. For multi-currency stores using a side store table, SleekView can be pointed at that table as an additional source.

Queries hit indexed columns on shipping_zones and shipping_zone_methods and only deserialize the wp_options rows for the visible page. Pagination is keyset where possible and per-instance settings columns are opt-in, so default lists stay fast even on large configurations.