Skwirrel PIM sync for WooCommerce
| 开发者 | jkoomen |
|---|---|
| 更新时间 | 2026年6月24日 15:09 |
| PHP版本: | 8.3 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
Skwirrel PIM sync for WooCommerce connects your WooCommerce webshop to the Skwirrel PIM system. Products, variations, categories, brands, manufacturers, images, and documents are synchronised automatically or on demand.
Features:
- Full and delta (incremental) product synchronisation
- Simple and variable product support with ETIM classification for variation axes
- Automatic category tree sync with parent-child hierarchy
- Brand sync via WooCommerce native product_brand taxonomy
- Manufacturer sync with dedicated product_manufacturer taxonomy
- Product image and document import into the WordPress media library
- Custom class attributes (alphanumeric, logical, numeric, range, date, multi)
- Configurable product URL slugs (source field, suffix, update on re-sync)
- GTIN and manufacturer product code search filter on the product list page
- Scheduled synchronisation via WP-Cron or Action Scheduler
- Manual synchronisation from the admin dashboard with live progress tracking
- Date-grouped sync history (last 20 runs)
- Stale product and category purge after full sync
- Delete protection with warnings and automatic full re-sync
- Multilingual support with 7 locales (nl_NL, nl_BE, de_DE, fr_FR, fr_BE, en_US, en_GB)
- Optional integration with the WordPress 7.0 Connections Screen for centralised API key management
- WordPress 6.0 or higher
- WooCommerce 8.0 or higher (9.6+ recommended for native brand support; tested up to 10.6)
- PHP 8.3 or higher
- An active Skwirrel account with API access
安装:
- Upload the plugin files to
/wp-content/plugins/skwirrel-pim-sync/, or install the plugin directly through the WordPress plugin screen. - Activate the plugin through the 'Plugins' screen in WordPress.
- Navigate to WooCommerce > Skwirrel Sync to configure the plugin.
- Enter your Skwirrel API URL and authentication token.
- Click 'Sync now' to start the first synchronisation.
常见问题:
Which Skwirrel API version is supported?
The plugin works with the Skwirrel JSON-RPC 2.0 API.
How often are products synchronised?
You can set an automatic schedule (hourly, twice daily, or daily) or synchronise manually from the settings page.
Are existing products overwritten?
The plugin uses the Skwirrel external ID as a unique key. Existing products are updated, not duplicated.
I use a media offload plugin (WP Offload Media, S3 Uploads, …) — will the sync delete my offloaded files?
No, the sync never invokes wp_delete_attachment() on a missing-file event in 3.8.0+. When the local file is gone, the plugin only clears its own Skwirrel-side meta keys from the WP attachment record so the next sync can download fresh; the WP record itself (and any remote copy your offload plugin manages) is left untouched.
If you want to go a step further and have the sync reuse the existing WP attachment (no fresh download, no churn) when the local file is gone but the remote copy is fine, hook into the skwirrel_wc_sync_attachment_is_valid filter. The simplest implementation as a mu-plugin:
<?php
add_filter( 'skwirrel_wc_sync_attachment_is_valid', function ( $local_present, $att_id ) {
return $local_present || (bool) wp_get_attachment_url( $att_id );
}, 10, 2 );
Returning true tells the sync the attachment is still valid even though the local file is missing. The plugin ships a more thorough reference implementation (URL-equals-uploads-baseurl check) you can adapt — see the project's mu-plugins/skwirrel-offload-compat.php.
更新日志:
3.11.0
- Change: a "normal" batch sync now imports each product fully in one pass — create, categories, attributes, and images together — exactly like syncing a single product from the product screen. Previously batch sync worked in separate global phases (all products created first, then all categorised, then all imaged, …), so a run interrupted by a timeout or server limit could leave products half-built (created but without images or attributes) and a later sync would not go back to finish them. Each product is now committed completely before the next, so an interrupted run only leaves not-yet-started products, which are picked up cleanly next time. Same work, same speed — just no half-finished products.
- Safety: a newly-created product now stays a draft until its categories, attributes, and images are all in place, then goes live. This prevents a sync that is interrupted while importing a brand-new product from briefly showing an empty product on your shop. (Existing products are never affected — they are never unpublished during a sync.)
- Fix: re-syncs no longer create duplicate products with a suffixed SKU (e.g.
4250366870007-14768). When a product's SKU already exists, the sync now reuses the existing product (or, for grouped/variable products, leaves it to the grouped-product path) instead of minting a second copy. - Fix: an interrupted sync no longer "loses" products. The delta checkpoint that tracks what has been synced is now advanced only when a run fully completes (and is stamped with the run's start time), so a run that dies partway through is simply re-done next time instead of silently skipping the products it never finished.
- Fix: the live "Sync in progress" panel now shows the steps that actually run (Fetch, Create & sync products, Finalize variable products, Link related products, Cleanup) instead of the old phase list, so steps no longer appear stuck and the counts make sense.
- Change: re-syncs now report products as "unchanged" instead of marking every product "updated". A product counts as updated only when it actually changed in Skwirrel (its update timestamp advanced) — not just because a sync ran. Unchanged products are skipped (no re-save), so a repeat sync of a mostly-unchanged catalog finishes in seconds, and the result shows a new "Unchanged" count. Changing a sync setting (or upgrading the plugin) automatically reprocesses everything once.
- Fix: the internal
wp_skwirrel_sync_queueworking table no longer grows without bound. This table is temporary scratch space used during a sync, and is cleaned up when a run finishes. Runs that ended abnormally — a fatal error, an out-of-memory kill, a server timeout, or a hard-killed process — left their rows behind, and over time these accumulated and could fill the disk. Each sync now sweeps away leftovers from earlier interrupted runs at the start, and cleanup is hardened to run on every failure path, so the table stays small automatically. (No product data is affected — this is purely temporary working data.)