feat(vendor-settings): flat-array Store settings backend (schema, mapper, writer, REST)

[MdAsifHossainNadim]

All Submissions:

• My code follow the WordPress' coding standards
• My code satisfies feature requirements
• My code is tested
• My code passes the PHPCS tests
• My code has proper inline documentation
• I've included related pull request(s) (optional)

Changes proposed in this Pull Request:

PR 1 of 3 for the vendor Store Settings → React migration (spec: getdokan/plugin-internal-tasks#2115, parent: getdokan/plugin-internal-tasks#1981). This is the pure PHP backend — no UI change, no behavior change for the legacy page.

Serves the plugin-ui flat-array schema with values from dokan_profile_settings and persists through the exact legacy save pipeline, so storage keys and value shapes stay byte-identical and every Pro consumer on the two seams keeps working.

• Vendor/Settings/Schema/StoreSettingsSchema.php — flat SettingsElement[] (page → subpage → collapsible section cards → fields) with values populated inline. Conditional blocks use the same server-side gates as templates/settings/store-form.php: map only with dokan_has_map_api_key(), ToC only when seller_enable_terms_and_conditions is on, schedule only when appearance store_open_close is on, email visibility hidden per dokan_is_vendor_info_hidden('email'), address handed over when Pro delivery-time is active, catalog-mode per its admin gates. Pro appends via the new dokan_get_vendor_settings_schema filter (mirrors dokan_get_admin_settings_schema).
• Vendor/Settings/ValueMapper.php — flat field ids → legacy keys. Composites handled bespoke: store_map → location + find_address; address merges over previous subkeys (preserves store-pickup's location_name); catalog-mode ids → nested catalog_mode array preserving RFQ's request_a_quote_enabled + the legacy forced-off rule. Any Pro-injected field persists via its string legacy_key (defaults to the field id).
• Vendor/Settings/StoreSettingsWriter.php — the one write path: shallow array_merge, dokan_store_name mirror meta, dokan_store_profile_settings_args filter, canonical meta write, dokan_store_profile_saved( $id, $merged, $prev ). Deliberately never re-applies the legacy dokan_store_time POST-parsing filter (Pro's parser returns null without the legacy nonce and would wipe the schedule on REST saves).
• REST/VendorStoreSettingsController.php — GET/PUT /dokan/v1/vendor-settings/store on DokanBaseVendorController (vendor-staff aware via get_vendor_id_for_user()), permission dokandar + dokan_view_store_settings_menu. Validation failures return 400 { errors: { field_id: [messages] } } (plugin-ui merges these into per-field errors). Validations use the plugin-ui client contract ([{ rules: 'not_empty', message }]) so one declaration drives both sides; the schedule validator enforces matching g:i a pairs with opening < closing (single Lite slot and Pro multi-slot both accepted). Pro extension filters: dokan_rest_vendor_settings_sanitize_field / dokan_rest_vendor_settings_validate_field.

Related Pull Request(s)

• feat(vendor-settings): complete the reactive Store settings page #3312
• feat(vendor-settings): wire React Store settings route + custom field variants #3311
• test(store-settings): vendor Store Settings migration e2e + API coverage #3322
• https://github.com/getdokan/dokan-pro/pull/5919

Closes

• https://github.com/getdokan/plugin-internal-tasks/issues/2115
• https://github.com/getdokan/dokan-pro/issues/5265

How to test the changes in this Pull Request:

1. As a logged-in vendor, GET /wp-json/dokan/v1/vendor-settings/store — returns the flat schema with current values; sections respect the admin gates (disable the map API key → store_map_section disappears, etc.).
2. PUT /wp-json/dokan/v1/vendor-settings/store with { "values": { "store_name": "" } } → 400 with errors.store_name.
3. PUT a valid payload → dokan_profile_settings keys/shapes are byte-identical to a legacy form save ('yes'/'no', 'on'/'off', attachment-ID ints, per-day {status, opening_time[], closing_time[]} with g:i a strings); untouched keys (payment, vendor_biography, …) survive; dokan_store_name mirror meta syncs; both legacy seams fire (verify a Seam-B consumer like store-support still persists).
4. Smoke-tested on this branch: schema builds for a real seller (20 elements, delivery-time active correctly omits the address section) and the route registers.

Changelog entry

Vendor Store Settings flat-array backend

Adds the schema/REST backend for the React vendor Store Settings page. No user-facing change yet: the legacy page keeps rendering and saving as before; storage stays in dokan_profile_settings with unchanged keys and value shapes.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 4c2c8bce-6391-45f6-94c0-8d88f0d295ff

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/vendor-store-settings-backend

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[MdAsifHossainNadim]

Pro counterpart: getdokan/dokan-pro#5919 — extends this vendor Store settings implementation (module sections, tab placements, min-max validation) and should ship together with it.