Skip to content

Conversation

@MdAsifHossainNadim
Copy link
Contributor

@MdAsifHossainNadim MdAsifHossainNadim commented Nov 28, 2025

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)

Closes

How to test the changes in this Pull Request:

  • Steps or issue link

Changelog entry

fix: Add the reflection of admin-configured banner dimensions in admin vendor settings

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

    • Banner dimensions can be customized via WordPress filters (defaults preserved).
  • Refactor

    • Streamlined image upload and cropping behavior for more consistent, predictable results.
  • Bug Fixes / UI

    • Enforced minimum banner display and removal heights to avoid layout issues.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 28, 2025

Walkthrough

Streamlines image cropping by removing runtime ratio calculations and exposing a consistent cropControl; makes banner dimensions dynamic via wp.hooks.applyFilters (defaults 625×300) and passes them into media upload handlers and UI hints.

Changes

Cohort / File(s) Change Summary
Image cropping & media options (TS/JS)
src/admin/dashboard/pages/vendor-create-edit/WpMedia.ts, assets/src/js/script.js
Removed mutable init/recalculation of crop coordinates and ratio-based adjustments; replaced mutable vars with constants; imgSelectOptions now always include aspectRatio, maxWidth, maxHeight; introduced cropControl with mustBeCropped logic; switched media controller from Cropper to CustomizeImageCropper and pass cropControl to media frame.
Vendor form — dynamic banner dims (TSX & PHP)
src/admin/dashboard/pages/vendor-create-edit/form/General.tsx, templates/settings/store-form.php
Added sprintf i18n import and bannerWidth/bannerHeight via wp.hooks.applyFilters (defaults 625×300); replaced hardcoded banner size label with dynamic sprintf string; pass computed width/height into wpMedia(...) calls; CSS uses guarded minimums (max(banner_width, 625), max(banner_height, 300)) for display.
Manifest
package.json
Included in manifest list (no code changes described).

Sequence Diagram(s)

mermaid
sequenceDiagram
participant AdminUI as Admin UI (vendor form)
participant WP_Media as wp.media frame (CustomizeImageCropper)
participant MediaLibrary as WordPress Media Library / Attachment
participant CropControl as cropControl.mustBeCropped

AdminUI->>WP_Media: open media frame with imgSelectOptions + cropControl
WP_Media->>CropControl: call mustBeCropped(imageWidth,imageHeight,params)
alt mustBeCropped = true
WP_Media->>MediaLibrary: present cropper UI (enforce aspectRatio/maxWidth/maxHeight)
MediaLibrary-->>WP_Media: cropped image + coordinates
else mustBeCropped = false
WP_Media->>MediaLibrary: allow direct selection (no crop enforced)
MediaLibrary-->>WP_Media: selected image URL
end
WP_Media-->>AdminUI: return image data (URL, dimensions, crop coords if any)

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

  • Areas needing attention:
    • assets/src/js/script.js: verify the new mustBeCropped rules cover all previous edge cases and integration with CustomizeImageCropper.
    • WpMedia.ts: ensure removal of mutable coordinate recalculation doesn't break existing crop presets or saved vendor banners.
    • General.tsx / templates/settings/store-form.php: confirm wp.hooks.applyFilters usage and UI text formatting (sprintf) behave across translations and overridden filter values.

Possibly related PRs

Suggested reviewers

  • mrabbani
  • shohag121

Poem

🐰 I hopped through constants, neat and bright,
No more ratios dancing out of sight.
Banners learn the sizes admins set,
Croppers ask first — then trim or let.
A nibble of code, all tidy and light. 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main objective: adding banner image dimension settings reflection on admin vendor page.
Description check ✅ Passed The description follows the template structure with key sections completed (submissions checklist, related PR, issue closure, changelog), though detailed testing steps and before/after screenshots are missing.
Linked Issues check ✅ Passed Code changes successfully implement dynamic banner dimension reflection via wp.hooks.applyFilters and pass those values to media handlers, directly addressing the core requirement in issue #5197.
Out of Scope Changes check ✅ Passed Changes to WpMedia.ts, General.tsx, script.js, and store-form.php are cohesive and focused on banner dimension settings; refactoring cropping logic is necessary infrastructure for proper dimension handling.
✨ 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/store-diemensions-settings-not-working-perfectly-for-new-vendor-settings-page

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.

@MdAsifHossainNadim MdAsifHossainNadim self-assigned this Nov 28, 2025
@MdAsifHossainNadim MdAsifHossainNadim added Needs: Dev Review It requires a developer review and approval Needs: Testing This requires further testing Upcoming Release labels Nov 28, 2025
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

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6d52144 and 64663c9.

📒 Files selected for processing (2)
  • src/admin/dashboard/pages/vendor-create-edit/WpMedia.ts (4 hunks)
  • src/admin/dashboard/pages/vendor-create-edit/form/General.tsx (5 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-19T06:19:41.376Z
Learnt from: mrabbani
Repo: getdokan/dokan PR: 2891
File: src/admin/dashboard/pages/vendors-single/InformationTabs/WithdrawTab.tsx:58-59
Timestamp: 2025-09-19T06:19:41.376Z
Learning: The Dokan codebase uses 'dokan-lite' as the text domain for WordPress internationalization (__() function calls).

Applied to files:

  • src/admin/dashboard/pages/vendor-create-edit/form/General.tsx
🧬 Code graph analysis (2)
src/admin/dashboard/pages/vendor-create-edit/form/General.tsx (1)
src/admin/dashboard/pages/vendor-create-edit/WpMedia.ts (1)
  • wpMedia (52-250)
src/admin/dashboard/pages/vendor-create-edit/WpMedia.ts (1)
assets/src/js/product-editor.js (3)
  • xInit (1293-1300)
  • realWidth (1291-1291)
  • realHeight (1292-1292)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
  • GitHub Check: e2e tests (1, 3)
  • GitHub Check: api tests (1, 1)
  • GitHub Check: e2e tests (3, 3)
  • GitHub Check: e2e tests (2, 3)
🔇 Additional comments (7)
src/admin/dashboard/pages/vendor-create-edit/form/General.tsx (4)

1-1: LGTM!

The sprintf import is correctly added to support the dynamic banner dimension label.


319-324: LGTM!

The dynamic banner size label correctly uses sprintf with the computed bannerWidth and bannerHeight values, ensuring the admin-configured dimensions are displayed to users.


334-338: LGTM!

The banner change action correctly passes the dynamic bannerWidth and bannerHeight values to the wpMedia function, ensuring the cropper uses the admin-configured dimensions.


389-395: LGTM!

The banner upload action correctly passes the dynamic bannerWidth and bannerHeight values to the wpMedia function, ensuring consistency with the change action.

src/admin/dashboard/pages/vendor-create-edit/WpMedia.ts (3)

58-63: LGTM!

Converting xInit and yInit to const improves code immutability and prevents accidental reassignment. The logic correctly uses the provided croppingWidth and croppingHeight parameters or falls back to the global store_banner_dimension settings.


73-74: LGTM!

Converting realWidth and realHeight to const is appropriate since these values are derived from the attachment and should not be modified.


90-104: Verify that always including aspectRatio/maxHeight/maxWidth doesn't break flexible cropping.

The change to make imgSelectOptions a const and always include aspectRatio, maxHeight, and maxWidth properties appears to remove previously conditional logic. While this aligns with the General.tsx changes that now pass explicit dimensions, it's important to verify that this doesn't break scenarios where flexible width/height cropping is expected.

The AI summary mentions "removed intermediate ratio-based cropping adjustments," but without seeing the old code, it's unclear if this change might affect:

  • Cases where flex_width or flex_height is true in cropControl (lines 142-149)
  • The mustBeCropped logic that checks flexibility flags (lines 153-193)

Please test the following scenarios to ensure cropping behavior remains correct:

  1. Upload a banner when admin has set fixed dimensions (flex_width=false, flex_height=false)
  2. Upload a banner when admin has set flexible width (flex_width=true)
  3. Upload a banner when admin has set flexible height (flex_height=true)
  4. Upload a banner when both dimensions are flexible

Verify that the cropper behaves as expected in each case and that the canSkipCrop flag is set appropriately.

@Aunshon Aunshon added Dev Review Done and removed Needs: Dev Review It requires a developer review and approval labels Nov 28, 2025
@dev-shahed
Copy link
Member

There’s an existing issue on the vendor dashboard where the size-cropping functionality isn’t working the same way it does on the admin dashboard. Since this PR is intended to fix the cropping issue on the admin side, we’ll proceed with it as is.

@MdAsifHossainNadim
@getdokan/product-plugin-team

@dev-shahed dev-shahed added 🎉 QA Approved This PR is approved by the QA team and removed Needs: Testing This requires further testing labels Dec 1, 2025
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

🧹 Nitpick comments (1)
assets/src/js/script.js (1)

351-417: Consider future consistency: profile image still uses legacy crop approach.

The banner upload now uses CustomizeImageCropper with explicit cropControl, while calculateImageSelectOptionsProfile still relies on api.HeaderTool.ImageModel.shouldBeCropped(). This is fine for now since profile pictures have fixed 150×150 dimensions, but consider unifying the approach in a future refactor for maintainability.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 64663c9 and cd1fd13.

📒 Files selected for processing (2)
  • assets/src/js/script.js (4 hunks)
  • templates/settings/store-form.php (1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
assets/src/js/script.js (1)
assets/src/js/product-editor.js (3)
  • xInit (1293-1300)
  • realWidth (1291-1291)
  • realHeight (1292-1292)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
  • GitHub Check: e2e tests (3, 3)
  • GitHub Check: e2e tests (2, 3)
  • GitHub Check: api tests (1, 1)
  • GitHub Check: e2e tests (1, 3)
🔇 Additional comments (3)
templates/settings/store-form.php (1)

277-283: LGTM! Dynamic banner dimensions with sensible fallbacks.

The CSS now correctly reflects admin-configured banner dimensions while ensuring minimum sizes of 625×300 pixels. The esc_attr() escaping is properly applied.

assets/src/js/script.js (2)

177-194: LGTM! Clean refactor to centralized crop control.

The cropping decision logic is now properly delegated to cropControl.mustBeCropped(), and image select options always include aspect ratio constraints for consistent behavior.


337-340: Correct usage of CustomizeImageCropper with custom control.

The switch to wp.media.controller.CustomizeImageCropper properly supports the new cropControl object, enabling dynamic dimension handling for banner uploads.

@MdAsifHossainNadim MdAsifHossainNadim merged commit 1cb516f into develop Dec 4, 2025
2 of 6 checks passed
@MdAsifHossainNadim MdAsifHossainNadim deleted the fix/store-diemensions-settings-not-working-perfectly-for-new-vendor-settings-page branch December 4, 2025 07:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants