Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Comportament Formulari Wordpress

Una actualització del plugin de formularis trenca els enviaments

Recupera formularis després d'actualitzar conservant evidències, revisant logs, compatibilitat, rollback i integracions.

Un error detectat després d’actualitzar pot procedir del plugin principal, un add-on dependent, una validació més estricta, incompatibilitat amb PHP o recursos front-end antics. La coincidència temporal és una evidència útil, però no justifica una reversió improvisada.

Protegeix els leads nous, reprodueix l’error i troba la recuperació compatible més petita.

Registra el canvi i l’estat actual

Anota la versió anterior i l’actual del plugin, l’hora de l’actualització, les versions de WordPress i PHP i tots els complements relacionats. Conserva changelogs, registres de l’allotjament i una còpia de fitxers i base de dades abans d’editar.

Fes un enviament sintètic i registra la pàgina, l’ID, l’hora, la petició del navegador i si s’ha desat una entrada.

No buidis tots els registres i memòries cau abans de capturar l’error original.

Ofereix una ruta temporal per als leads

Si el formulari no és fiable, mostra una adreça supervisada o un telèfon i demana al personal autoritzat que revisi les entrades desades. Retira l’avís només quan el lliurament complet estigui comprovat.

No insereixis un altre formulari sense verificar que no depengui de la mateixa ruta de correu trencada. Protegeix les dades i no exportis entrades completes per correu ordinari.

Documenta l’interval de l’incident per reconciliar consultes perdudes.

Llegeix l’error real

Inspecciona la petició i la consola, i correlaciona l’hora amb PHP, WordPress, servidor web i seguretat. Un 500 exigeix l’excepció concreta; un 403 apunta a nonce, CAPTCHA o firewall; un enviament normal sense correu requereix rastrejar la notificació.

Revisa també els registres i les eines de salut del plugin. Mantén ocult el debug públic i redacta rutes, tokens i valors personals.

La primera capa fallida determina la prova següent.

Comprova add-ons, tema i codi propi

Els complements de pagament, camps condicionals i hooks poden cridar API modificades per l’actualització. Compara’n les versions compatibles i les notes de llançament oficials.

A staging, aïlla el complement sospitós reproduint la mateixa ruta. En producció, entén si desactivar-lo eliminaria camps, tasques, entrades o protecció abans d’actuar.

Busca hooks obsolets al codi propi i conserva una reversió per a cada canvi PHP.

Descarta recursos i caché antics

Un backend PHP actualitzat pot conviure amb un JavaScript antic en memòria cau, o els recursos nous poden combinar-se en un ordre incorrecte. Compara les versions carregades a l’HTML i revisa la consola.

Purga només la pàgina, l’objecte CDN i el fitxer optimitzat afectats després de demostrar la discrepància. Prova sense sessió i en mòbil, perquè l’administrador sol evitar la caché.

No excloguis tots els scripts de l’optimització sense localitzar la dependència.

Decideix si és adequat un rollback

Utilitza la reversió com a diagnòstic controlat o recuperació temporal només si existeixen un paquet anterior fiable i una còpia de base de dades. Comprova si l’actualització contenia una correcció de seguretat o migració que faci perillós tornar enrere.

Prova primer a staging. Si has d’actuar en producció, copia l’estat actual, registra la versió de destí i evita l’actualització automàtica fins a resoldre la compatibilitat.

No descarreguis mai versions antigues des de llocs no oficials.

Repara cap endavant quan sigui possible

La solució duradora pot ser actualitzar un add-on compatible, adaptar un hook, corregir una configuració de correu més estricta o instal·lar una versió corregida. Aplica un canvi cada vegada i conserva l’evidència que el relaciona amb l’error.

Si ha canviat l’esquema de base de dades, utilitza la reparació o migració admesa pel proveïdor. Evita editar taules a mà sense conèixer l’esquema i la reversió.

Mantén les dependències sensibles en versions mantingudes.

Torna a provar totes les accions

Una entrada correcta és només el primer control. Verifica validació, rutes condicionals, uploads, notificacions, SMTP, CRM, webhooks, pagaments, confirmacions i Analytics.

Prova sense sessió en escriptori i mòbil amb dades sintètiques. Confirma que un enviament produeix una entrada i només els efectes previstos, fins i tot després d’un reintent segur.

Demana ajuda urgent quan hi hagi pagaments, càrregues personals o canvis de base incompatibles. Facilita versions, hores i errors amb dades ocultes; mai llicències, credencials o entrades reals.

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència