Po aktualizaci nezobrazuje web obrázky.
Vložil/a ptu, 2 Červen, 2011 - 13:10
Kategorie:
Jak na to?
Týká se verze:
Drupal 6.x
Aktualizoval jsem jak jádro Drupalu 6 tak některé moduly a nyní mi web nezobrazuje obrázky. Správněji řečeno – grafiku tématu webu ano, ale ne obrázky vložené do obsahu. I pro superusera Drupal hlásí: Nemáte oprávnění přistupovat na tuto stránku.
Když proberu log, vidím třeba položku:
Typ access denied
Zpráva system/files/obrazkova_galerie/citron.jpg
Prošel jsem už všechno, co snad šlo, v admin/user/permissions, Modul imagecache se zdá vše v pořádku, na serveru se s adresářem sites nic nedělo a obrázky tam jsou.
Prosím o radu nebo odkaz, jestli se to už někde řešilo, několik hodin hledám a zkouším a marně. Pavel
Hlavní RSS kanál
nezměnil si při té
nezměnil si při té aktualizaci také .htaccess?
Tak to mne nenapadlo ověřit.
Tak to mne nenapadlo ověřit. Díky za nápad, zkusím to off-line. Potřeboval jsem potíž rychle napravit a tak jsem obnovil ze zálohy a aktualizoval jen jádro. Moduly nevyžadovaly bezpečnostní aktualizaci, tak jsem to zatím nechal u starších ale fungujících verzí.
Přesouvám nyní web na jiný
Přesouvám nyní web na jiný webhosting a výše popsaný problém mne zas trápí. Konkrétněji: Web vodomilka.cz, např. obrázek Lhota.jpg V adresáři /sites/default/files/imagecache/obrazek-nahled/obrazkova_galerie/Lhota.jpg fyzicky na serveru je, ale odkaz Drupalu http://example.cz/…ie/Lhota.jpg neukáže nic než že soubor neexistuje. Web testuji u dvou společností a u stávající ještě jede. U dvou z těchto hostingů se obrázek zobrazí a u jedné ne. 3× identická instalace jak na ftp tak na mysql a jedna z nich neukazuje některé obrázky. Obrázky grafického tématu a obrázky v textu se zobrazují v pořádku. Technik hostingu mne přesvědčuje, že práva jsou nastavena správně a že chyba je někde v nastavení Drupalu. Jednak tomu moc nevěřím, protože pak by mi to nechodilo ani na dalších serverech. Ale co já vím, zase takový odborník nejsem. Snad nějaká interakce mezi nastavením Drupalu a jejich serverem. Nemáte nápad jak tomu přijít na kloub? Když ne řešení, alespoň nápad co zkusit testovat a jak. Sám už nevím. Dík Pavel
A opravdu tam někde v nějaké
A opravdu tam někde v nějaké adresáři nemáte nějaký .htaccess, který nemá zakomentovaný obsah?
Dále bych si vyjel phpinfo z obou hostingů a porovnal je. Třeba mají zakázanou nějakou php direktivu…
Možná povede k cíli
Možná povede k cíli následující zkušenost. Na hostingu byli ochotní a zjistili, že obrázky se dají z adresářů přímo zobrazit, ale jakmile se dá cesta, kterou si drupal vytváří sám, už to nefunguje. Příklad:
example.cz/system/files/imagecache/obrazek-nahled/obrazkova_galerie/116_003.jpg
dává chybu 403
example.cz/sites/default/files/imagecache/obrazek-nahled/obrazkova_galerie/116_003.jpg
obrázek se zobrazí.
Když jsem změnil na stránce Systém souborů z původní Metoda stahování: Neveřejně – soubory přenáší Drupal. na Veřejně – soubory jsou k dispozici pomocí HTTP protokolu, už se vše zobrazuje jak má. Ale zůstává otázka, jak to, že jinde to jde i s neveřejným přenosem souborů. Mám to nechat takto nebo se snažit zprovoznit neveřejný přístup? Souvislosti veřejný vs. neveřejný přístup moc nechápu. Jde o bezpečnost? .htaccess vám tu mohu ukázat, to už je pro mne trochu vyšší dívčí. Pavel
Veřejné stahování souborů mi
Veřejné stahování souborů mi na webu nemůže zůstat, protože určité soubory musí být přístupné pouze přihlášeným. Dal jsem se tedy do porovnávání phpinfo.V tomhle jsem laik a rozdílností je mnoho. Z toho, co mne uhodilo do očí je, že jeden server má safemode on a druhý off. Mohlo by toto způsobit potíž s neveřejným přenosem souborů?
Další rozdíl je v definici disable_functions jeden má
chgrp,chown,lchgrp,lchown,link,popen,dl,pcntl_exec,pcntl_fork,pcntl_signal, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig
a druhý
proc_close, putenv, readlink, socket_get_option, socket, socket_read, socket_recv, socket_write
Není to sice jádro problému,
Není to sice jádro problému, ale přesto: „určité soubory musí být přístupné pouze přihlášeným“ – jediným řešením zde není neveřejné stahování pro celý Drupal. Lze použít například http://drupal.org/…ate_download
… je to mnohem lepší, protože vás to neomezí v jiných věcech, jako je např. komprimace css
Skvělé, děkuji, vynikající
Skvělé, děkuji, vynikající tip! Líbí se mi mít „pod pokličkou“ pouze neveřejné věci a ne všechno. To by kompletně problém vyřešilo.
Teoreticky ale budu bádat dál co se na serverech dělo. Např. mi není jasné, jakto že když původní web jel s neveřejným stahováním (tak se tam i automaticky uploadovaly soubory a Drupal na ně odkazoval s virtuálním adresářem system) a i když je psáno, že při změně veřejného stahování na neveřejné odkazy fungovat nebudou, ony fungují.
Oprava:
neveřejné odkazy fungovat nebudou, ony fungují
ne všechny, je jich málo, ale některé opravdu nefungují, bude je třeba změnit ručně.
Nainstaloval jsem modul
Nainstaloval jsem modul private_download, povolil jej v seznamu modulů, v menu nastavení webu – private_download jsem nastavil privátní adresář a v uživatelé – oprávnění stanovil role, které mohou stahovat. V ten okamžik nemůže stahovat nikdo, ani superuser. Když zakážu modul a smažu .htaccess, který v chráněném adresáři vytvoří, podle očekávání zase stahovat lze (veřejně). Dělám v něčem chybu?
Nejdřív bych chtěla upřesnit,
Nejdřív bych chtěla upřesnit, že používám (skoro stejný) custom modul, jehož návod pochází od autorů zmíněného modulu (je starší než modul na drupal.org) a je zde: http://www.drupalcoder.com/…e-management (To je ale jen pro úplnost, princip je zcela stejný).
K popsanému problému – někdy se mi po instalaci dělo totéž a bylo třeba vymazat cache prohlížeče.
A velmi nedávno jsem musela ze stejného důvodu vypnout Backup and Migrate, jehož novější verze jsou údajně s tímto modulem v kolizi. viz http://drupal.org/node/961372 #11
Madam, klaním se! Vypnul jsem
Madam, klaním se! Vypnul jsem Backup and migrate, vše mi funguje a web mohu zveřejnit.
Poslat nový komentář