Description
Print-on-demand sync fails quietly. Products stop appearing, orders do not reach the supplier, and the error message — when there is one — says nothing you can act on. The worst version of it is silent: a customer pays, the order sits in your shop, and nobody is making it.
Most of the time the cause is not the integration. It is one of six things on your own side of the connection, and all six can be measured without any supplier credentials at all. This plugin measures them and tells you, in plain language, what is wrong and what to do about it.
It is a diagnostic tool. It does not sync anything, it does not connect to any supplier, and it never asks for an API key.
What it checks
-
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.
Works alongside
This plugin sits beside whatever integration you already use. It is compatible with stores running the WooCommerce integrations for Printful, Printify, Gelato and other print-on-demand suppliers, and it is useful whether or not you keep them. It changes nothing about your setup: it reads, measures and reports.
What it does not do
It cannot prove that a supplier’s servers, somewhere else in the world, can reach your shop. That test needs a request from outside your hosting, and this plugin makes no outside requests.
It cannot tell you whether an order that was collected was then accepted or rejected at the supplier. That answer is not on your server.
It fixes nothing by itself. Every finding says what to do; you do it.
It tells you all of this on the page, rather than implying a certainty it does not have.
External services
This plugin contacts no external services. The only network requests it makes are to your own site’s REST API, at your own domain, in order to test whether it answers. No data leaves your server.
Screenshots
Installation
- 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.
There are no settings to configure. If any orders are found stranded, a warning also appears on your dashboard and on your orders screen, because that is the one finding that costs money while nobody is looking at it.
FAQ
-
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 things, both WordPress transients, both temporary. One is a cached count of stranded orders, so the dashboard warning does not run a database query on every admin page; it expires within the hour. The other records that you clicked “Hide for a day” on that warning, and expires in a day. Deactivating the plugin deletes both.
-
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.
-
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.
Reviews
There are no reviews for this plugin.
Contributors & Developers
“OrderGuard for Print on Demand” is open source software. The following people have contributed to this plugin.
Contributors
Translate “OrderGuard for Print on Demand” into your language.
Interested in development?
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
Changelog
1.0.1
- Added the plugin home page link to the plugin header. No functional changes.
1.0.0
- 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.