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.

Com provar una actualització de WordPress abans d’aplicar-la a producció

Que carregui la portada de staging és una prova feble. La còpia ha de compartir l’entorn de producció i executar les funcions del component actualitzat, inclosos els desaments, cron, correu i integracions.

Defineix els criteris d’acceptació abans de prémer Actualitza. Així, l’absència d’un error evident no es confon amb l’èxit.

Crea un staging segur

Copia els fitxers i la base actuals amb control d’accés. Desactiva la indexació, el correu real, els pagaments, webhooks i API externes destructives.

Anonimitza les dades quan sigui possible i restringeix els usuaris. No exposis una base de clients clonada en un subdomini públic.

Anota l’hora de la còpia perquè els canvis posteriors no hi seran.

Iguala l’entorn

Utilitza les mateixes versions i extensions PHP, MySQL o MariaDB, servidor web, configuració de WordPress, memòria cau i ruta de proxy DNS o SSL.

Llista de paritat:
WordPress i nucli
tema i connectors actius
controlador i límits PHP
emmagatzematge i esquema de base
cron
memòria cau d'objectes i pàgina

Documenta les diferències inevitables, com la passarel·la sandbox.

Considera els canvis posteriors de producció

Staging envelleix quan es clona. Anota els canvis de configuració o contingut durant les proves i decideix si afecten la compatibilitat.

Abans de desplegar, torna a comparar versions, PHP, tema, connectors obligatoris, drop-ins i opcions rellevants. No copiïs la base de staging a producció per portar-hi una actualització: esborraries dades comercials noves. Desplega el codi i deixa executar només les migracions documentades.

Inclou seguretat i privadesa

Comprova que la versió no amplia endpoints REST, accés a fitxers, rols o capacitats. Prova l’accés anònim a pàgines privades i que els logs no continguin secrets nous.

Revisa el consentiment i les peticions externes si s’afegeixen scripts. Una actualització funcional que trenca permisos o privadesa no està preparada.

Conserva material de reversió

Fes còpia de staging i conserva els paquets exactes anterior i nou. Anota recomptes de taules i versions d’esquema.

Prova-hi la restauració de fitxers i dades. Un estat verd de la còpia no demostra que recuperi el web.

Mantén estret el límit de rollback de producció: paquet de codi davant de base.

Llegeix la informació de la versió

Revisa el registre de canvis, versions mínimes, seguretat, funcions retirades i migracions. Comprova dependències i plantilles sobreescrites pel tema.

Per a salts grans, prova versions intermèdies si el fabricant les exigeix.

No confiïs únicament en escàners automàtics.

Aplica un canvi cada vegada

Actualitza el component objectiu i deixa acabar les migracions. Conserva els errors de PHP, navegador, base i tasques.

No barregis a la mateixa prova PHP, WordPress, tema i diversos connectors; no podràs atribuir la fallada.

Buida OPcache i els recursos al moment correcte i torna a provar amb la memòria cau calenta.

Executa proves de la funció real

Prova l’accés, rols, editor, mitjans, cerca, navegació, REST o AJAX, cron i correu. Executa el recorregut comercial exacte del component.

Per a cada prova:
entrada o estat
resultat esperat
resultat observat
referència de registre o petició
aprovat o fallit

Inclou mòbil i usuaris anònims o connectats.

Prova la fallada i la reversió

Simula una fallada segura: entrada invàlida, API no disponible o cancel·lació. Confirma que l’error és clar i la feina parcial es pot recuperar.

Reverteix el component a staging i demostra que les dades actuals continuen. Si el downgrade de base falla, producció necessita un pla més sòlid de manteniment, restauració i unió.

No descobreixis la incompatibilitat durant la caiguda real.

Defineix una porta de desplegament

Enumera les fallades bloquejants, problemes coneguts acceptables, aprovador i llindar de rollback. Una prova crítica fallida no es compensa perquè la portada funcioni.

Registra checksums i finestra. Si producció supera el llindar —nou fatal, fallada en desar o funció caiguda— executa el rollback assajat en lloc de depurar indefinidament en públic.

Desplega observant

Programa segons el risc, fes una còpia nova i aplica el mateix paquet i procediment. Executa proves ràpides.

Vigila errors PHP i HTTP, cron i mètriques de la funció durant un període representatiu. El manteniment recurrent ha de conservar aquesta bateria i executar-la després de cada versió; les proves converteixen l’actualització en un canvi controlat.