Errors JavaScript de WordPress que trenquen botons i finestres emergents

Si els botons, pestanyes o finestres emergents de WordPress deixen de funcionar, un error JavaScript és una possible causa, no un diagnòstic per si sol. Distingeix entre un element absent, un botó tapat, un script que no es carrega i un gestor que llança una excepció. Un avís de consola aliè al control espatllat no demostra l’origen de la fallada.

Si el resultat canvia entre navegadors, utilitza la guia de WordPress que funciona en un navegador i falla en un altre per comparar perfils, fitxers rebuts i la mateixa interacció abans d’encarregar una correcció.

Si el problema bloqueja consultes, reserves o compres, demana una avaluació de la interacció que falla. Envia la URL, l’acció concreta i l’últim canvi anterior al problema.

Reprodueix un únic control

Anota la URL, amplada, estat de consentiment i sessió, interacció exacta i resultat esperat. Repeteix la prova en un navegador net sense extensions.

Captura:
primera excepció de Consola
fitxer, línia i pila
peticions fallides a Xarxa
versió i memòria cau de l'script
ID o classe de l'objectiu HTML
si l'esdeveniment arriba a executar-se

Oculta dades privades, galetes i tokens.

Comença per la primera excepció

Recarrega amb la Consola oberta i interactua una vegada. Els errors posteriors poden ser conseqüències d’una dependència no definida.

Obre el fitxer des de la URL carregada i confirma que conté JavaScript, no una pàgina HTML d’error amb un tipus incorrecte. Utilitza source maps en staging si n’hi ha, sense publicar codi propietari indegudament.

Comprova dependències i ordre

Declara les dependències que utilitza realment el teu script. Aquest exemple pressuposa que ui.js fa servir jQuery; si no el necessita, no afegeixis aquesta dependència només per copiar l’exemple.

wp_enqueue_script(
    'site-ui',
    get_stylesheet_directory_uri() . '/assets/ui.js',
    array( 'jquery' ),
    '1.2.0',
    true
);

Evita còpies duplicades de jQuery. defer, els mòduls i la càrrega al peu poden canviar l’ordre; inspecciona els atributs que apareixen realment a la pàgina.

Inspecciona l’objectiu al DOM

Una actualització del tema o dels blocs pot canviar classes o generar IDs duplicats. Confirma que el selector coincideix i que el codi gestiona diverses instàncies.

Per al contingut inserit dinàmicament, utilitza delegació d’esdeveniments quan sigui adequat. No registris gestors repetits en cada actualització AJAX. Comprova alhora clic, teclat i estat ARIA.

Aïlla els efectes de l’optimització

Els connectors de minificació, combinació o retard poden alterar l’ordre o conservar un paquet antic. Desactiva una sola funció en staging i compara.

Exclou únicament l’script o dependència incompatibles que hagis demostrat, regenera recursos i versiona el llançament. El consentiment pot retardar analítica opcional, però no els controls essencials.

Revisa CSP, CORS i contingut mixt

Content Security Policy, CORS o la barreja d’HTTP i HTTPS poden bloquejar biblioteques i API. Llegeix el missatge exacte del navegador.

Ajusta CSP de manera limitada per als orígens, nonces o hashes necessaris. No afegeixis comodins ni unsafe-inline com a solució ràpida. Prioritza dependències locals mantingudes quan sigui possible.

Repara el comportament defensiu

Corregeix el component, la dependència, el selector o la comprovació nul·la a la font:

const trigger = document.querySelector("[data-dialog-trigger]");
if (trigger) {
  trigger.addEventListener("click", openDialog);
}

És un fragment il·lustratiu: openDialog ha de ser una funció definida a la teva implementació. La comprovació evita trencar pàgines sense el component, però no soluciona un HTML absent allà on el botó és obligatori.

Contén els scripts de tercers

El xat, mapes, consentiment i analítica poden fallar sense inutilitzar la interfície principal. Carrega les integracions opcionals de manera asíncrona i fora de la ruta d’inicialització crítica.

Afegeix temps d’espera i alternatives per a les API externes. No encadenis la preparació del menú o modal a una promesa de màrqueting. Tampoc no amaguis globalment tots els errors: registra una empremta segura i l’origen.

Instrumenta els esdeveniments en staging

Utilitza els panells de listeners, breakpoints i instrumentació temporal per saber quin gestor s’executa, crida preventDefault() o atura la propagació.

Retira el diagnòstic abans de publicar. Si dos connectors controlen el mateix activador, defineix-ne la propietat i els namespaces. En contingut AJAX, inicialitza una vegada cada component i neteja’l quan es retiri.

Verifica tots els estats

Prova ratolí, tacte, teclat, diversos controls, obertura, tancament, navegació enrere i contingut dinàmic en navegadors representatius. Repeteix-ho amb la memòria cau calenta.

Supervisa les empremtes d’errors del frontal després del desplegament. Que un botó sigui visible no demostra que la interacció funcioni.

Prepara evidències per a una reparació concreta

Compara la mateixa acció sense iniciar sessió i en mòbil. Anota el primer error rellevant, la URL de l’script i el resultat esperat. Per exemple, si una finestra s’obre i es tanca immediatament, comprova si hi ha dos gestors abans d’afegir-ne un tercer. És un exemple de diagnòstic, no una conclusió sobre el teu web.

Comparteix errors sense dades privades, mai contrasenyes ni exportacions de sessions del navegador. El procés de reparació explica l’avaluació i l’aprovació. Demana una avaluació si no pots aïllar la fallada amb seguretat.

Documentació de referència

Consulta la documentació de la consola de Chrome DevTools, la referència d’esdeveniments de MDN i les dependències de scripts a WordPress per comprovar el mecanisme que investigues.

Guies relacionades

• El menú mòbil de WordPress no funciona
• Enllaços permanents amb error 404 després de canviar d’allotjament