Non riesco a installare nuovi plugin a causa dell'errore "Impossibile creare la directory"

Per capire perché stai riscontrando questi problemi, devi comprendere i concetti fondamentali della proprietà dei file.

In sostanza, sai che Apache viene eseguito come utente www-data. Questo è il motivo per cui impostare tutto come proprietà di quell'utente funziona, perché WordPress verifica che possa creare file come l'utente che possiede i suoi stessi file. Quindi, quello che stai facendo è rendere tutto di proprietà dell'utente che possiede i file.

Se hai il controllo totale e completo della macchina, questo va bene. D'altra parte, se è un server di hosting condiviso, allora hai creato una falla nella sicurezza.

Normalmente, i server web vengono eseguiti come un determinato utente (come www-data) che poi esegue codice di altri utenti (come "otto", il mio account utente). In questa situazione, il server web non avrebbe la possibilità di creare file come "otto", e quindi non sarebbe in grado di creare correttamente file come il mio account. Pertanto, questo controllo di WordPress per creare file correttamente posseduti e quindi poter installare plugin o aggiornare file fallirebbe, correttamente, perché avere i miei file di proprietà dell'utente condiviso del server web sarebbe un rischio per la sicurezza.

In tal caso, WordPress dovrebbe correttamente chiedermi le credenziali FTP, o qualcosa del genere. Queste sarebbero un modo per aggirare il problema dell'account utente autenticandosi come l'utente che dovrebbe scrivere i file, e poi scriverli come quell'utente.

Ora, stai cercando di risolvere questo problema cambiando tutti i file di WordPress in modo che siano di proprietà dello stesso account con cui il server web scrive i file. L'approccio più normale per questo è cambiare il modo in cui il server web scrive i file, per consentire al processo PHP di essere "di proprietà" dell'account utente con cui sta eseguendo i file.

La risposta generale a questo è "suphp". Questa versione di PHP imposta l'utente con cui viene eseguito il processo PHP allo stesso utente del proprietario dei file PHP che sta eseguendo. Questo è più sicuro nelle configurazioni di hosting condiviso, perché assicura che un processo PHP eseguito dal server web condiviso venga eseguito come proprietario dei file PHP, e quindi non possa leggere gli account di altri utenti e simili.

Su Ubuntu, credo che questo sia il modo generale per farlo:

Installa suphp:

$ sudo apt-get install libapache2-mod-suphp

Disabilita il vecchio mod_php

$ sudo a2dismod php5 

Riavvia Apache

$ sudo /etc/init.d/apache2 restart

Ed ecco fatto. Ora, fai in modo che i tuoi file PHP di WordPress siano di proprietà del loro normale proprietario. Nessun trucco speciale, nessun cambiamento di permessi o proprietà o cose del genere. Dato che il processo PHP verrà eseguito come proprietario di quei file, sarà in grado di scriverci come quel proprietario. Le directory dovrebbero essere 755, i file dovrebbero essere 644 (nota, suphp non gradisce che i file siano scrivibili dal gruppo, quindi 755/644 è l'impostazione corretta dei permessi).

Per me (su Ubuntu) ho dovuto aggiungere umask 002 a /etc/apache2/envvars per far sì che WordPress caricasse plugin/immagini con permessi 775 invece di 755 (cioè permettere a chiunque oltre ad Apache e root di modificare i file caricati)

È necessario concedere i permessi di scrittura alle directory rilevanti. Idealmente, dovresti farlo solo per il file o la cartella specifica e poi ripristinare i permessi per non lasciare il tuo sito vulnerabile.

Puoi risolvere questo problema utilizzando i seguenti comandi dalla riga di comando (supponendo che ti trovi nella cartella principale di WordPress):

# cd wp-content
# chmod -R a+w plugins
# chmod -R a+w themes
# chmod -R a+w upgrade

La soluzione più sicura è aggiungere apache allo stesso gruppo del proprietario dell'installazione di WordPress e modificare tutti i permessi del gruppo in scrivibili.

A volte mi è capitato di avere siti in cui correggere i permessi di directory e file non era sufficiente per risolvere il problema. Ho poi scoperto che una o più directory avevano impostato il flag immutabile. Questo può essere facilmente risolto eseguendo chattr -R /var/www/sub.domain.tld come root.

Ecco una soluzione molto semplice: cambia i permessi della cartella opt eseguendo il comando sudo chmod -R 777 /opt.