Non riesco a caricare immagini nel pannello di amministrazione di Magento, ricevendo l'errore "La cartella di destinazione non è scrivibile o non esiste". Di recente ho spostato tutti i file da un hosting a un altro. Qualche soluzione per questo?
Non riesco a caricare immagini nel pannello di amministrazione di Magento, ricevendo l'errore "La cartella di destinazione non è scrivibile o non esiste". Di recente ho spostato tutti i file da un hosting a un altro. Qualche soluzione per questo?
Risposte:
Nel tuo progetto apri il file lib/Varien/File/Uploader.php
e inserisci una funzione Mage::log()
all'interno save()
.
public function save($destinationFolder, $newFileName = null)
{
$this->_validateFile();
if ($this->_allowCreateFolders) {
$this->_createDestinationFolder($destinationFolder);
}
if (!is_writable($destinationFolder)) {
// Put a mage::log() and check what is the folder magento is looking for.
Mage::log($destinationFolder);
throw new Exception('Destination folder is not writable or does not exists.');
}
...
}
Dal registro puoi scoprire la cartella che Magento sta cercando. E quindi controlla le autorizzazioni per quella cartella.
Ottengo lo stesso errore su Magento 2 e questo è il file da cui proviene l'errore in questo caso:
vendor/magento/framework/File/Uploader.php
Alla riga 256
puoi inserire temporaneamente questo codice per ottenere la cartella non scrivibile / inesistente:
if( !is_writable($destinationFolder) ) {
// throw new Exception('Destination folder is not writable or does not exists.');
throw new Exception($destinationFolder);
}
Altrimenti, controlla se esistono queste cartelle e che sono scrivibili dal server web:
pub/media/catalog/
pub/media/catalog/category
pub/media/catalog/product
pub/media/images
pub/media/wysiwyg/
Per me il problema è stato risolto facendo
pub / media / tmp
scrivibile dal web server
Le cartelle successive nella directory "pub / media" sono anche scrivibili
- banners
- catalog
- images
- wysiwyg
Per quello che vale ho avuto questo problema alcune volte e ho dimenticato che di solito è il file immagine stesso, non il server dopo aver verificato le autorizzazioni e tutto il resto. Non caricare comunque l'immagine perché era troppo grande, sia in dimensioni che in dimensione file.
Le soluzioni per me sono:
Ridimensiona una foto HIGH-REZ prima del caricamento.
Aumenta magento Risoluzione massima o carica immagine System > Catalog > Product Image
Assicurati che la cartella multimediale media / tmp / catalog / product esista "e rendi quella directory scrivibile dal tuo server web"
777
, è meglio dire "e rendere quella directory scrivibile dal tuo server web". L'idea è che non è necessario concedere a ogni singolo utente l'accesso in scrittura solo per consentire al server Web di scrivere immagini. (Non sono io quello che ha effettuato il downgrade, ma nel caso ve lo stavate chiedendo, questo è molto probabilmente il motivo)
Si prega di controllare la cartella multimediale con l' autorizzazione 777. Se si è abilitata la modalità di compilazione significa anche controllare include la cartella con l' autorizzazione 777 .
Dopo aver dato il permesso 777 a quelle cartelle problema risolto per me.
Potrebbe essere il certificato scaduto dall'amministrazione Plesk (era il mio caso).
Ho provato i passaggi precedenti, ma non ha funzionato. Da lì ho provato ad accedere ai file tramite FileZilla per dare immediatamente i permessi a tutte le cartelle, quindi un messaggio di errore sul certificato scaduto. Non è il certificato SSL del negozio stesso, ma l'amministrazione di Plesk. Ho creato un nuovo certificato autofirmato, applicato la sua amministrazione Plesk e tutto è tornato alla normalità.
Questo ha funzionato per me. Lascio qui il mio contributo.
In bocca al lupo
C'è un bug in Magento per il caricamento di file quando magento DocumentRoot su vhost è impostato correttamente
/path/to/magento/pub
Invece di (obsoleto)
/path/to/magento
Uploader tenta di creare file in
/path/to/magento/pub/pub/your_upload_dir
Si noti che il pub della posizione va due volte. Hanno detto che lo risolveranno in 2.2.0+ ma in 2.2.1 questo problema appare ancora.