Repository navigation
PHP fix 10/10: cURL and JSON errors — separate network failure, HTTP status, and response data #20
vistabylara-dev
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
نجاح الاتصال وحده لا يعني نجاح العملية. افصل أخطاء الشبكة عن حالة HTTP وعن صحة JSON قبل متابعة أي إجراء.
Free code series · Topic 17/50 · PHP fix 10/10
The problem
An app assumes any response is usable JSON. A timeout, HTTP error page, or structurally wrong JSON can then break the workflow or produce a false success message.
Where this belongs in Shopify
PHP runs in an external app, integration service, or server you control. Shopify themes use Liquid, HTML, CSS, and JavaScript; do not paste this PHP into a theme section or Custom Liquid block. If a third-party app owns the failing server, share a sanitized error with that app's support team.
Placement and free suggested code
Save as response-check-demo.php in a PHP development directory. This example uses fixtures and sends no network requests. In an existing cURL client, capture transport failure before passing the received HTTP status and body to this validator.
response-check-demo.php
Verify before using it
Test HTTP 200 with an object, 500 with HTML, 200 with malformed JSON, and 200 with an array or null. Only the object passes this structural guard. An empty 204 body is rejected by design: use an endpoint-specific path for legitimate no-content responses. An object containing an application error can still pass; validate the actual endpoint schema and business outcome next.
What was checked for this guide: The demo ran in a PHP WebAssembly CLI runtime. Local fixture checks passed; this is not a test of your host, store, production workflow, or every failure mode.
Precautions and rollback
For cURL, use CURLOPT_RETURNTRANSFER and check curl_exec with === false; a 404/500 is not automatically a cURL transport failure. Set connect and total timeouts appropriate to your service and leave TLS verification enabled. Never blindly retry payment or order writes after a timeout—the result may be uncertain. Reconcile the operation and use supported idempotency controls. This parser does not authenticate a webhook or verify payment.
Back up or commit the existing application before adapting anything. Test on a development copy with dummy data. Restore the previous application version if behavior regresses; reverting code does not undo database writes or external actions. These are educational suggestions, not a universal drop-in repair.
Check the ecommerce workflow
After adapting a fix, verify the affected operation from input to its intended result in your test environment. Check failure handling as well as success. Do not mark a sale or analytics purchase event merely because a PHP script finished. Payment/order state and analytics reporting need their own checks, and repeated requests must not duplicate side effects.
Official references
Share your error and join the free discussion
Comment with the exact error text, PHP version, whether this is your own app or a third-party app, and a short sanitized code sample. Remove passwords, tokens, customer details, and private server paths. What happened just before the error?
Need free Shopify guidance or a free consultation? Call +971 50 799 4292 or message Dr Lara on WhatsApp.
Free guidance. No commitment. No package to sell.
Dr Lara · Dubai, UAE
All reactions