Skip to content

Revert "fix: Add banner image dimension settings reflection on admin vendor page." - #3042

Merged
MdAsifHossainNadim merged 1 commit into
developfrom
revert-3019-fix/store-diemensions-settings-not-working-perfectly-for-new-vendor-settings-page
Dec 22, 2025
Merged

Revert "fix: Add banner image dimension settings reflection on admin vendor page."#3042
MdAsifHossainNadim merged 1 commit into
developfrom
revert-3019-fix/store-diemensions-settings-not-working-perfectly-for-new-vendor-settings-page

Conversation

@MdAsifHossainNadim

@MdAsifHossainNadim MdAsifHossainNadim commented Dec 22, 2025

Copy link
Copy Markdown
Contributor

Reverts #3019

Summary by CodeRabbit

  • Bug Fixes

    • Improved image cropping behavior with refined aspect ratio calculations to better handle images with different dimensions.
  • Refactor

    • Simplified banner upload workflow for reduced complexity.
    • Updated banner dimension constraints for consistent display across the platform.

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

@coderabbitai

coderabbitai Bot commented Dec 22, 2025

Copy link
Copy Markdown
Contributor

Walkthrough

The changes refactor image cropping logic across multiple files, introducing dynamic computation of crop dimensions based on actual image aspect ratios. A header image model now determines cropping needs, and theme dimensions are adjusted to fit computed aspect ratios. The JavaScript cropper initialization is updated to use Cropper with a fixed large suggested width, while template styling removes implicit minimum sizing constraints for banner elements.

Changes

Cohort / File(s) Summary
Image cropping logic
assets/src/js/script.js, src/admin/dashboard/pages/vendor-create-edit/WpMedia.ts
Refactored crop control to use header image model with shouldBeCropped() check. Introduced dynamic aspect ratio computation (xInit/yInit ratio) and real image dimension tracking (xImg, yImg). Added conditional adjustments for image select options (aspectRatio, maxHeight, maxWidth) based on flex flags. Updated cropper initialization to use Cropper library with fixed 5000px suggested width.
Banner integration
src/admin/dashboard/pages/vendor-create-edit/form/General.tsx
Removed dynamic banner dimension handling (bannerWidth/bannerHeight) and wp.filters hooks. Replaced dynamic banner size display with fixed text "Size - 600 X 325 px". Simplified banner upload flow by passing single argument to wpMedia instead of width/height parameters.
Template styling
templates/settings/store-form.php
Relaxed maximum width/height constraints for banner container and remove-banner-image element by replacing minimum fallback logic (max operations) with direct use of actual banner dimensions.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

  • WpMedia.ts: The aspect ratio computation logic and conditional dimension adjustments require careful verification to ensure correct crop frame calculations across different image sizes.
  • assets/src/js/script.js: Variable tracking and Cropper initialization changes need validation for proper integration with the new dimension model.
  • General.tsx: Verify that fixed banner dimensions (600 X 325 px) are appropriate for all use cases and that single-argument wpMedia calls handle the setup correctly.
  • store-form.php: Ensure removal of implicit minimums doesn't cause layout issues with smaller banner dimensions.

Possibly related PRs

Suggested labels

Dev Review Done, QA Approved

Suggested reviewers

  • mrabbani
  • Aunshon

Poem

🐰✨ A cropper so fine, with ratios divine,
We flex and we bend each dimension in line,
From banners to borders, the logic takes flight,
Aspect ratios dance in the code, oh what delight!
No more static sizing—dimensions now bloom! 🌸

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)
Check name Status Explanation Resolution
Description check ⚠️ Warning The pull request description is incomplete and does not follow the provided template. It only mentions reverting a PR without addressing required sections like 'Changes proposed', 'How to test', 'Changelog entry', or the checklist items. Complete the pull request description by filling in required template sections: explain why the revert is necessary, provide testing steps, include a changelog entry, and check the applicable checklist items.
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 (1 passed)
Check name Status Explanation
Title check ✅ Passed The pull request title clearly and specifically describes the main change—reverting a previous fix for banner image dimension settings—which aligns with the changeset that removes dimension handling from General.tsx and related files.
✨ 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 revert-3019-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.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 60223f8 and 56a6af1.

📒 Files selected for processing (4)
  • assets/src/js/script.js
  • src/admin/dashboard/pages/vendor-create-edit/WpMedia.ts
  • src/admin/dashboard/pages/vendor-create-edit/form/General.tsx
  • templates/settings/store-form.php
🧰 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 (3)
src/admin/dashboard/pages/vendor-create-edit/WpMedia.ts (1)
assets/src/js/product-editor.js (3)
  • xInit (1293-1300)
  • realHeight (1292-1292)
  • realWidth (1291-1291)
src/admin/dashboard/pages/vendor-create-edit/form/General.tsx (1)
src/admin/dashboard/pages/vendor-create-edit/WpMedia.ts (1)
  • wpMedia (52-271)
assets/src/js/script.js (1)
assets/src/js/product-editor.js (4)
  • realHeight (1292-1292)
  • realWidth (1291-1291)
  • api (1304-1304)
  • xInit (1293-1300)
