| 开发者 |
cratesdigital
ahmd3tf |
|---|---|
| 更新时间 | 2026年8月8日 07:11 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
product post type.product-image-processor folder to the /wp-content/plugins/ directory, or install directly from Plugins → Add New by searching for "Crates Product Image Processor for WooCommerce."No. Processing only triggers for uploads made directly on a WooCommerce Product edit screen. Everything else is left exactly as uploaded.
No. Background removal is anchored to the edges of the image and only travels through background that is connected to a corner, so it stops at the product's outline. Areas of the same colour that sit inside the product — a white label, white packaging, a bright highlight — are preserved. (If you are upgrading from 1.3.0 or earlier, this was not the case, and any images processed by those versions may need to be restored from their backups and re-processed. See the 1.3.1 changelog.)
A copy of the untouched original is saved automatically before processing, in a dedicated subfolder inside your site's uploads directory (wp-content/uploads/cdpip-originals/). The folder ships with an .htaccess file that blocks direct access on Apache; on nginx you will need an equivalent location block in your server config, since nginx ignores .htaccess. Uninstalling the plugin does not delete these backups.
If you re-process an image that has already been through the plugin, the existing backup is kept as-is rather than being replaced with a copy of the already-processed file.
Adjust the "Trim Tolerance / Fuzz" setting. Lower it if the trim is too aggressive and removing parts of the product; raise it if too much background is being left behind. Trimming works inward from the edges and stops as soon as it meets the product, so a generous value here is safe.
That is the "Background Removal Tolerance" setting being too high for that product. The two tolerance settings do very different things. Trimming crops the outer margin and stops at the product. Background removal spreads inward from the image corners, so if the tolerance is wide enough to include the product's own colour, it will flow out of the backdrop and into the product. This mostly affects light-coloured products — silver, white, pale grey — photographed on a white backdrop, where the body may be only 10-15% away from the background colour. Lower the setting (the default of 6% is safe for almost everything), or set it to 0 to skip background removal entirely and keep the trimmed image exactly as-is. The plugin also checks this automatically: before committing, it measures whether the configured tolerance is spreading further than a thin edge halo could account for, and reduces it if so. When that happens it is noted in your server error log.
Yes — the PHP Imagick extension. Most managed WordPress and WooCommerce hosts include this by default. If it isn't installed, the plugin will simply skip processing rather than break your uploads.
Yes — go to Media → Bulk Process Images, select the specific images you want processed from the Media Library picker, and run them through the same processing pipeline. You choose exactly which images are affected; nothing is processed automatically. This also regenerates the image's thumbnail sizes afterward, so everything stays consistent across your site.
Administrators and Shop Managers (anyone with the manage_woocommerce capability). It used to require only upload_files, which Authors also hold — too broad for a tool that overwrites files used across the whole site. Developers can adjust this with the cdpip_bulk_capability filter.
Only if you've explicitly enabled the "Upscale Small Images" setting. By default, images smaller than the canvas area are kept at their original resolution and centered rather than stretched.
cdpip_background_leak_tolerance filter.original_image metadata key, which broke wp_get_original_image_path() and orphaned -original files on disk.Requires Plugins, Requires at least, Requires PHP and Text Domain to the plugin header. The WooCommerce dependency was declared only in readme.txt, where WordPress does not read it, so it was never actually enforced.jpeg_quality filter instead of falling back to Imagick's default.scaleImage() bestfit — sharper downscales, and predictable behavior for the "upscale small images" option across Imagick builds.manage_woocommerce rather than upload_files, filterable via cdpip_bulk_capability..htaccess blocking direct access on Apache.uninstall.php, and text-domain wrapping throughout.