Mc Print 2 keeps printing copies of the same order over and over again

i’m having the same issue, I was told it’s my hosting (godaddy) but they cannot seems to get it sorted ??

I called godaddy and they said to specify what they can change on their end and they will be happy to….but this doesn’t seem to be linked to that.

Seems like something else…

Mine is like this out of the box and I have 6 more to setup….
clients waiting…..sales waiting….money waiting….
you get it.

Working round the clock to look for a fix here.

Someone pls help!

editing the cloudprint.php disconnects the printer
editing order-handler.inc.php with exit on several lines causes the printer to stop printing all together
ran database query wp_dhxystbnd2_options
search string batman – everything checks fine
tried changing ntp settings nothing is really effective and doesn’t like medium security

notes gathered:
cloudprint.php. – Line 225 cloudprint.php. is the issue –
// POST requests from the printer come with a JSON payload

– the server is not deleting previous files
– because it does not know whether a print is finised
– also its not just 6 copies it just keeps on making copies
– we need to find out if the printer is requesting the server url you put in the backend after its done printing a memo
or its being blocked in some way`

*currently working on monitoring url logs – tomm

Please help on this issue and prehaps exact directions on what changes are required on hosting end if any.

Looking forward to a fix.

@rsgdynamics @lunacaffe54

Essentially, there are two potential causes of re-printing. Either the printer is unable to inform you server that it has completed printing (usually an http caching issue) or, your web server is prevented from deleting the local print job file (a user permissions issue).

Both of these are somewhat out of our hands, but the caching issue is by far the more frequent cause (a file system permission issue will generally cause other problems too, like being unable to remove other plugins). Our http responses already include the necessary headers to prevent caching, but some services do so regardless.
In most cases, asking your hosting company to disable all http caching for your CloudPRNT URL will resolve the problem. I am looking into options that will help us to work around http caches that do not honour the header requests (such as ensuring that the request URL contains a query parameter that changes for each request.

Since you are looking at the code and logs, let me explain the basic CloudPRNT protocol, so that you can see what is missing.

• Firstly, the printer will regularly make an http POST request to your server with some JSON data, and expecting a JSON response. This POST is sent whenever the printer status changes (e.g. if you open the paper cover, or if you run out of paper), and on a regular timed interval. The POST is used to inform your server of the current printer status, and also to allow your server to print.
  If there is a job to be printed, then the server will indicate this in the JSON response.
• If your server indicates that there is a job to be printed, then the printer will request this using an http GET request, to download the print job data from the server.
• When the printer has completed the print job, it will then typically send an http DELETE request to the server, to request that the job is removed from the print queue. However, since we found that many WordPress hosts do not accept DELETE requests, the WooCommerce plugin sets a flag in its JSON responses to ask the printer to use an http GET request (with a “delete” query parameter) instead.
• If printing failed for any reason (usually paper ran out, or the cover was opened before the job completed) then the DELETE/GET will include an error code to inform the server of this also, but the printer may also issue another GET to try to print the job again too, depending on the nature of the print failure.

So, it seems very likely that your server is not receiving the http GET that is used to confirm the print job completion. I’m sure that this is most likely caused by some traffic filter/caching, because the request will usually look identical every time when confirming a successful print (the GET would be issued to your CloudPRNT URL, with a query string of ?delete&code=200&mac=<printermac>, where <printermac> is the Mac address assigned to your printers Ethernet, which is also used as a per-printer identifier.

Hello Lawrence,

After applying all caching changes you requested.
we have confirmed the printer is not sending a clear get command
or a complete get command at all. Including adding the Mac address to the hosting didn’t make any changes. The printer continues to print multiple copies even if I go to the back and trash all transactions and create a new order the printer prints the previous one multiple times.

conclusion:
1) the printer hardware is faulty
– which I can check tomorrow as I have 5 other units that need to be setup still, to rule that out
2) the printer is not sending any clear que or clear complete commands
3) there is a fault in the software
4) there is a fault in the plugin

Here’s the response from GoDaddy hosting:

You asked for help. Here it is.
Thanks for talking with me, GoDaddy Customer. You're off to a good start. The info I mentioned will help you take your next step. You'll find it all here:

Website Security and Backups may be helpful to you. Here's a link: Website Security and Backups currently the Realtime tracking system is not showing any requests with a delete tag coming through the system. this tells us that the printer is not sending clear requests to the site in a way that it understands or to the right ip address. the dns records from server to web has been scanned showing no issues with tracking. also added delete methods to caching with no effect as well as new non cache url code with no effect. 

If you need anything else, we're here to help.

Thanks,
Help 2.0

Heres a list of the transactions from realtime:

https://ibb.co/H2DYJdv

Please help as I am trying to get this figured out around the clock.
Appreciate your time in this matter.

Regards,

RSG

@rsgdynamics

A printer fault that allows it to send http POST requests, but not GET requests is extremely unlikely, of course it must have sent at least one GET request to receive the print job that is re-printing (and, it does this for every reprint, so something is responding to its GET requests with print job data). However, of course nothing should be ruled out.

This is really very typical of caching/filtering services (are you using any intermediary filtering service such as cloudflare?) which typically will not cache responses to POST requests, but will often cache a GET. In the case that a caching service is responding to the GET automatically, this will not be passed on to your server, so it can be hard to detect from either just the printer end, or the web server/application end.

Still, I think that is is essential to rule out any printer issue. The WordPress forum rules do not allow me to exchange direct contact information, but if you contact your regional Star Micronics office technical support, then they will be able to provide temporary access to a Star hosted CloudPRNT service in order to test your printer.

They may also, with your permission, be able to connect one of their printers to your site to see if the same issues occur.

Hi Lawrence,

I tested a new printer on a different shop all together. Client has similar product with hosting as the previous. Brand new and guess what?

SAME ISSUE IT PRINTS MULTIPLES
-NEW PRINTER
-DIFFERENT ONLINE SHOP
-DIFFERENT ACCOUNT
SAME ISSUE

• This reply was modified 3 years, 5 months ago by rsgdynamics.
• This reply was modified 3 years, 5 months ago by rsgdynamics.

NO CLOUDING SERVICE like cloud fare JUST CloudPRNT directly with wordpress

Please advise what it is exactly that hosting has to do.

As far as credentials I can provide those.

Hope to hear back soon im being pushed back on my installs quite a bit here.

I also have a lot more printers to setup and if this an issue that needs to be resolved we need this fixed asap so that I can deliver.

Kind Regards,

RSG

• This reply was modified 3 years, 5 months ago by rsgdynamics.
• This reply was modified 3 years, 5 months ago by rsgdynamics.

Hi Lawerence,

we have tried to update folder permissions and everything
haunt tried to stop troubleshooting
I really need to deliver the products

no one is getting back to me form the team
pls send me an email you can get it form Ahmed Zeedia form integrations.

I can give you all and any credentials you need to figure out the issue.

!) its not sending the commands clear or complete
2) its sending it and its being stopped somewhere

I have called go-daddy 6 times and they are trying to refer me to wordpress support which I know its not because of all the troubleshooting already done.

Pls help I need to figure this out soon I have almost 3k worth of just these printer sitting here waiting to be connected.

Regards,

RSG

I found a previous post month ago, saying godaddy is not clearing the catch automatically and that why the printer is getting stuck and print the same receipt over and over again, but despite many attempts they never sorted. I moved the server for a week and the printer was working perfectly fine so in my case definitely related to the host

@rsgdynamics

I’m sorry you are having so much trouble. The problem fundamentally is that http GET requests are being cached and so automatic responses are being sent back to the printer, instead of being passed on to your site and handled by the plugin. This caching is performed either by your webhost (GoDaddy), or by an intermediate traffic filter (i.e. if you have your site behind a service such as Cloudflare?).

I wish I could tell you how to disable that, but there are literally thousands of WordPress hosting options and we are not able to know the details of them all.

You are right, this is almost certainly not a WordPress issue, but a general hosting issue. In my experience, modifying the caching behaviour is something that can only be configured by the hosting company. There are a few examples in this forum of people with similar issues, until their hosting company added a cache exclusion for their sites cloudprnt URL.

I’m sure that you will hear back from Star tech support now that the weekend is over, could you let me know where you are based, and which office you contacted? I can ask them to expedite your request. But in reality, they can help verify that the printer is not faulty (which I’m now very confident is not the issue here) but also will have very limited ability to support you with hosting side issues.

Please don’t pass any account details over this forum, it would violate the forum rules.

However, if you can let me know what type of GoDaddy hosting account you have and in which region, I will talk with them directly too. I’d like to figure out both how customers can easily get the right support to resolve it, and also if there are any additional steps that our plugin can take to avoid it.

@lunacaffe54 Thank you for the confirmation. It is good to know, even if the situation isn’t ideal.

Hi @rsgdynamics,

My name is Guillermo and I work along side Ahmed at Star Micronics America. I’ve been discussing your issue internally with Ahmed and I’ve passed along my suggestions which are not that different from Lawrence suggestions (caching on host). In fact, most of our suggestions come from Lawrence since he is main plugin contributor.

I’m confident that his assessment regarding the caching is accurate; as he’s mentioned we’ve seen several others with this issue. Unfortunately, there really isn’t much we can do, but if you want to test it on another web host, I can set one up. I use Dreamhost and I have never experienced such an issue. That’s not to suggest that Dreamhost is better, rather that issues can vary between hosts.

Guys!!

I figured out the mess that had been caused.

Im still in the work arounds of fixing it and will advise once im done.

So maybe others can benefit form the answer as well.

On the other hand I appreciate your detailed feed back both from lunacaffe54, Lawrence and Guillermo. Thanks guys

In the meantime maybe its also best to keep working on header timing and ensuring that the request URL contains a query parameter that changes for each request.
I know this is a big task and lots of coding is involved so I wish you best.

However for the time being you can rest assure the issue has been narrowed down and its not the equipment at all.

I will be in touch with an update once I have this all sorted out.

Regards,

RSG

The issue is resolved appreciate your feedback and support. Keep on keeping on and hopefully headers won’t be an issue of the future that require such drastic moves. Happy printing!