Ciao a tutti, volevo segnalare un comportamento che mi è parso anomalo; utilizzando imagecache, al momento della creazione di un preset non venivano create sul server remoto (Aruba) le corrispondenti cartelle in sites/default/files/imagecache/, problema che ho visto notificare più volte da vari utenti. Dopo aver fatto tentativi tra più versioni di php e di drupal (ora sono alla 6.14), dopo aver verificato che clean-urls fosse attivo e che il contenuto di .htaccess dentro sites/default/files fosse:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks
ho riscontrato lo stesso il problema.
Ho fatto un tentativo, commentando le righe di questo .htaccess
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
#Options None
#Options +FollowSymLinks
Ed ora funziona, le cartelle vengono create ed imagecache sembra fare il suo dovere. Sul server locale (xampp) questo non accade, non è necessario commentare htaccess. Mi chiedevo, cosa può comportare non avere l'opzione dei links simbolici gestista da htaccess? Forse che il server aruba la gestiva già di suo ed era in qualche modo in confitto con questa?
Grazie
Dad
appena rilasciato: http://drupal.org/project/take_control
Certified to Rock
Ciao ragazzi, spero di essere nel posto giusto...
dopo vari tentativi e grazie all'immenso aiuto di jhl.verona sono riuscito a spostare il mio sito drupal da localhost su aruba.
Ora non mi resta che risolvere questo problema (forse)(spero).
Con CCK mi sono creato i miei content types utilizzando ImageCache per le immagini con i vari presets per il ridimensionamento dei thumbnails e delle immagini più grandi. Ora l'upload dell'immagine funziona e viene salvata in:
http://www.miosito.com/sites/default/files/imagefield_thumbs/preview/immagine.jpg
quando però salvo il content type l'immagine sparisce e non viene salvata nelle cartelle dei preset che sono:
http://www.miosito.com/sites/default/files/imagecache/260x130/preview/immagine.jpg
e
http://www.miosito.com/sites/default/files/imagecache/350x300/preview/immagine.jpg
ho modificato i permessi delle varie cartelle (777) default e files e il file .htaccess è commentato nelle rispettive righe
HELP! Grazie
ImageCache è uno dei moduli che brilla per la sua semplicità. Lui crea un immagine definito da uno dei preset ma solo se viene richiesta - per questo si chiama ImageCache.
Se cariciamo un immagine in
sites/default/files/immagine.jpg, allora finchè non viene richiesta uno dei preset, ImageCache non lo crea affatto - quindi cerchi quanto vuoi ma non lo troverà (e se non sono stati creati nessun immagine tramite un preset,sites/default/files/imagecacherimerrà vuoto).Adesso, scriviamo un nodo con riferimento al preset:
sites/default/files/imagecache/small/immagine.jpgcosa succede?ErrorDocument 404 /index.phpin .htaccess, Apache rimanda a Drupal...La prossima volta che viene richiesta l'immagine, il file esiste quindi risponde Apache senza passare per Drupal (molto più efficace).
La bellezza sta nel efficienza. Puoi avere miglaia di immagini, e centiaia di preset, ma ImageCache crea solo quelli che serve. Ottimizzando l'utilizzo del disco, al costo (una tantum) di un esecuzione Drupal quando il file 'manca'... Cambi i comandi del preset, e ImageCache cancella il cache (di quel preset), e dopo man mano ricostruisce gli 'immagini.
Ovviamente, quel direttivo Apache
ErrorDocument 404 /index.phpè essenziale perchè funziona ImageCache (e non solo lui, ovvio)...HTH
John
Più imparo, più dubito.
Caro John,
I do apologise but...
grazie per la tua pronta risposta ma non ho capito come risolvere il problema...
Da come me la spieghi non è un problema di permessi, anche se la cartella sites/default va sbloccata.
Riesco via FTP a fare l'upload delle immagini nelle cartelle e vengono correttamente visualizzate anche se chiaramente il crop and resize va fatto manualmente ad esempio check this out:
http://www.yiaos.com/sites/default/files/imagecache/100x100/wimwenders_or.jpg
Ho riletto il thread...
No. L'immagine (originale) viene salvato in http://www.miosito.com/sites/default/files/preview/immagine.jpg o più probabile http://www.miosito.com/sites/default/files/immagine.jpg
Forse non hai capito come funziona. Ho guardato http://www.yiaos.com/sites/default/files/imagecache/100x100/wimwenders_o... che non è per niente 100 x 100 pixels, quindi sono andato a cercare l'originale: http://www.yiaos.com/sites/default/files/wimwenders_or.jpg ma non c'è - errore 404!
Per caso hai uploadati gli immagini in
sites/default/files/imagecacheinvece disites/default/files?E forse no. Ho guardato http://www.yiaos.com/sites/default/files/imagecache/260x130/preview/wimw..., che ha invece un correspondente http://www.yiaos.com/sites/default/files/preview/wimwenders.jpg. Hmmm. Quello funziona a dovere. Idem http://www.yiaos.com/sites/default/files/imagecache/350x300/preview/wimw.... Non so che dire... C'è tanta nebbia...
Ma Wim Wenders è un registra o un frigorifero?
John
Più imparo, più dubito.
HO RISOLTO! E SONO RIUSCITO DA SOLO!!!! E' "BASTATO" CAMBIARE IN ADMINISTER>SITE CONFIGURATION>FILE SYSTEM - DOWNLOAD METHOD = PRIVATE!!
GRAZIE
E SE ME LO SPIEGATE MI FARESTE UN PIACERE E VOLEVO SCUSARMI CON JOHN PER AVERGLI FATTO PERDERE TEMPO.
Ma Wim Wenders è un registra o un frigorifero?
è un frigorifero...
Si e no.
Questo funziona perchè file system == private, funziona quasi esattamente come ImageCache. Cioè invece di
sites/default/filescome percorso, stabilisce uno (non esistente) chiamato se mi ricordo benesystem/files. Allora di nuovo, Apache non trovando il percorso/file rimanda a Drupal, che passa la palla a ImageCache (in questo caso).Io ho visto su tuo sito pezzi funzionante, e pezzi non. Credo che devi semplicemente pulire il cache (di ImageCache) in
admin/build/imagecache/listfai Flush per i preset non funzionante, e poi ritentare a vedere gli immagini col browser, senza mettere file system == private...Non devi scusarti, decido io come spendere il mio tempo ;-)
Più imparo, più dubito.
Ciao John,
ho fatto il flush ai vari preset ma se rimetto su download method PUBLIC non va, se torno a PRIVATE mi carica le immagini. Adesso mi accontento che funzioni (anche se non dovrei farlo), quando avrò un pò di tempo finito questo proggetto sicuramente mi metterò a studiare.
Anche io più imparo e più dubito... mi piacerebbe allora avere un sacco di dubbi...
Mi sono appena accorto che le immagini le fa vedere solo se è stato effettuato il login... Sta diventando frustrante...
Chiaramente è causa del download method...
Questo forum sta diventando un pò il mio diario di bordo... Ho fatto il flush ai preset, ho rimesso il download method su public. Risultato 1 su 3 funziona...
E' già un risultato ;-)
Si solo uno funziona, allora il percorso Apache a Drupal sta funzionando, e il problema sta altrove.
Stai usando GD o Imagemagik? Quando vai a modificare il preset, anche l'anteprima è corretto?
Più imparo, più dubito.
Secondo me risolvi togliendo il file .htaccess dalla cartella sites/default/files. Cancellalo o rinominalo!
Se non ricordo male questo accorgimento risolve su hosting aruba!
..vivere non è difficile, potendo poi rinascere..
No. Se lo cancelli o rinomini Drupal si accorge e scrive uno nuovo.
Più imparo, più dubito.
Se le immagini non vengono mai visualizzate è un problema, se qualcuna si e qualcuna no è un altro. Quest'ultimo caso dovrebbe essere il tuo da quanto ho capito...
Ebbene, un po di tempo fa ho avuto il medesimo problema e dopo tanti sbattimenti mi sono accorto che solo le immagini che nn venivano visualizzate avevano nel nome del file dei segni percentuali "%". Ho rinominato i file senza di essi e ricaricate le immagini con i nuovi nomi tutto è andato liscio!
Non conosco il motivo di tutto questo ad essere sincero, ma ti riporto la mia esperienza nel caso possa esserti d'aiuto... controlla i nomi dei file nn visualizzati e confrontali con quelli che invece vanno, se noti delle differenze (come per me i %) allora sistema il tutto...
Tutorial, guide e moduli per drupal su www.cmswiki.net
Anch'io lo credevo, ma ti assicuro che nel mio caso non è così! Ho appena ricontrollato ed è presente solo il file .htaccess nella root, ma non quello in sites/default/files/. Mi ricordo che dopo vari tentativi avevo risolto così!
Ed infatti in un'altra installazione sempre su aruba, ma fatta con il loro installer, i file .htaccess ci sono in entrambe le cartelle! Ma nel .htaccess in sites/default/files tutte le righe di codice sono commentate, quindi c'è, ma in realtà non c'è! Quindi il problema sta tutto nel .htaccess della cartella "files".
Di seguito posto i due file .htaccess che aruba inserisce nell'installazione di drupal fatta con il loro installer, e confermo che questa configurazione permette la visualizzazione delle immagini con imagecache:
. htaccess della ROOT:
## Apache/PHP/Drupal settings:
#
# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl|svn-base)$|^(code-style\.pl|Entries.*|Repository|Root|Tag|Template|all-wcprops|entries|format)$">
Order allow,deny
</FilesMatch>
# Don't show directory listings for URLs which map to a directory.
#Options -Indexes
# Follow symbolic links in this directory.
#Options +FollowSymLinks
# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php
# Force simple error message for requests for non-existent favicon.ico.
<Files favicon.ico>
# There is no end quote below, for compatibility with Apache 1.3.
ErrorDocument 404 "The requested file favicon.ico was not found."
</Files>
# Set the default handler.
#DirectoryIndex index.php
# Override PHP settings. More in sites/default/settings.php
# but the following cannot be changed at runtime.
# PHP 4, Apache 1.
<IfModule mod_php4.c>
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
</IfModule>
# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
</IfModule>
# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
</IfModule>
# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
# If your site can be accessed both with and without the 'www.' prefix, you
# can use one of the following settings to redirect users to your preferred
# URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
#
# To redirect all users to access the site WITH the 'www.' prefix,
# (http://example.com/... will be redirected to http://www.example.com/...)
# adapt and uncomment the following:
# RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
# RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
#
# To redirect all users to access the site WITHOUT the 'www.' prefix,
# (http://www.example.com/... will be redirected to http://example.com/...)
# uncomment and adapt the following:
# RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
# RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]
# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
# RewriteBase /drupal
#
# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /
# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>
# $Id: .htaccess,v 1.90.2.5 2010/02/02 07:25:22 dries Exp $
.htaccess in sites/default/files/
#SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006#Options None
#Options +FollowSymLinks
Provate! A me funziona perfettamente!
..vivere non è difficile, potendo poi rinascere..