Què importa primer: WordPress mostra el mateix missatge genèric per a diverses sol· licituds rebutjades, més comunament un fitxer més gran que PHP permet o un formulari enviat amb un token de seguretat caducat.
Què indica realment aquest símptoma
La pàgina no nomena el límit fallit. Compara l’acció, la mida del fitxer, la configuració de PHP i el temps de sol· licitud evita canvis aleatoris en cada configuració de càrrega.
Recull proves abans de canviar res
- Registra si l’error es produeix durant la càrrega de plugin/tema, la càrrega de suports o la presentació de formularis.
- Compara la mida del fitxer amb càrrega_ max_ filesize i entrada_ max_ size.
- Comprova la max_ exempletion_time i el límit de petició-cap del servidor web.
- Repet des d’una pàgina acabada de carregar per a descarregar un nonce caducat.
Causes més habituals
- Cos entradaal massa gran: El servidor web o PHP descarreta la sol· licitud abans que WordPress la rebi.
- Desajustament del límit de càrrega: entrada_max_ size és més baix que pujar_ max_ filesize o el servidor imposa una altra tapa.
- Nonce caducat: Una pàgina de gestió a la memòria cau o oberta durant molt de temps envia un token no vàlid.
- Temps d’espera durant l’extracció: Un paquet gran es carrega però no es pot desempacar abans que acabi la petició.
Seqüència segura de diagnòstic i reparació
- Establir límits coherents en la capa activa PHP i servidor web, a continuació, confirmar els seus valors efectius.
- Usa SFTP o WP-CLI per a grans paquets de confiança en comptes d’eliminar els límits de càrrega pública indefinidament.
- Exclou les pàgines d’administració de la memòria cau de pàgina completa.
- Prova una càrrega controlada i Inspecciona el servidor registre si l’extracció falla.
Com distingir entre les causes probables
No tractis Cos entradaal massa gran i Desajustament del límit de càrrega com a causes equivalents. El servidor web o PHP descarrita la sol· licitud abans que WordPress la rebi. En canvi, entrada_ max_ size és més baix que pujar_ max_ filesize o el servidor imposa una altra tapa. Per distingir- les, useu aquestes dues comprovacions: Registra si l’error es produeix durant la càrrega plugin/tema, la càrrega de suports o la presentació de formularis; i compara la mida del fitxer amb càrrega_ max_ filesize i entrada_ max_ size. Amb aquestes dades podreu decidir si convé aplicar la primera acció controlada -establir límits coherents a la capa activa PHP i servidor web, a continuació, confirmar els seus valors efectius- o si has de conservar l’estat actual i ampliar la recerca.
En un lloc de WordPress en producció, repeteix la petició que falla mentre comprova una pàgina que funciona correctament i l’àrea d’administració. Un error aïllat en una ruta requereix un rollback més acotat que un problema que afecta PHP, la base de dades o totes les peticions. Documenta la data i hora exactes, la URL o transacció afectada, l’últim estat correcte conegut i cada canvi realitzat durant el diagnòstic. Aquest registre permet distingir una reparació reproduïble d’una desaparició temporal del símptoma.
Què no has de fer
No carregueu fitxers ZIP no fiables a través d’un límit més gran. Valida la font i preserveu una còpia de seguretat abans d’instal· lar el codi.
Com verificar la reparació
- Un paquet realista es carrega i instal·la una vegada.
- Administració fresca i de durada normal sessions Envia sense errors nonce.
- Els límits dels organismes de petició pública no són superiors als necessaris des del punt de vista operacional.
Que el símptoma visible desaparegui no és suficient. Tanca la incidència només quan l’acció original que fallava, el recorregut de negoci relacionat i els registres rellevants confirmin que el problema ha desaparegut.
CRITERI D’INCIDENT WP REPAIR
Seqüència d’intervenció segura
La pàgina no nomena el límit fallit. Compara l’acció, la mida del fitxer, la configuració de PHP i el temps de sol· licitud evita canvis aleatoris en cada configuració de càrrega.
- Registra si l’error es produeix durant la càrrega de plugin/tema, la càrrega de suports o la presentació de formularis.
- Compara la mida del fitxer amb càrrega_ max_ filesize i entrada_ max_ size.
- Comprova la max_ exempletion_time i el límit de petició-cap del servidor web.
- Repet des d’una pàgina acabada de carregar per a descarregar un nonce caducat.
Què ha de quedar verificat
- Un paquet realista es carrega i instal·la una vegada.
- Administració fresca i de durada normal sessions Envia sense errors nonce.
- Els límits dels organismes de petició pública no són superiors als necessaris des del punt de vista operacional.
Fonts tècniques oficials
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
Aquest missatge vol dir sempre que el meu testimoni de seguretat ha caducat?+
No. WordPress mostra aquest mateix missatge genèric per a diverses sol·licituds rebutjades diferents, més comunament una càrrega de fitxers de gran mida o una nonce caducada, de manera que la redacció per si sola no identifica la causa. Compara la mida del fitxer contra pujar_ max_ filesize i la configuració post_ max_ size normalment aclareix quina s'aplica.
Ja he augmentat la càrrega_max_filesize — per què la càrrega continua fallant amb aquest missatge?+
Post_max_ size també s'ha d’elevar, atès que un valor inferior al de pujar_ max_ filesize farà que PHP descarti la sol·licitud abans de que WordPress la vegi. Ambdues configuracions, a més de qualsevol límit de petició-prop del servidor web, neceswebn estar d’acord entre si.
L'elevació dels límits de càrrega a tot el lloc és una manera segura d'instal·lar un paquet gran plugin?+
Funciona però no és l’opció més segura. Per a paquets de gran confiança, l’ús de SFTP o WP-CLI evita elevar els límits de càrrega pública indefinidament, el que redueix l’exposició creada en deixar un límit més alt en el seu lloc després de la instal·lació.
El fitxer s’ha arribat a carregar, però la instal·lació ha fallat igualment amb aquest error: què té de diferent aquest cas?+
Això apunta a un temps d’espera durant l’extracció en comptes d’un problema de mida de càrrega: un paquet gran pot acabar de carregar, però no pot desempacar abans que la petició acabi degut a max_ execution_time. Comprova el registre del servidor per a un temps d’espera en aquesta etapa separa això d’un problema de mida límit senzill.