⏰ 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: e2e tests (3, 3)
  • GitHub Check: e2e tests (2, 3)
  • GitHub Check: api tests (1, 1)
🔇 Additional comments (8)
templates/settings/store-form.php (1)

276-283: LGTM - Banner styling reverted to use max constraints.

The styling changes appropriately use max-width and max-height with the actual banner dimensions from settings, rather than minimum fallbacks. This provides proper responsive behavior while respecting configured dimensions.

src/admin/dashboard/pages/vendor-create-edit/form/General.tsx (1)

319-321: Banner upload uses default dimensions from settings.

Calling wpMedia(setBanner) without explicit dimensions will fall back to dokanAdminDashboard.store_banner_dimension values in WpMedia.ts. This is acceptable for the revert.

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

329-332: Cropper controller with large suggestedWidth.

Changed from CustomizeImageCropper to Cropper with suggestedWidth: 5000. The large suggested width effectively allows any width, deferring actual constraints to imgSelectOptions.


192-202: Aspect ratio calculation adjusts crop region to fit image.

The logic correctly scales xInit/yInit to maintain the target aspect ratio while fitting within the actual image dimensions. This ensures the initial crop selection doesn't exceed image bounds.

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

57-76: Dimension calculation logic mirrors script.js for consistency.

The pattern of using mutable xInit/yInit, extracting real dimensions, and computing aspect-ratio-constrained crop regions is consistent with assets/src/js/script.js. This ensures uniform cropping behavior across frontend and admin contexts.


92-102: Aspect ratio adjustment correctly constrains crop to image bounds.

The conditional logic correctly determines whether to scale by width or height based on comparing image aspect ratio to target ratio, ensuring the crop region fits within the actual image while maintaining the desired proportions.


117-125: Conditional constraint application based on flex settings.

The flex flag checks correctly apply aspectRatio only when both dimensions are fixed, and maxHeight/maxWidth when the respective dimension is non-flexible. This matches the expected behavior for WordPress media cropping.


216-222: Different cropper controllers used intentionally for respective contexts.

WpMedia.ts correctly uses wp.media.controller.CustomizeImageCropper with the control parameter in the admin dashboard component, while script.js appropriately uses the base wp.media.controller.Cropper class for vendor frontend settings. This difference aligns with WordPress media API design where CustomizeImageCropper extends Cropper to handle Customizer-specific functionality.

Comment thread assets/src/js/script.js
Comment on lines +180 to +190
this.headerImage = new api.HeaderTool.ImageModel();
this.headerImage.set({
themeWidth: xInit,
themeHeight: yInit,
themeFlexWidth: flexWidth,
themeFlexHeight: flexHeight,
imageWidth: realWidth,
imageHeight: realHeight
});

controller.set('canSkipCrop', !this.headerImage.shouldBeCropped());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for the file and examine its context
git ls-files | grep -E "script\.js|customize" | head -20

Repository: getdokan/dokan

Length of output: 321


🏁 Script executed:

#!/bin/bash
# First, find the file
fd "script\.js" --type f

# Then examine its contents around lines 180-190
echo "=== Searching for api/wp.customize references ==="
rg "wp\.customize|api\.HeaderTool|var api" -B2 -A2 --type=js assets/

Repository: getdokan/dokan

Length of output: 3061


🏁 Script executed:

#!/bin/bash
# Check the file header and how it's loaded
head -n 30 assets/src/js/script.js

echo -e "\n=== Lines around 180-190 ==="
sed -n '170,200p' assets/src/js/script.js

echo -e "\n=== Search for api variable definition ==="
rg "var api|const api|let api|api\s*=" assets/src/js/script.js -B2 -A2

Repository: getdokan/dokan

Length of output: 1921


🏁 Script executed:

#!/bin/bash
# Search for where script.js is enqueued
rg "script\.js|dokan-script" --type=php -B2 -A2 | head -100

echo -e "\n=== Search for enqueue_scripts in Dokan files ==="
fd "\.php$" | xargs rg "wp_enqueue_script|admin_enqueue_scripts|wp_enqueue_scripts" | grep -i "script.js\|dokan.*script" | head -20

Repository: getdokan/dokan

Length of output: 2232


🏁 Script executed:

#!/bin/bash
# Look for the main Dokan class that loads scripts
fd "class-.*\.php" | xargs grep -l "enqueue" | head -5

# Check the assets or main plugin file
cat dokan.php | head -100

Repository: getdokan/dokan

Length of output: 2752


🏁 Script executed:

#!/bin/bash
# Look at the load_dokan_global_scripts function
sed -n '1,500p' includes/Assets.php | grep -A 50 "function load_dokan_global_scripts"

echo -e "\n=== Check full context of dokan-script enqueue ==="
rg "dokan-script.*=>|load_dokan_global_scripts" includes/Assets.php -B5 -A15 | head -100

Repository: getdokan/dokan

Length of output: 3246


🏁 Script executed:

#!/bin/bash
# Search for all places where dokan-script is enqueued
rg "wp_enqueue_script\(\s*['\"]dokan-script" includes/Assets.php -B3 -A3

