Skip to content

Conversation

@akzmoudud
Copy link
Contributor

@akzmoudud akzmoudud commented Feb 2, 2026

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)
  • I've included developer documentation (optional)
  • I've added proper labels to this pull request

Changes proposed in this Pull Request:

Related Pull Request(s)

  • Full PR Link

Closes

  • Closes #

How to test the changes in this Pull Request:

  • Steps or issue link

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:

  • Code is not following code style guidelines
  • Bad naming: make sure you would understand your code if you read it a few months from now.
  • KISS: Keep it simple, Sweetie (not stupid!).
  • DRY: Don't Repeat Yourself.
  • Code that is not readable: too many nested 'if's are a bad sign.
  • Performance issues
  • Complicated constructions that need refactoring or comments: code should almost always be self-explanatory.
  • Grammar errors.

FOR PR REVIEWER ONLY:

As a reviewer, your feedback should be focused on the idea, not the person. Seek to understand, be respectful, and focus on constructive dialog.

As a contributor, your responsibility is to learn from suggestions and iterate your pull request should it be needed based on feedback. Seek to collaborate and produce the best possible contribution to the greater whole.

  • Correct — Does the change do what it’s supposed to? ie: code 100% fulfilling the requirements?
  • Secure — Would a nefarious party find some way to exploit this change? ie: everything is sanitized/escaped appropriately for any SQL or XSS injection possibilities?
  • Readable — Will your future self be able to understand this change months down the road?
  • Elegant — Does the change fit aesthetically within the overall style and architecture?

Summary by CodeRabbit

  • New Features
    • Vendor API responses (for authorized users) now include comprehensive payment method metadata.
    • Visible: active, connected, and disconnected payment methods.
    • Also included: withdrawal options, required bank payment fields, placeholders for payment fields, and chargeable payment method details.

@akzmoudud akzmoudud requested a review from mrabbani February 2, 2026 04:12
@akzmoudud akzmoudud self-assigned this Feb 2, 2026
@akzmoudud akzmoudud added Needs: Testing This requires further testing Needs: Dev Review It requires a developer review and approval labels Feb 2, 2026
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 2, 2026

📝 Walkthrough

Walkthrough

Adds additional vendor/payment metadata to StoreController API responses: when the requester is authorized, the controller fetches seller payment methods and injects bank payment required fields, active/connected/disconnected methods, withdraw options, field placeholders, and chargeable methods. Also defaults the method's third parameter to an empty array.

Changes

Cohort / File(s) Summary
Payment metadata & API signature
includes/REST/StoreController.php
Retrieves $methods_data for authorized stores and appends bank_payment_required_fields, active_payment_methods, connected_methods, disconnected_methods, withdraw_options, fields_placeholders, and chargeable_methods to responses. Also updates prepare_item_for_response(..., $additional_fields = []) default parameter.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested labels

Dev Review Done

Suggested reviewers

  • mrabbani

Poem

🐰 I hopped through code to patch the view,
Payment fields tucked in, neat and new,
Connected, active, placeholders too,
Authorized eyes receive the clue —
A tiny rabbit's release review. 🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Description check ⚠️ Warning The PR description is largely incomplete. While the checklist is filled out, critical sections such as 'Changes proposed', 'How to test', 'Changelog entry', 'Before Changes', and 'After Changes' are empty or contain only placeholder text. Complete the 'Changes proposed', 'How to test', 'Changelog entry', 'Before/After Changes' sections with specific details about what was changed, why, and how to verify the fix works correctly.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The PR title directly addresses the main change: injecting connected/disconnected payment method data into the vendor profile response to fix missing or conflicting withdraw status display.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix/admin-vendor-withdraw-connection-state

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

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@includes/REST/StoreController.php`:
- Around line 730-731: Remove the redundant vendor lookup and avoid premature
data retrieval: stop calling dokan()->vendor->get($store->get_id()) and use the
existing $store object directly for its ID; also move the call to
dokan_get_container()->get('dashboard')->templates->settings->get_seller_payment_methods(...)
so it runs inside the if ($is_authorized) block (assign $methods_data there
using $store->get_id()), eliminating the unconditional $methods_data fetch for
unauthorized requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Needs: Dev Review It requires a developer review and approval Needs: Testing This requires further testing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants