Come cancellare la cache di WordPress dal server/FTP/posizione remota

17 set 2016, 00:42:37
Visualizzazioni: 18.1K
Voti: 2

Normalmente non lavoro con WordPress e sto avendo difficoltà a trovare molte cose.

Ho aggiunto una riga di PHP personalizzato a un file template nel child theme, ma ho dimenticato un punto e virgola. Ora il sito non si carica e rimane bloccato all'infinito. Nella maggior parte dei casi, quando questo mi succede in Drupal, basta salvare di nuovo il file e aggiornare; apparentemente WordPress non funziona così...

Dove viene salvata la cache predefinita di WordPress e quali file devo eliminare/modificare per forzare WP a cancellare le cache? Non posso accedere al sito in alcun modo, non si carica. L'unico accesso che ho è via FTP. Se non posso semplicemente eliminare la cache, quali opzioni ho nella situazione attuale?

5
Commenti

WordPress non ha una cache di pagina integrata, quindi dovrai identificare il plugin di caching utilizzato e fare ricerche da lì. Tuttavia, questo è un problema altamente localizzato. Non avere accesso alla dashboard e modificare i file direttamente sul server è davvero una ricetta per il disastro.

Dave Romsey Dave Romsey
17 set 2016 00:50:46

@DaveRomsey Ho un backup e sembra che non ci sia alcun plugin di caching nell'elenco dei plugin, quindi di default WordPress non memorizza nulla in cache? Cosa posso fare per risolvere questo problema? Un errore di battitura in un file template PHP può portare a un errore irrecuperabile? Sembra un bug critico completamente rotto. C'è un qualche tipo di fail-safe se questo errore di battitura è stato inserito nell'editor del backend?

Altef four Altef four
17 set 2016 00:57:10

Esatto, il core di WordPress non effettua la cache delle pagine. Prova a rimuovere temporaneamente il child theme usando FTP, correggi il problema nel template (che potrebbe non essere stato salvato in primo luogo), poi riaggiungi il child theme. Avrai bisogno di accedere all'area di amministrazione per reimpostare il child theme come tema attivo. Dato che non hai accesso, potresti semplicemente entrare nel child theme e assicurarti che la tua correzione sia stata salvata perché ho l'impressione che tu abbia modificato il tema tramite l'editor di temi nel backend (inizialmente pensavo che avessi usato FTP anche per quello).

Dave Romsey Dave Romsey
17 set 2016 01:07:37

Ho rimosso il child theme e poi lo ho rimesso su FTP e ora tutto funziona. Sono super confuso. No, mi chiedevo solo se teoricamente facessi lo stesso errore di battitura nel backend invece di modificarlo via ftp, esploderebbe allo stesso modo? E scelgo di non modificare con l'editor del backend su WordPress perché è super lento e laggoso, e ho bisogno del syntax highlighting, e alcuni file che devo modificare (file PHP malamente hardcodati nel tema premium) non sono visibili dall'editor in WordPress, ho bisogno dell'accesso FTP.

Altef four Altef four
17 set 2016 01:31:50

Sì, presumibilmente incorreresti nello stesso problema se ci fosse un errore fatale nel tema modificato via FTP. Personalmente, disabilito gli editor di temi e plugin perché usarli è semplicemente chiedere guai. Ho aggiunto la soluzione che ho suggerito come risposta. Per favore accettala se effettivamente risolve il problema (mantiene WPSE pulito).

Dave Romsey Dave Romsey
17 set 2016 04:46:00
Tutte le risposte alla domanda 1
2

WordPress non ha una cache nativa per l'output del codice sorgente delle pagine. In un'installazione standard, le modifiche ai template dovrebbero essere visibili immediatamente.

Se ciò non accade, ci sono diverse possibili ragioni:

  • è installato un plugin di cache per pagine statiche, che sta servendo una versione obsoleta (l'implementazione specifica della cache dipenderebbe dal plugin);
  • esiste un livello di cache tra il sito e internet, come un reverse proxy fornito dall'hosting;
  • il sito ha header HTTP configurati in modo da causare una cache eccessivamente aggressiva nel browser (o eventualmente in un server proxy lungo il percorso);
  • PHP ha una cache opcode installata (cosa buona/normale) configurata per essere troppo aggressiva/lunga (raro), il che potrebbe fargli ignorare per un po' le modifiche al codice PHP nei file.
17 set 2016 21:02:52
Commenti

Per aggiungere, non credo che le pagine di errore utilizzino un codice HTTP 200 (o almeno non dovrebbero farlo), e quindi non dovrebbe esserci alcuna cache della pagina di errore. D'altra parte, PHP 5.6 (?) ha introdotto la cache del codice PHP analizzato e, a causa di alcuni problemi di configurazione del server, le modifiche ai file non venivano rilevate e il re-parsing non avveniva

Mark Kaplun Mark Kaplun
17 set 2016 21:16:03

Ho aggiunto la cache opcode come possibile motivo.

Rarst Rarst
17 set 2016 21:24:50