echo -e "\n=== Check the context around those enqueues ==="
rg "enqueue_front_scripts|enqueue_admin_scripts" includes/Assets.php -A30 | head -150

Repository: getdokan/dokan

Length of output: 6106


🏁 Script executed:

#!/bin/bash
# Check what customize-base and customize-model are
rg "customize-base|customize-model" --type=php includes/Assets.php

echo -e "\n=== Check the full enqueue_front_scripts function ==="
sed -n '/public function enqueue_front_scripts/,/^    public function/p' includes/Assets.php | head -200

Repository: getdokan/dokan

Length of output: 8718


🏁 Script executed:

#!/bin/bash
# Let me verify: is there actually a guard at the start of script.js file?
head -10 assets/src/js/script.js

echo -e "\n=== Check if there's a guard before api usage ==="
sed -n '1,200p' assets/src/js/script.js | grep -B5 -A5 "api\.HeaderTool"

Repository: getdokan/dokan

Length of output: 676


🏁 Script executed:

#!/bin/bash
# Let me check the dependencies more carefully
# Is wp.customize guaranteed to be available when customize-base/model are loaded?
rg "customize-base|customize-model" --type=php -B2 -A2

echo -e "\n=== Search for where customize-base/model are registered ==="
rg "wp-includes/js/customize" includes/Assets.php -B2 -A2

echo -e "\n=== Check all usages of api.HeaderTool in script.js ==="
rg "api\." assets/src/js/script.js | head -20

Repository: getdokan/dokan

Length of output: 1919


🏁 Script executed:

#!/bin/bash
# Confirm the actual filename - is it dokan.js or script.js?
ls -la assets/src/js/*.js | grep -E "dokan|script"

echo -e "\n=== Check line 2 of the actual file used (dokan.js) ==="
head -5 assets/src/js/dokan.js

echo -e "\n=== Verify the structure around lines 180-190 of dokan.js ==="
sed -n '175,200p' assets/src/js/dokan.js

echo -e "\n=== Check if dokan.js is compiled from script.js or is script.js the compiled version ==="
head -20 assets/src/js/script.js
head -20 assets/src/js/dokan.js

Repository: getdokan/dokan

Length of output: 1423


🏁 Script executed:

#!/bin/bash
# Search for the context of where headerImage is used - what function/object contains it
rg "this\.headerImage" assets/src/js/script.js -B20 | head -80

echo -e "\n=== Look for product-editor.js which had a guard ==="
rg "typeof wp|wp\.customize" assets/src/js/product-editor.js -B2 -A2

Repository: getdokan/dokan

Length of output: 2283


Guard wp.customize access before using HeaderTool.ImageModel().

The code assigns var api = wp.customize; at line 2 without checking if wp.customize exists. The wp.customize API is only available in the WordPress Customizer context, but this script is enqueued on public-facing pages (store, product, account) via enqueue_front_scripts() where it will be undefined, causing runtime errors when calculateImageSelectOptions() and calculateImageSelectOptionsProfile() call api.HeaderTool.ImageModel().

Add a guard similar to the one in product-editor.js:

if ( typeof wp !== 'undefined' && wp.customize ) {
  var api = wp.customize;
  // ... use api.HeaderTool
}

Or wrap the methods that use api with conditional checks before instantiating or calling HeaderTool.

Comment on lines 306 to 311
<span className="text-neutral-400 -mt-1">
{ sprintf(
/* translators: 1) banner width, 2) banner height. */
__( 'Size - %1$s X %2$s px' ),
bannerWidth,
bannerHeight
{ __(
'Size - 600 X 325 px',
'dokan-lite'
) }
</span>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Hardcoded banner size may not match actual settings.

The banner size text is hardcoded to "600 X 325 px", but the wpMedia function (called without dimension arguments) will use dokanAdminDashboard.store_banner_dimension for cropping. If admin settings differ from 600×325, the displayed hint won't match actual cropping behavior.

Consider using the dimension values from the dashboard settings for consistency:

{ `Size - ${dokanAdminDashboard.store_banner_dimension.width} X ${dokanAdminDashboard.store_banner_dimension.height} px` }
🤖 Prompt for AI Agents
In src/admin/dashboard/pages/vendor-create-edit/form/General.tsx around lines
306 to 311, the banner size hint is hardcoded to "600 X 325 px" but wpMedia uses
dokanAdminDashboard.store_banner_dimension for cropping; replace the hardcoded
text with a dynamic string built from
dokanAdminDashboard.store_banner_dimension.width and .height (safely handling
missing values with sensible defaults) so the displayed hint matches actual
settings and continue to pass the resulting string through the localization
function.

@MdAsifHossainNadim
MdAsifHossainNadim merged commit 9fc1d2d into develop Dec 22, 2025
1 of 5 checks passed
@MdAsifHossainNadim
MdAsifHossainNadim deleted the revert-3019-fix/store-diemensions-settings-not-working-perfectly-for-new-vendor-settings-page branch December 22, 2025 06:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants