WordPress: la cartella di destinazione esiste già

“La cartella di destinazione esiste già” compare quando WordPress tenta di installare un plugin o un tema ma trova già una directory con lo stesso slug. Può trattarsi del componente installato, di file residui dopo un aggiornamento fallito o di una copia caricata manualmente.

Questa guida approfondisce La cartella di destinazione esiste già con una procedura progressiva e reversibile. Non inviare password, codici 2FA, token, chiavi private o file di configurazione completi nei ticket.

Che cosa significa

Eliminare la directory senza identificarla può rimuovere un plugin attivo, personalizzazioni o un tema child. Prima bisogna verificare nome, stato e contenuto.

Le impostazioni dei plugin sono spesso nel database e possono restare dopo la rimozione dei file, ma non è garantito per ogni componente.

Come riconoscere il problema

  • Installazione ZIP interrotta.
  • Il plugin non appare ma la cartella esiste.
  • Aggiornamento fallito ha lasciato file.
  • La directory ha suffisso o contenuto incompleto.
  • Il tema attivo usa la stessa cartella.

Cause più frequenti

1. Plugin già installato

WordPress non sovrascrive l’installazione con la procedura scelta. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

2. Aggiornamento incompleto

La directory temporanea è stata spostata solo in parte. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

3. Upload manuale

Un archivio è stato estratto nella cartella errata. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

4. Slug identico

Due pacchetti usano lo stesso nome directory. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

5. Permessi

WordPress non è riuscito a sostituire o eliminare i file. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

6. Backup locale

Una copia rinominata in modo ambiguo viene interpretata come destinazione. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

Diagnosi passo per passo

  1. Leggi lo slug. Annota la cartella indicata nell’errore. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  2. Controlla Plugin o Temi. Verifica se il componente è già registrato. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  3. Apri Gestione file. Esamina percorso, data e contenuto senza cancellare. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  4. Crea backup. Salva directory e database se il componente contiene dati. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  5. Confronta il pacchetto. Verifica autore, versione e slug ufficiale. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  6. Controlla log. Cerca aggiornamento interrotto e permessi. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
  7. Verifica dipendenze. Un tema child o plugin add-on può richiedere il componente. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.

Metodo sicuro di intervento

Prima di modificare la configurazione, registra lo stato iniziale: indirizzo o funzione coinvolta, messaggio completo, data e ora, ultima modifica nota e risultato da un secondo dispositivo, rete o strumento. Una diagnosi ripetibile è più utile di molti tentativi eseguiti contemporaneamente.

Applica una sola correzione alla volta e conserva una copia dei file, dei record o dei valori precedenti. Dopo ogni intervento ripeti esattamente il test originale e controlla i log relativi allo stesso intervallo temporale. Se il risultato cambia, annota quale modifica lo ha prodotto.

Evita disattivazioni globali di firewall, WAF, TLS, cache o sistemi di sicurezza. Quando serve una eccezione, deve essere limitata all’URL, al parametro, al processo o al servizio realmente interessato.

Procedura di risoluzione

  1. Aggiorna dal pannello. Se il componente è installato, usa il normale aggiornamento. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  2. Rinomina temporaneamente la directory. Solo per diagnosi e con una copia disponibile. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  3. Rimuovi residui verificati. Elimina esclusivamente la cartella incompleta e non il componente attivo. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  4. Ripristina il pacchetto ufficiale. Installa una copia integra e compatibile. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  5. Correggi permessi. Usa valori corretti senza 777. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  6. Riattiva e testa. Controlla frontend, wp-admin e funzioni del componente. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
  7. Pulisci copie temporanee. Dopo la verifica evita directory obsolete. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.

Controlli finali

  • Plugin o tema appare correttamente.
  • Nessun fatal error.
  • Impostazioni preservate.
  • Directory unica e coerente.
  • Aggiornamenti futuri funzionano.

Prevenzione

  • Aggiorna con backup.
  • Non interrompere installazioni.
  • Usa pacchetti ufficiali.
  • Evita copie dentro plugins.
  • Controlla spazio disco.

Errori da evitare

  • Non cancellare la cartella senza identificarla.
  • Non rinominare il tema attivo senza alternativa.
  • Non caricare ZIP dentro la directory finale.
  • Non usare 777.
  • Non lasciare versioni multiple attive.

Come documentare la verifica

Conserva una breve nota con configurazione iniziale, risultato di ogni controllo e modifica applicata. Inserisci sempre data e ora, perché cache, log, code, rate limit e processi pianificati possono cambiare nel tempo. Questa documentazione facilita il rollback e permette all’assistenza di evitare verifiche già eseguite.

Quando confronti due test, usa le stesse condizioni: stesso URL o destinatario, stesso file, stesso client e stessa rete quando possibile. Se cambi più variabili, il risultato non permette di individuare con certezza la causa.

Controllo incrociato

Dopo la correzione esegui almeno un controllo indipendente. Per un sito confronta browser, risposta HTTP e log; per DNS interroga autoritativo e resolver pubblico; per la posta confronta Webmail, intestazioni e Track Delivery; per PHP verifica il valore effettivamente applicato al dominio. Un solo indicatore può essere influenzato da cache o configurazioni locali.

Se il problema ricompare, evita ulteriori modifiche e raccogli nuovamente i dati. La ricorrenza può indicare un processo pianificato, un limite raggiunto, una dipendenza esterna o una configurazione che viene rigenerata automaticamente.

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:

  • slug
  • percorso
  • versione WordPress
  • operazione
  • log o screenshot

Non inviare credenziali. Per iniziare la diagnosi sono sufficienti dati tecnici, orari, URL, codici e messaggi di errore.

Fonti tecniche ufficiali

Domande frequenti su La cartella di destinazione esiste già

Posso eliminare la cartella?

Solo dopo aver verificato che sia un residuo e aver creato un backup.

Le impostazioni del plugin andranno perse?

Spesso sono nel database, ma dipende dal plugin e dalla procedura di disinstallazione.

Perché WordPress non sovrascrive?

Per evitare di sostituire file esistenti in modo ambiguo o incompleto.

Rinominare la cartella disattiva il plugin?

Sì, WordPress non troverà più il percorso registrato.

Devo usare il pacchetto ufficiale?

Sì, riduce rischi di file modificati o struttura errata.

WordPress: la cartella di destinazione esiste già ultima modifica: 2026-08-02T02:07:15+02:00 da Team tecnico Xlogic

Ti è piaciuto questo Post?