WordPress PCLZIP_ERR_BAD_FORMAT: archivio non valido

PCLZIP_ERR_BAD_FORMAT WordPress indica che il file trattato come archivio ZIP non possiede una struttura valida o completa. Spesso WordPress ha scaricato una pagina HTML di errore, login o licenza al posto del pacchetto previsto.

Questa guida approfondisce PCLZIP_ERR_BAD_FORMAT WordPress con verifiche progressive e reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.

Che cosa significa

L’errore può comparire installando plugin e temi o durante aggiornamenti. Il nome del file `.zip` non garantisce che il contenuto sia realmente un archivio.

Pacchetti premium richiedono talvolta una licenza o un token. Se la richiesta viene reindirizzata a una pagina web, PclZip tenta di aprirla e restituisce BAD_FORMAT.

Come riconoscere il problema

  • Installazione o update termina con PCLZIP_ERR_BAD_FORMAT.
  • Il file ZIP è molto piccolo.
  • Aprendo l’archivio localmente compare un errore.
  • Il download richiede login o licenza.
  • Il log mostra redirect, 403 o timeout durante il download.

Cause più frequenti

1. Archivio corrotto o incompleto

Il trasferimento è stato interrotto. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

2. Pagina HTML al posto dello ZIP

Il provider restituisce login, errore o scadenza licenza. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

3. Pacchetto sbagliato

Lo ZIP contiene documentazione e un secondo archivio installabile. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

4. Spazio temporaneo insufficiente

Download o estrazione non completano. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

5. Proxy, WAF o cURL

La richiesta remota viene modificata o bloccata. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

6. Estensione ZIP o libreria

Il metodo di estrazione disponibile incontra un formato non supportato. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.

Diagnosi passo per passo

  1. Scarica il pacchetto manualmente. Usa il portale ufficiale. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
  2. Controlla dimensione e tipo. Verifica firma ZIP e apertura locale. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
  3. Esamina il contenuto. Cerca un archivio installabile annidato. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
  4. Controlla licenza e URL. Verifica che il download non richieda nuova autenticazione. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
  5. Controlla spazio e inode. Serve margine per file temporanei ed estrazione. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
  6. Leggi log HTTP e PHP. Cerca cURL, redirect e permessi. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
  7. Confronta installazione manuale e automatica. Distingui pacchetto e downloader. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.

Metodo sicuro di diagnosi

Prima di modificare la configurazione, registra URL o servizio coinvolto, messaggio completo, data e ora, ultima modifica nota, client o rete e risultato ottenuto con un secondo strumento. Questa fotografia iniziale permette di confrontare i test e di tornare alla configurazione precedente quando una modifica non produce il risultato atteso.

Applica una sola correzione alla volta. Dopo ogni intervento ripeti esattamente la stessa operazione e controlla i log dello stesso intervallo temporale. Modificare contemporaneamente DNS, cache, PHP, plugin, proxy e firewall elimina la possibilità di attribuire il risultato a una causa precisa.

Controllo incrociato

Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin, Site Health e WP-CLI; per DNS interroga nameserver autoritativi e resolver pubblici; per la posta confronta Webmail, intestazioni originali e Track Delivery. Cache, TTL e code possono mostrare stati differenti per alcuni minuti.

Quando il problema sembra risolto, esegui una seconda prova con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Verifica inoltre che TLS, autenticazione, WAF, permessi e controlli antispam restino attivi: una correzione che disabilita stabilmente le protezioni non è una soluzione definitiva.

Verifica prolungata dopo la correzione

Conserva temporaneamente backup, valori precedenti ed estratti dei log. Ripeti il controllo dopo il normale ciclo di cache, cron, coda o TTL. Se l’anomalia ricompare a intervalli regolari, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, processi pianificati e servizi esterni.

Documenta il risultato finale con data, comando o schermata utilizzata e condizione verificata. Questa nota evita interventi duplicati e rende più rapida una futura analisi da parte dell’assistenza.

Procedura di risoluzione

  1. Scarica nuovamente il file ufficiale. Evita copie modificate o incomplete. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  2. Estrai lo ZIP corretto. Quando il pacchetto commerciale contiene più file. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  3. Aggiorna licenza o token. Ripristina l’URL autorizzato. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  4. Carica il pacchetto da WordPress. Solo dopo averlo validato localmente. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  5. Libera spazio e inode. Prima di ripetere download ed estrazione. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  6. Aggiorna WordPress e plugin. Correggi downloader incompatibili. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
  7. Installa via SFTP con cautela. Mantieni backup e struttura corretta della directory. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

Come raccogliere prove utili

Quando riproduci il problema, conserva soltanto i dati tecnici necessari: codice di risposta, URL priva di token, orario con fuso, request ID, nome del client, dimensione del file o del messaggio e una breve descrizione dell’operazione. Evita screenshot parziali quando puoi esportare il testo originale, perché header, log e messaggi completi permettono una diagnosi più precisa.

Prima di chiudere il controllo, confronta il comportamento con una configurazione nota e funzionante. Per una API usa un payload minimo; per WordPress prova una funzione core senza plugin aggiuntivi; per DNS interroga direttamente i nameserver; per la posta usa Webmail e conserva il file `.eml`. Questo confronto riduce le ipotesi e impedisce modifiche inutili.

Controlli finali

  • Archivio valido.
  • Plugin o tema installato.
  • Nessun file HTML rinominato ZIP.
  • Licenza attiva.
  • Aggiornamenti futuri funzionanti.

Prevenzione

  • Pacchetti ufficiali.
  • Licenze monitorate.
  • Spazio libero.
  • Download verificati.
  • Backup prima degli update.

Errori da evitare

  • Non rinominare HTML in ZIP.
  • Non installare pacchetti da fonti sconosciute.
  • Non sovrascrivere directory senza backup.
  • Non disattivare SSL verify.
  • Non ignorare la dimensione anomala.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:

  • nome componente
  • origine pacchetto
  • dimensione file
  • errore completo
  • log download senza token

Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.

Fonti tecniche ufficiali

Domande frequenti su PCLZIP_ERR_BAD_FORMAT WordPress

Il file può chiamarsi ZIP ma non esserlo?

Sì, una pagina HTML può essere salvata con estensione `.zip`.

Perché accade con plugin premium?

Il download può richiedere licenza o autenticazione valida.

Posso estrarre e caricare via SFTP?

Sì, dopo backup e usando la directory corretta del componente.

Spazio pieno può causarlo?

Può produrre un archivio incompleto o impedire l’estrazione.

Devo disattivare la verifica SSL?

No, bisogna correggere certificato, URL o connessione.

WordPress PCLZIP_ERR_BAD_FORMAT: archivio non valido ultima modifica: 2026-08-02T16:57:29+02:00 da Team tecnico Xlogic

Ti è piaciuto questo Post?