Si el botó de comanda de WooCommerce no fa res, comprova primer si està deshabilitat, si la validació atura el checkout i si el navegador envia una petició. Són fallades diferents. L’aspecte del botó no permet saber tot sol si ja existeix una comanda o un pagament.
Si els clients no poden comprar, consulta el servei de reparació del checkout. Envia la URL, el mètode de pagament i el símptoma exacte per avaluar el cas; evita demanar clics repetits mentre el resultat del pagament sigui incert.
Identifica el checkout clàssic o el bloc de pagament
El checkout clàssic sol enviar mitjançant ?wc-ajax=checkout; el bloc utilitza la ruta de checkout de Store API, com ara /wp-json/wc/store/v1/checkout. Inspecciona la petició real de la botiga.
Al bloc, calcular enviaments o totals pot deshabilitar temporalment el botó. Aquest estat no demostra que l’esdeveniment de clic estigui trencat. Comprova què continua pendent abans de forçar-ne l’activació.
Defineix què significa “no fa res”
Prova una vegada en una finestra privada. Anota si canvia el botó, la pàgina salta cap a un camp, apareix un error a Console o Network envia el checkout.
Revisa també les comandes recents i el panell de la passarel·la. Un client pot dir “res” encara que la pàgina hagi fallat després del cobrament.
Protegeix contra duplicats abans de demanar un altre intent.
Comprova si el botó rep el clic
Comprova si el control està tapat, deshabilitat o vinculat al component de checkout esperat. Al checkout clàssic, revisa la relació amb el formulari; un selector d’aquest formulari no serveix tot sol per diagnosticar el bloc. Utilitza el selector d’elements per localitzar una capa que intercepti el clic.
/* Només per a diagnòstic local o staging */
.capa-sospitosa {
outline: 3px solid red;
pointer-events: none;
}No deixis aquest CSS a producció: pot inutilitzar controls de consentiment o accessibilitat.
Llegeix el primer error del navegador
Obre Console, recarrega i prem una vegada. Investiga el primer error nou; els següents poden ser-ne conseqüències.
Les fonts habituals són connectors de camps, el tema, l’autocompleció, el consentiment o JavaScript comprimit. Un objecte indefinit, un error de jQuery o un script bloquejat és una pista millor que desactivar-ho tot.
Comprova CSP i les extensions del navegador. Repeteix amb un perfil net abans de modificar la botiga.
Inspecciona camps i validació
WooCommerce pot impedir l’enviament per un camp obligatori mentre el CSS amaga l’avís o el desplaçament. Cerca aria-invalid="true" i contenidors d’error a la part superior.
Els camps propis necessiten un nom únic, un valor vàlid i la mateixa validació al servidor. Prova adreces, telèfons i codis postals corresponents al país seleccionat.
No eliminis globalment la validació només per superar una prova.
Confirma l’esdeveniment i la petició
Filtra checkout a Network i prem. Si no surt cap petició, el problema continua al layout, JavaScript o validació. Si existeix i retorna error, analitza’n l’estat i el cos: ja no és un error del botó.
Si comença l’enviament final però la interfície no acaba, segueix el diagnòstic del checkout que continua carregant i llegeix-ne la resposta abans de canviar el handler del clic.
Cerca handlers que cridin preventDefault() sense reprendre el checkout. Revisa condicions segons el mètode de pagament, l’acceptació de termes o els camps dinàmics.
Comprova que no hi hagi dos formularis amb el mateix ID.
Aïlla la integració responsable
Reprodueix el disseny a staging amb el mateix tema, tipus de checkout i dades pertinents. Desactiva primer la combinació de scripts si n’amaga l’origen i prova després una integració cada vegada.
Canviar temporalment a un tema estàndard pot demostrar que hi intervé, però no és la reparació final. Localitza la plantilla, el selector o l’script concret.
Conserva evidències i una via de reversió de cada prova.
Repara sense debilitar el checkout
Corregeix el selector, handler, z-index, marcatge invàlid o ordre de càrrega. Restaura els controls de consentiment, frau i pagament que hagis aïllat.
No utilitzis snippets que habilitin contínuament el botó: poden permetre comandes incompletes o múltiples.
Purga només la caché del recurs afectat i confirma que el fitxer corregit arriba a un visitant sense sessió.
Verifica totes les rutes del client
Acorda el mètode de prova abans de començar: entorn de proves i sandbox de la passarel·la quan siguin compatibles, amb comandes de prova identificades. Comprova convidats, comptes, mòbil, teclat, errors de validació i mètodes de pagament actius. Verifica l’estat de la comanda, resultat del pagament, estoc i confirmació esperats per a aquell mètode; una comanda pendent de pagament no té el mateix estat esperat que una de pagada.
Abans de qualsevol prova real, acorda qui autoritza el càrrec i en gestiona les conseqüències. Les comprovacions periòdiques han de registrar fallades i resultats esperats sense crear vendes reals silenciosament.
Què enviar per avaluar el checkout
Envia URL, dispositiu, tipus de checkout, mètode de pagament, hora aproximada i última actualització. Indica si el botó continua deshabilitat, mostra un error o envia una petició. Afegeix una captura o registre sense dades privades. Mai no enviïs números de targeta, contrasenyes ni una exportació completa de la sessió del navegador.
El procés de reparació explica avaluació, abast i aprovació. Demana una avaluació del checkout si no pots aïllar la fallada o conciliar comanda i pagament.
Documentació de referència
Contrasta el flux del bloc de checkout i la referència de Store API amb la implementació. La guia de diagnòstic de WooCommerce orienta les proves de conflictes.