feat(store): add API to retrieve and update vendor store profile sett…#3103
feat(store): add API to retrieve and update vendor store profile sett…#3103
Conversation
📝 WalkthroughWalkthroughThe pull request adds three new REST API update parameters to the StoreController's get_store_update_params() method: vacation settings, store support options, and cart min/max order amount configuration. These parameters extend the public schema for store update operations with nested object structures and enumerated values. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
includes/REST/StoreController.php (2)
1301-1311:seller_vacation_schedulesitems should markfromandtoasrequired.Without
required, a schedule object containing onlymessage(with no date range) passes schema validation. For thedatewiseclosing style,fromandtoare semantically mandatory; accepting date-less entries will silently produce broken schedules.♻️ Proposed fix
'seller_vacation_schedules' => [ 'type' => 'array', 'items' => [ 'type' => 'object', + 'required' => [ 'from', 'to' ], 'properties' => [ 'from' => [ 'type' => 'string', 'format' => 'date' ], 'to' => [ 'type' => 'string', 'format' => 'date' ], 'message' => [ 'type' => 'string' ], ], ], ],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@includes/REST/StoreController.php` around lines 1301 - 1311, The schema for the seller_vacation_schedules array currently allows objects missing dates; update the item schema in StoreController (the 'seller_vacation_schedules' definition) to require the 'from' and 'to' properties by adding a "required" => ['from','to'] entry on the item object schema so that any schedule object without both date fields fails validation.
1290-1293: Inconsistent REST API type definition for toggle parameters.Existing toggle fields (
show_email,enable_tnc,enabled,featured,trusted) use'type' => 'boolean', while newly added toggle fields (setting_go_vacation,show_support_btn,show_support_btn_product,enable_vendor_min_max_amount) use'type' => 'string', 'enum' => ['yes', 'no'].The existing pattern in the codebase accepts boolean input, validates it with
dokan_validate_boolean(), and converts it to'yes'/'no'for meta storage. The new fields should follow the same pattern for API consistency rather than exposing the internal storage format as the API contract.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@includes/REST/StoreController.php` around lines 1290 - 1293, The new toggle fields (setting_go_vacation, show_support_btn, show_support_btn_product, enable_vendor_min_max_amount) currently expose storage as 'string' with enum ['yes','no']; change their REST schema entries to use 'type' => 'boolean' to match existing toggles (show_email, enable_tnc, enabled, featured, trusted), then ensure the controller continues to validate incoming booleans with dokan_validate_boolean() and convert/store them as 'yes'/'no' using the same conversion logic used elsewhere so the API contract remains boolean while meta storage stays unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@includes/REST/StoreController.php`:
- Around line 1327-1330: The numeric schema entries for min_amount_to_order and
max_amount_to_order currently allow negatives; update their JSON Schema
definitions in the REST schema array (the entries for 'min_amount_to_order' and
'max_amount_to_order') to include "minimum: 0" so values are non-negative. Keep
the type 'number' and add the minimum constraint here, and continue to enforce
min ≤ max in the update handler (not in this schema).
- Around line 1286-1332: The REST schema exposes pro-only fields ('vacation',
'store_support', 'cart_min_max' in StoreController.php) but Vendor::update
(includes/Vendor/Manager.php) does not persist them, so Lite API returns 200
without saving—either hide these properties when the Pro modules are not active
or implement persistence for them; update StoreController.php to conditionally
add those schema properties only when the Pro feature detection (use your
existing Pro-check helper) returns true, or alternatively extend Vendor::update
to read and save these fields (or re-dispatch them early via
dokan_rest_stores_update_store) so the data is actually handled; reference the
schema property names 'vacation', 'store_support', 'cart_min_max' and the
Vendor::update method when making the change.
---
Nitpick comments:
In `@includes/REST/StoreController.php`:
- Around line 1301-1311: The schema for the seller_vacation_schedules array
currently allows objects missing dates; update the item schema in
StoreController (the 'seller_vacation_schedules' definition) to require the
'from' and 'to' properties by adding a "required" => ['from','to'] entry on the
item object schema so that any schedule object without both date fields fails
validation.
- Around line 1290-1293: The new toggle fields (setting_go_vacation,
show_support_btn, show_support_btn_product, enable_vendor_min_max_amount)
currently expose storage as 'string' with enum ['yes','no']; change their REST
schema entries to use 'type' => 'boolean' to match existing toggles (show_email,
enable_tnc, enabled, featured, trusted), then ensure the controller continues to
validate incoming booleans with dokan_validate_boolean() and convert/store them
as 'yes'/'no' using the same conversion logic used elsewhere so the API contract
remains boolean while meta storage stays unchanged.
| 'vacation' => [ | ||
| 'description' => esc_html__( 'Vacation settings.', 'dokan-lite' ), | ||
| 'type' => 'object', | ||
| 'properties' => [ | ||
| 'setting_go_vacation' => [ | ||
| 'type' => 'string', | ||
| 'enum' => [ 'yes', 'no' ], | ||
| ], | ||
| 'settings_closing_style' => [ | ||
| 'type' => 'string', | ||
| 'enum' => [ 'instantly', 'datewise' ], | ||
| ], | ||
| 'setting_vacation_message' => [ | ||
| 'type' => 'string', | ||
| ], | ||
| 'seller_vacation_schedules' => [ | ||
| 'type' => 'array', | ||
| 'items' => [ | ||
| 'type' => 'object', | ||
| 'properties' => [ | ||
| 'from' => [ 'type' => 'string', 'format' => 'date' ], | ||
| 'to' => [ 'type' => 'string', 'format' => 'date' ], | ||
| 'message' => [ 'type' => 'string' ], | ||
| ], | ||
| ], | ||
| ], | ||
| ], | ||
| ], | ||
| 'store_support' => [ | ||
| 'description' => esc_html__( 'Store support settings.', 'dokan-lite' ), | ||
| 'type' => 'object', | ||
| 'properties' => [ | ||
| 'show_support_btn' => [ 'type' => 'string', 'enum' => [ 'yes', 'no' ] ], | ||
| 'show_support_btn_product' => [ 'type' => 'string', 'enum' => [ 'yes', 'no' ] ], | ||
| 'support_btn_name' => [ 'type' => 'string' ], | ||
| ], | ||
| ], | ||
| 'cart_min_max' => [ | ||
| 'description' => esc_html__( 'Cart min/max order amount settings.', 'dokan-lite' ), | ||
| 'type' => 'object', | ||
| 'properties' => [ | ||
| 'enable_vendor_min_max_amount' => [ 'type' => 'string', 'enum' => [ 'yes', 'no' ] ], | ||
| 'min_amount_to_order' => [ 'type' => 'number' ], | ||
| 'max_amount_to_order' => [ 'type' => 'number' ], | ||
| ], | ||
| ], | ||
| ]; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find Vendor class and its update method
find . -type f -name "*.php" | xargs grep -l "class Vendor" | head -5Repository: getdokan/dokan
Length of output: 279
🏁 Script executed:
# Search for the update method in Vendor class
rg -A 30 "function update\(" --type=php | grep -A 30 "Vendor\|vendor" | head -100Repository: getdokan/dokan
Length of output: 5930
🏁 Script executed:
# Search for direct handling of the new parameter keys
rg -n "setting_go_vacation|settings_closing_style|show_support_btn|enable_vendor_min_max_amount|seller_vacation_schedules" --type=phpRepository: getdokan/dokan
Length of output: 757
🏁 Script executed:
# Check if these parameters are used in Pro module hooks or filters
rg -n "dokan_rest_stores_update_store" --type=php -C 5Repository: getdokan/dokan
Length of output: 898
🏁 Script executed:
# Get the complete Vendor::update() method
cat -n includes/Vendor/Manager.php | sed -n '40,150p'Repository: getdokan/dokan
Length of output: 3651
🏁 Script executed:
# Check if there's a generic meta handling in Vendor::update()
rg -A 60 "public function update\(\s*\$vendor_id" includes/Vendor/Manager.php | head -100Repository: getdokan/dokan
Length of output: 40
🏁 Script executed:
# Find the line number of the update method in Vendor/Manager.php
rg -n "public function update" includes/Vendor/Manager.phpRepository: getdokan/dokan
Length of output: 116
🏁 Script executed:
# Read the Vendor class update method more carefully
sed -n '170,280p' includes/Vendor/Manager.php | cat -nRepository: getdokan/dokan
Length of output: 5793
🏁 Script executed:
# Look for the complete update method implementation
rg -B 5 -A 80 "public function update\(" includes/Vendor/Manager.php | head -150Repository: getdokan/dokan
Length of output: 3026
🏁 Script executed:
# Continue reading the update method to see if there's a generic meta handler
sed -n '257,380p' includes/Vendor/Manager.php | cat -nRepository: getdokan/dokan
Length of output: 5772
🏁 Script executed:
# Check if there's a dokan_profile_settings meta update in the update method
rg -A 150 "public function update\(\s*\$vendor_id" includes/Vendor/Manager.php | grep -A 150 "public function update"Repository: getdokan/dokan
Length of output: 40
🏁 Script executed:
# Get the complete update method - need more lines
sed -n '257,450p' includes/Vendor/Manager.php | cat -nRepository: getdokan/dokan
Length of output: 8780
🏁 Script executed:
# Continue reading to the end of the update method
sed -n '440,500p' includes/Vendor/Manager.php | cat -nRepository: getdokan/dokan
Length of output: 2498
🏁 Script executed:
# Check the total line count to see where the method ends
wc -l includes/Vendor/Manager.phpRepository: getdokan/dokan
Length of output: 89
🏁 Script executed:
# Check if there's any handling of the new Pro parameters elsewhere in the codebase
rg -n "vacation|cart_min_max|store_support" --type=php | grep -v "REST/StoreController.php" | head -20Repository: getdokan/dokan
Length of output: 1247
🏁 Script executed:
# Look at the update_store method in StoreController to see if it does anything special
sed -n '430,450p' includes/REST/StoreController.phpRepository: getdokan/dokan
Length of output: 701
Pro-only parameters in REST schema are silently dropped in Lite unless Pro modules are active.
The schema defines vacation, store_support, and cart_min_max parameters, but Vendor::update() (includes/Vendor/Manager.php:257–303) does not handle any of them. These parameters will be ignored by the Lite vendor update path and not persisted. The subsequent dokan_rest_stores_update_store hook fires after the update, allowing Pro modules to intercept and handle these fields, but this only works if Pro is active. Endpoints will return 200 OK without actually saving the data in Lite, creating a misleading API contract. Document this behavior or move these parameter definitions behind a conditional check for Pro module availability.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@includes/REST/StoreController.php` around lines 1286 - 1332, The REST schema
exposes pro-only fields ('vacation', 'store_support', 'cart_min_max' in
StoreController.php) but Vendor::update (includes/Vendor/Manager.php) does not
persist them, so Lite API returns 200 without saving—either hide these
properties when the Pro modules are not active or implement persistence for
them; update StoreController.php to conditionally add those schema properties
only when the Pro feature detection (use your existing Pro-check helper) returns
true, or alternatively extend Vendor::update to read and save these fields (or
re-dispatch them early via dokan_rest_stores_update_store) so the data is
actually handled; reference the schema property names 'vacation',
'store_support', 'cart_min_max' and the Vendor::update method when making the
change.
| 'enable_vendor_min_max_amount' => [ 'type' => 'string', 'enum' => [ 'yes', 'no' ] ], | ||
| 'min_amount_to_order' => [ 'type' => 'number' ], | ||
| 'max_amount_to_order' => [ 'type' => 'number' ], | ||
| ], |
There was a problem hiding this comment.
Add minimum: 0 to numeric amount fields.
min_amount_to_order and max_amount_to_order are declared as number with no lower bound, so negative values will pass schema validation. There is also no schema-level enforcement of min ≤ max (this needs to be handled in the update handler), but the non-negative guard is easy to add here.
🛡️ Proposed fix
-'min_amount_to_order' => [ 'type' => 'number' ],
-'max_amount_to_order' => [ 'type' => 'number' ],
+'min_amount_to_order' => [ 'type' => 'number', 'minimum' => 0 ],
+'max_amount_to_order' => [ 'type' => 'number', 'minimum' => 0 ],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@includes/REST/StoreController.php` around lines 1327 - 1330, The numeric
schema entries for min_amount_to_order and max_amount_to_order currently allow
negatives; update their JSON Schema definitions in the REST schema array (the
entries for 'min_amount_to_order' and 'max_amount_to_order') to include
"minimum: 0" so values are non-negative. Keep the type 'number' and add the
minimum constraint here, and continue to enforce min ≤ max in the update handler
(not in this schema).
1 participant
…ings
All Submissions:
Changes proposed in this Pull Request:
Related Pull Request(s)
Closes
How to test the changes in this Pull Request:
Changelog entry
Title
Detailed Description of the pull request. What was previous behaviour
and what will be changed in this PR.
Before Changes
Describe the issue before changes with screenshots(s).
After Changes
Describe the issue after changes with screenshot(s).
Feature Video (optional)
Link of detailed video if this PR is for a feature.
PR Self Review Checklist:
FOR PR REVIEWER ONLY:
Summary by CodeRabbit