OrderGuard for Print on Demand
| 开发者 | epicshift |
|---|---|
| 更新时间 | 2026年9月4日 02:16 |
| PHP版本: | 7.2 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
- Which paid orders were never collected? Your supplier does not receive orders — it comes and fetches them, through the WooCommerce REST API, using a key WooCommerce keeps a "last used" date for. So your own database knows the last time anyone came to look. An order that is still waiting to be fulfilled, was placed after that visit, and has been sitting for over a day, was collected by nobody. This check names those orders and adds up the money in them. It needs no credentials to do it, because none of it happens at the supplier.
- Is your REST API answering? Supplier integrations register REST routes and expect the supplier's servers to call into your shop. This is the single biggest source of "sync failed" and of 404 errors during sync. The check asks your own REST API for a response, separates a TLS problem from a firewall problem, and confirms that the WooCommerce namespace is present. It runs from your browser rather than while the page is loading, so it can never freeze your admin — on hosting with a single PHP process, a site cannot answer its own request while it is still building a page.
- Are your permalinks set to Plain? The WooCommerce REST API does not work with Plain permalinks. Sync fails with 404 and nothing explains why. One setting, one fix.
- What is standing in front of your REST API? Security and caching plugins are the usual culprits, and the fix is almost never to remove them — it is one specific setting in one specific plugin. The check names the active plugins that are known to interfere and says which setting to open in each. It also reads the WordPress REST filters directly and names the code hooked onto them, so a block can be traced even when it comes from a snippet rather than a plugin.
- Are your PHP limits big enough for your images? A generic "your memory limit is low" warning helps nobody. This check measures the largest product image actually in your catalogue and compares it against what this server accepts, and it flags an execution limit short enough to cut a sync run off part way through. That is what "it only syncs half the time" looks like from the inside.
- What did an interrupted sync leave behind? Duplicate SKUs make suppliers overwrite or skip the wrong product. Orphaned variations stay in the database, invisible in the admin, and break matching at order time. Both are the residue of a sync that failed and was run again.
- "No products are configured in Printful. Order was not imported." — the four causes, in order of how often they happen.
- Printful sync not working, with a 404 error — permalinks, security plugins and hosting, and how to tell them apart.
- Paid orders that were never sent to the supplier — the silent failure, and how to find it without credentials.
- "There are no shipping options available" at checkout — the error that loses the sale without leaving a trace.
安装:
- Install and activate the plugin.
- Go to Tools > OrderGuard.
- Read the results. Failures are listed first and opened; anything that passed is folded away at the bottom.
屏幕截图:
常见问题:
Do I need an API key from my supplier?
No. Every check runs against your own site. That is the point: you can find out what is wrong before involving anyone.
How do I know this plugin is safe to run on my shop?
By checking, rather than by trusting us. It asks for no keys, no account and no credentials of any kind. It contacts no external service: the only request it makes is to your own domain. It writes nothing to your products, your orders or your settings. The source is plain, commented PHP with no build step and no minified files, so you or your developer can read every query it runs before you run it. And where a check cannot prove something, it says so on the page instead of guessing.
Will this fix the problem for me?
No. It tells you what is wrong and what the fix is. The fixes are settings changes, and most of them take a minute; a few need your host.
Does it change anything on my site?
It writes nothing to your content. It reads settings, PHP configuration, product metadata and order line items, and it requests your own REST API root. It keeps two temporary things and three tiny permanent ones, and deactivating the plugin deletes all of them. The temporary ones are WordPress transients: a cached count of stranded orders, so the dashboard warning does not run a database query on every admin page (expires within the hour), and a record that you clicked "Hide for a day" on that warning (expires in a day). The permanent ones exist so the plugin can ask you for a review politely instead of immediately: the date you first ran it, how many times it has run, and your answer if you dismissed the ask. No content, no orders and no settings of yours are ever written to.
An order shows as never collected, but my supplier has it. Why?
Two possibilities. Your integration may collect orders in a way this check cannot see, in which case the finding is wrong and worth telling us about. Or the order was collected in the last day, which is inside the grace period the check allows before it reports anything, and something else changed its date. The check errs towards silence: an order is only reported when it is still waiting to be fulfilled, was placed after the last recorded visit, and has been waiting more than 24 hours. Fresh orders are never reported, because suppliers poll on their own schedule. One more thing it cannot separate: an order containing a supplier product that you decided to make or ship yourself looks identical from here.
There are more stranded orders than it lists. Is it hiding some?
No, and it says so on the page. It examines the 200 oldest orders in the window and names the 20 oldest of those, because two hundred bullet points is a wall rather than a finding. When it stops at either limit it prints a line saying the total is a floor and not a count. A diagnostic that quietly stops counting reads exactly like one that found everything, which is worse than useless.
It says "No products are configured in Printful. Order was not imported." What does it mean?
It means the integration looked at the order and found no product in it that it recognises as one of its own. There are four causes, and they are worth checking in this order: the product was never linked to the supplier's copy of it, the link was lost when a sync failed part way, the product was created directly in the shop and the supplier has never heard of it, or the integration cannot reach your shop at all. The REST API, permalink and leftover checks in this plugin cover the last two. The full walkthrough, with how to confirm each cause, is at orderguard.dev/fix/order-was-not-imported-printful.
Sync stopped working and I see a 404 error. Why?
A 404 during sync means the supplier's servers called into your shop and your shop answered "no such page". The usual causes are permalinks set to Plain, a security or firewall plugin standing in front of the REST API, or hosting that cannot answer a second request while it is building a page. Checks 2, 3 and 4 measure exactly these, and the guide at orderguard.dev/fix/printful-sync-not-working-rest-api-404 explains how to tell them apart.
My checkout says "There are no shipping options available". What now?
That error appears at checkout when no shipping method answers for the customer's address, and with print-on-demand it usually means the integration failed to return live rates at that moment. It is the most expensive error on this list, because the customer is standing at the till and leaves. The two-minute protection is a flat-rate fallback in the shipping zone, and the guide at orderguard.dev/fix/no-shipping-options-available-print-on-demand walks through it.
All the checks pass and sync still fails. Now what?
Then the cause is not in your hosting or your catalogue — it is at the supplier or inside the integration plugin. That is worth knowing: it means the time you would have spent changing settings is time you can spend on a support thread instead. Copy the report from the bottom of the page and paste it there.
The REST API check says it could not finish. Is that a bug?
No, and it is worth reading carefully. It means your server did not answer its own request within eight seconds, and there are two possible causes: something is blocking the request, or your hosting has too few PHP processes to answer a second request while it is still working on the first. Both of them break sync, so neither is a false alarm. The check tells you how to tell them apart.
Does it work without WooCommerce?
Partly. The REST API, permalink, blocking-plugin and PHP-limit checks all run. The order and catalogue checks need WooCommerce and will say so.
Is there anyone at the other end of the support forum?
Yes. Topics on this plugin are read. No promise is made about how fast, because a promise about response time is one we would eventually break, and that is worse than not making it.
更新日志:
- The results page can now ask for a review, and only once it has earned the right to: after at least two runs, at least a week of use, and never while a check is failing. "No thanks" hides it for ever. Nothing else about the checks changed.
- Readme: linked the guides to the errors the plugin diagnoses, and answered the three error messages shop owners actually search for.
- Added the plugin home page link to the plugin header. No functional changes.
- First release. Six checks: paid orders never collected by the supplier, REST API reachability, permalink structure, interfering plugins, PHP limits measured against your real product images, and duplicate SKUs and orphaned variations.