- This topic has 6 replies, 2 voices, and was last updated 10 years, 7 months ago by .
Viewing 7 posts - 1 through 7 (of 7 total)
Viewing 7 posts - 1 through 7 (of 7 total)
- You must be logged in to reply to this topic.
Support site for Tips and Tricks HQ premium products
by
Tips and Tricks HQ Support Portal › Forums › WP PDF Stamper › WP PDF Stamper Troubleshooting › 502 Error with PDF Stamper Plugin
Tagged: pdf stamper, suPHP
Hi,
I am getting 502 Gateway error with PDF Stamper Plugin. I am using latest WooCommerce and latest version of PDF stamper plugin.
Website is hosted on Asmallorange and the destination server for both source and stamp file is the same.
What could be the issue causing this?
Update – I switched to Method 3 on File Path Conversion Method and it worked.
Another question, although I am not sure if a new thread is to be created. Please bear with me.
Before PDF stamper was being used, the PDF files were asked to be downloaded directly after clicking the links in the email. However, with this magnificent plugin, PDF files are opening in the browser. We have some trouble with this since most of our PDF files are of 50MB+ and customers have broken downloads or browser hangs due to large size of the file.
All we want is that they should be asked to directly download the PDF file after clicking the link.
Please suggest a way out.
Thanks
Hi,
Force Downloading Works. But 502 Errors are still pushing across even after disabling Caching of pdf files in nginx. I use Asmallorange. Please help
I hope you aren’t trying to use the $35 a year plan…
Okay, how much PHP memory do you have? It should be about 256 MB.
And are you able to successfully stamp the files manually?
Also, since you mentioned caching, are you using a CDN? CDN don’t work, with PDF Stamper:
https://support.tipsandtricks-hq.com/forums/topic/502-gateway-error-on-wpengine
Hi Again,
I am using a Cloud VPS by ASmallorange for $300/yr so mostly this isn’t the issue.
Additionally, the memory is set to 256MB. I contacted their tech support and they fixed the issue by re-compiling using SUPHP and now it works great!
Thanks for help.
It actually wasn’t “recompiling.” Apparently your hosting provider has some rather “uber security settings” turned on. suPHP merely allowed everything to execute at the proper permission levels: