Стилизованные картинки нормально генерятся и отдаются, но с кодом 404

Главные вкладки

Аватар пользователя marassa marassa 18 декабря 2018 в 13:56

Недавно выкатил очередные доработки на продакшен-сайт (версия Drupal 8.6.2), и через некоторое время случайно заметил в консоли хрома целую кучу сообщений такого вида при отображении галерей картинок:
GET http://***/sites/default/files/styles/gallery_thumbnail/public/*.jpg 404 (Not Found)
При этом сами стилизованные картинки в галерее отображаются совершенно нормально, на закладке Network видно, что они отдаются нормального размера, только почему-то с кодом 404. Выявил, что не все картинки в галерее отдаются с кодом 404, а только часть, остальные с кодом 200. Далее выявил, что с кодом 404 отдаются те картинки, для которых нужный стиль еще не сгенерен на момент запроса. То есть веб-сервер действительно не находит нужную картинку в папке styles, далее запускает друпал для обработки ошибки 404, друпал исправно генерит стилизованную картинку, кладет ее куда надо и отдает клиенту, но почему-то с кодом 404.
Самое смешное, что другие браузеры (IE11, Firefox) все эти ошибки даже на консоль не выводят, просто показывают картинки и всё, то есть эти ошибки видно только в консоли хрома, ну и в логах веб-сервера если их под микроскопом разглядывать.
В связи с этим я даже не уверен, что это появилось только сейчас - просто сейчас появился новый стиль галереи и к нему новый стиль картинок, и естественно для десятков тысяч картинок, уже имеющихся на сайте, стилизованных картинок в этом стиле нет, поэтому при отображении новых галерей идет массовая генерация стилизованных картинок. Раньше сайт был так устроен, что при добавлении новой картинки, практически сразу генерились и все стили к ней, то есть если ошибки 404 и возникали, то я их мог просто не замечать.
При этом на дев-сайте (версия 8.5.2, хостинг тот же) ничего подобного не наблюдается - вновь генерируемые картинки отдаются с кодом 200, как и ранее сгенеренные.
Поломав немножко над этим голову, я вспомнил, что год назад уже воевал со стилями картинок, правда немножко в другой ситуации:
http://dru.io/question/8905
Тогда я так и не понял, в чем было дело, просто нашел затычку и успокоился. Не знаю связано ли тогдашняя проблема с сегодняшней или нет. Попробовал убрать затычку из settings.php - стилизованные картинки вообще не генерируются, причем даже если убрать из .htaccess защиту от хотлинкинга!
Собственно вопрос: может быть кто-нибудь сталкивался с подобным, или интимно знаком с той частью потрохов Друпала, которая отвечает за image styles? Куда копать-то? Или забить?

Лучший ответ

Аватар пользователя marassa marassa 20 декабря 2018 в 16:28

В общем, перетащил все нужные мне директивы (явно прописав пути) в корневой .htaccess, всё работает как надо и без ошибок. А почему оно так было - пусть останется загадкой Wink

Комментарии

Аватар пользователя VasyOK VasyOK 18 декабря 2018 в 14:35

"Далее выявил, что с кодом 404 отдаются те картинки, для которых нужный стиль еще не сгенерен на момент запроса."
Ну да. Пока на страницу не зайдешь, миниатюра в папке стиля не сгенерируется. Как варинт указать стиль изображения используемый при редактирвании ноды. Это в настройках поля картинки.

Аватар пользователя marassa marassa 18 декабря 2018 в 14:47

VasyOK wrote:

Пока на страницу не зайдешь, миниатюра в папке стиля не сгенерируется

Всё верно, но зачем свежесгенерированная картинка отдается с кодом 404? Причем на одном сайте из двух?
VasyOK wrote:

Как варинт указать стиль изображения используемый при редактирвании ноды

Как вариант чего? Какую проблему это решает?

Аватар пользователя Orion76 Orion76 18 декабря 2018 в 17:16
1

скорее всего что-то с настройками вэб-сервера..

Настройки вэб-сервера на обоих сайтах сильно отличаются?

Аватар пользователя bsyomov bsyomov 18 декабря 2018 в 19:16
2

Вероятнее всего проблема в конфигурации веб сервера всё же. Особенно, если там есть что-то нестандартное. Возможно, не правильно интерпретируется отсутствие файла на месте, и отдаётся 404 в случае передачи запроса к обработчику php, вне зависимости от его ответа.

Давайте её посмотрим.

Аватар пользователя Orion76 Orion76 18 декабря 2018 в 20:34

Да.. обычно в такой конфигурации:

  1. nginx + php-fpm
  2. стандартный nginx-конфиг для drupal
  3. в админке указана папка временных файлов и разрешена запись в нее вэб-серверу (или просто права: 777)
  4. права на sites/default/files : 777

и никаких проблем с картинками не бывает.. совсем..

Аватар пользователя marassa marassa 18 декабря 2018 в 21:06

Отвечу на все вопросы сразу:
Панель управления хостингом - cPanel, хостинг один и тот же, сервер - Apache.
Вот - весь /sites/default/files/.htaccess от прод-сервера, где проблема есть:

# Turn off all options we don't need.
Options -Indexes -ExecCGI -Includes -MultiViews

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
  # Override the handler again if we're run later in the evaluation list.
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>
  php_flag engine off
</IfModule>

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://([^.]+\.)?nouveau\.world [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://([^.]+\.)?google\. [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://([^.]+\.)?yandex\. [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://([^.]+\.)?facebook\. [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ http://art.nouveau.world/nohotlinking.jpg [R,L]

RewriteCond %{HTTP_USER_AGENT} ^(.*)bingbot(.*)$ [NC]
RewriteRule .* - [R=403,L]

Вот весь /sites/default/files/.htaccess от дев-сервера, где проблемы нет:

# Turn off all options we don't need.
Options -Indexes -ExecCGI -Includes -MultiViews

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
  # Override the handler again if we're run later in the evaluation list.
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>
  php_flag engine off
</IfModule>

"Верхние" файлы .htaccess из корня довольно большие, чуть-чуть отредактированные из дистрибутива Друпал и почти одинаковые. Выложу только их разницу, но если надо могу выложить и файлы целиком:

Сравнение файлов .htaccess и DEV\.HTACCESS
***** .htaccess
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^/?$ "http\:\/\/art\.nouveau\.world\/" [R=301,L]
RewriteCond %{HTTP_HOST} ^art\-nouveau\.org$ [OR]
***** DEV\.HTACCESS
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^/?$ "http\:\/\/dev\.nouveau\.world\/" [R=301,L]
RewriteCond %{HTTP_HOST} ^art\-nouveau\.org$ [OR]
*****

***** .htaccess
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^/?$ "http\:\/\/art\.nouveau\.world\/" [R=301,L]

***** DEV\.HTACCESS
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^/?$ "http\:\/\/dev\.nouveau\.world\/" [R=301,L]

*****

***** .htaccess
Redirect 301 /user/login /FAQ
Redirect 301 /ru/user/register /FAQ
Redirect 301 /ru/user/login /FAQ

RewriteBase /
RewriteCond %{THE_REQUEST} ^GET.*index\.php [NC]
RewriteRule (.*?)index\.php/*(.*) /$1$2 [R=301,NE,L]

RewriteCond %{HTTPS} =on
RewriteRule ^robots.txt$ robots-https.txt [L]

RewriteCond %{HTTP_USER_AGENT} bingbot [NC]
RewriteRule !^robots\.txt - [R=403,L]
***** DEV\.HTACCESS
*****

Аватар пользователя marassa marassa 18 декабря 2018 в 21:47

Phantom63rus wrote:

А если убрать?

RewriteRule \.(jpg|jpeg|png|gif)$ http://art.nouveau.world/nohotlinking.jpg [R,L]

Убрал (вместе с соответствующими RewriteCond), ничего не изменилось. Картинки все отдаются, но свежесгенерированные с кодом 404.

Аватар пользователя marassa marassa 18 декабря 2018 в 22:12

Apache. В логах сервера вот так:

95.165.139.254 - - [18/Dec/2018:21:46:04 +0300] "GET /sites/default/files/styles/gallery_thumbnail/public/ArtefactPictures/Russia/St%20Petersburg/0_161ad_86978b3f_orig.jpg HTTP/1.1" 404 13222 "http://art.nouveau.world/railing" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"
95.165.139.254 - - [18/Dec/2018:21:46:04 +0300] "GET /sites/default/files/styles/gallery_thumbnail/public/ArtefactPictures/Spain/Madrid/20616981_401111413624788_9073456660031060747_o.jpg HTTP/1.1" 404 35507 "http://art.nouveau.world/railing" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"
95.165.139.254 - - [18/Dec/2018:21:46:05 +0300] "GET /sites/default/files/styles/gallery_thumbnail/public/ArtefactPictures/Russia/Samara/z3vu8717rcukvzn31f.jpg HTTP/1.1" 404 15253 "http://art.nouveau.world/railing" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"
95.165.139.254 - - [18/Dec/2018:21:46:05 +0300] "GET /sites/default/files/styles/gallery_thumbnail/public/ArtefactPictures/Austria/Vienna/DSC00241-01.jpeg HTTP/1.1" 200 30287 "http://art.nouveau.world/railing" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"
95.165.139.254 - - [18/Dec/2018:21:46:05 +0300] "GET /sites/default/files/styles/gallery_thumbnail/public/ArtefactPictures/Belgium/Brussels/5919752980_1c371af726_b.jpg HTTP/1.1" 200 23986 "http://art.nouveau.world/railing" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"
95.165.139.254 - - [18/Dec/2018:21:46:05 +0300] "GET /sites/default/files/styles/gallery_thumbnail/public/ArtefactPictures/Germany/Hagen/keom08.jpg HTTP/1.1" 200 25332 "http://art.nouveau.world/railing" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"
95.165.139.254 - - [18/Dec/2018:21:46:04 +0300] "GET /sites/default/files/styles/gallery_thumbnail/public/ArtefactPictures/Russia/St%20Petersburg/14589584_646887538807505_6804595714876752813_o.jpg HTTP/1.1" 404 27980 "http://art.nouveau.world/railing" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"
95.165.139.254 - - [18/Dec/2018:21:46:05 +0300] "GET /sites/default/files/styles/gallery_thumbnail/public/ArtefactPictures/Russia/Moscow/P4290317-X3.jpg HTTP/1.1" 404 23026 "http://art.nouveau.world/railing" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36"

То есть вперемешку 200 и 404. Все картинки в броузере отображаются нормально, независимо от кода.

Аватар пользователя marassa marassa 19 декабря 2018 в 6:57

Phantom63rus wrote:

В конфиге апача выставить LogLevel debug, правда там мусора в логах будет... но должно что-то проясниться.

Попробую попозже, если это возможно сделать на уровне .htaccess, без доступа к общей конфигурации апача.

Аватар пользователя marassa marassa 19 декабря 2018 в 7:00

VasyOK wrote:

Может опять глупость скажу: а если gallery_formatter отключить, тогда эффект сохраняется?

Я пробовал с другой галереей и другим стилем (просто снёс часть давно сгенерированных "миниатюр"): результат такой же, куча 404 при первом обращении, при этом все картинки генерируются и показываются.

Аватар пользователя marassa marassa 19 декабря 2018 в 8:10

Попробовал вставить LogLevel debug в .htaccess , получил довольно неожиданный результат: все картинки отдались с кодом 500, но при этом отдались и отрисовались как ни в чем ни бывало Wink
Никаких других подробностей в логе нет - по прежнему одна запись на один запрос.

Аватар пользователя Orion76 Orion76 19 декабря 2018 в 8:50

Я так понял, цель данного топика - превратиться в вечный "пятничный" топик?-)

Ну извините, если обломал.

Есть такой старый сисадминский(и не только) прием быстро и эффективно решать почти любые проблемы.
Если все варианты решений уже перепробованы, надо просто взять и прочитать наконец-то инструкцию(документацию).

В данном случае надо выяснить конфигурацию вэб-сервера:
1.Apache
2. Nginx + Apache
3. Другие варианты

И посмотреть логи вэб-сервера.

В 99% случаев эти действия помогут получить всю необходимую для решения проблемы информацию.

Аватар пользователя marassa marassa 19 декабря 2018 в 9:44

Orion76 wrote:

надо выяснить конфигурацию вэб-сервера...
И посмотреть логи вэб-сервера.

Так выяснили и посмотрели давно.
Orion76 wrote:

В 99% случаев эти действия помогут получить всю необходимую для решения проблемы информацию

А в оставшемся 1% что делать? Wink
На самом деле "проблема" конечно из разряда курьезов - если не пялиться праздно в консоль хрома, то ее и не видно никому. Думал вдруг кто сталкивался и сразу ответит, ну а нет так нет, действительно не тот вопрос, на который есть смысл тратить много времени.
Меня даже больше волнует та прошлогодняя проблема, которую я тогда заткнул отключением itok, так и не поняв "что это было" и почему отключение itok сработало. Отключение itok в settings.php грозятся убрать в одном из будущих релизов восьмерки (https://www.drupal.org/project/drupal/issues/2568517), и что я тогда буду делать? Wink

Аватар пользователя Orion76 Orion76 19 декабря 2018 в 10:34

marassa wrote:

Так выяснили и посмотрели давно.


Не выяснили..

Одни из самых распространенных конфигураций вэб-сервера:
1.Apache
2. Nginx + apllication server (обычно Apache)
3. Nginx + php-fpm

1.Apache
http-запросы принимает-отдает: Apache
обрабатывает: Apache

2. Nginx + apllication server (обычно Apache)
http-запросы принимает-отдает: Nginx
обрабатывает: Apache

3. Nginx + php-fpm
http-запросы принимает-отдает: Nginx
обрабатывает: php-fpm

У Вас скорее всего или 1 или 2
если 2 - то коды ответов отдает Nginx, и тогда разбираться надо с его конфигом.
Кстати, проблема с itok скорее всего с этим же связана.
В nginx для Drupal немного специфичный конфиг, как раз часть его "специфики" связана с обработкой запросов картинок.

Аватар пользователя gun_dose gun_dose 19 декабря 2018 в 10:35
1

Минуточку. Миниатюры не генерятся в момент запроса картинки. Миниатюры генерятся во время рендера форматтеров и всего такого. То есть, сервер перед тем, как "выплюнуть" ссылку на миниатюру в атрибуте src, должен её предварительно сгенерировать, если в папке со стилями этой картинки ещё нет.

Не знаю только, как это поможет в решении проблемы))

Аватар пользователя marassa marassa 19 декабря 2018 в 13:02

gun_dose wrote:
Минуточку. Миниатюры не генерятся в момент запроса картинки. Миниатюры генерятся во время рендера форматтеров и всего такого. То есть, сервер перед тем, как "выплюнуть" ссылку на миниатюру в атрибуте src, должен её предварительно сгенерировать, если в папке со стилями этой картинки ещё нет.

Довольно важное уточнение, но действительно ли это так? Чисто эмпирически при запросе галереи с несгенерированными картинками сначала открывается галерея с пустыми местами под картинки, а потом, довольно медленно и в случайном порядке в ней "проявляются" картинки по мере их генерации сервером. Простая перезагрузка страницы со всеми картинками после сброса браузерного кэша выглядит совсем не так - готовые картинки прилетают с сервера пулей.
И еще: если миниатюры не генерируются автоматически при прямом их запросе, то к чему тогда весь этот сыр-бор с введением itok'ов и последующим введением опции для их отключения?
PS Да вот прям щас попробовал загрузить несуществующую миниатюру прям из адресной строки браузера: сгенерировалась на ходу как ни в чем ни бывало. С кодом 404, что характерно Wink

Аватар пользователя gun_dose gun_dose 19 декабря 2018 в 14:19

Интересно, у меня тоже так. Удаляю картинку - она восстанавливается. Но если в пути написать папку другого стиля, который к этой картинке не применяется, то картинка не сгенерится. Непонятно))

Аватар пользователя Orion76 Orion76 19 декабря 2018 в 11:05

Конфиг nginx для drupal: https://www.nginx.com/resources/wiki/start/topics/recipes/drupal/

<?php
    location 
@rewrite {
        
rewrite ^/(.*)$ /index.php?q=$1;
    }

    

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
        
try_files $uri @rewrite;
        
expires max;
        
log_not_found off;
    }
?>

Как раз тут: location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
try_files $uri @rewrite;

nginx пробует отдать картинку по ее пути $uri,

например /sites/default/files/styles/my-style/image-name.jpg

если картинка не найдена
запрос обрабатывается секцией конфига @rewrite
которая преобразует запрос
/sites/default/files/styles/my-style/image-name.jpg
в
index.php?q=/sites/default/files/styles/my-style/image-name.jpg

и отдает его drupal

далее вызывается обработчик для пути :

<?php
/**
 * Implements hook_menu().
 */
function image_menu() {
  
$items = array();

  

// Generate image derivatives of publicly available files.
  // If clean URLs are disabled, image derivatives will always be served
  // through the menu system.
  // If clean URLs are enabled and the image derivative already exists,
  // PHP will be bypassed.
  
$directory_path file_stream_wrapper_get_instance_by_scheme('public')->getDirectoryPath();
  
$items[$directory_path '/styles/%image_style'] = array(
    
'title' => 'Generate image style',
    
'page callback' => 'image_style_deliver',
    
'page arguments' => array(count(explode('/'$directory_path)) + 1),
    
'access callback' => TRUE,
    
'type' => MENU_CALLBACK,
  );
.........
?>

который создает нужный стиль картинки и отдает вэб-серверу

Аватар пользователя marassa marassa 19 декабря 2018 в 13:15

Orion76 wrote:

Nginx
Nginx
Nginx
Nginx
Nginx
Nginx
Nginx
Nginx
Nginx

Ну нет у меня никаких следов и упоминаний nginx'а и его конфигурации на радоновском хостинге. Лежит в корне нетронутый web.config от друпаловского дистрибутива, сейчас снес его вообще для прикола - ничего не изменилось.

Аватар пользователя Andruxa Andruxa 19 декабря 2018 в 13:56
1

Самое время поставить )

В принципе, Orion76 уже описал физику процесса:
если вебсервер (в данном случае - апач) не находит файла по указанному пути, от переадресует запрос на /index.php
далее, срабатывает hook_menu модуля image, и необходимый пресет генерится и кладется на свое место.
При следующем запросе - апач находит файл по указанному пути и отдает его.
Непонятно, почему возвращается 404 при передаче запроса на /index.php

Похожим образом работает модуль robotstxt - если в корне сайта нет файла robots.txt, то запрос идет на index.php и через hook_menu обрабатывается модулем, который возвращает содержимое файла.
А если файл есть - то модуль не может обработать запрос, о чем и сообщает в отчете о состоянии сайта.
Попробуйте поставить robotstxt и переименовать файл в robots.txt.bak - с каким кодом будет отдаваться содержимое файла?
Если 200 - то проблема где-то в модуле image, а если - 404, то в настройках вебсервера.

Аватар пользователя marassa marassa 19 декабря 2018 в 14:01

Andruxa wrote:

Orion76 уже описал физику процесса:

если вебсервер (в данном случае - апач) не находит файла по указанному пути, от переадресует запрос на /index.php

далее, срабатывает hook_menu модуля image, и необходимый пресет генерится и кладется на свое место.

При следующем запросе - апач находит файл по указанному пути и отдает его.

Спасибо, кэп! Только я эту самую физику описал чуть раньше, прямо в самом первом посте Wink
Andruxa wrote:

Непонятно, почему возвращается 404 при передаче запроса на /index.php

И еще раз спасибо, кэп! ;)
Andruxa wrote:

Попробуйте поставить robotstxt

Это мысль, щас попробую.

Аватар пользователя marassa marassa 19 декабря 2018 в 14:41

Поставил модуль robotsttxt, снёс файл robots.txt, при запросе отдаётся динамический robots от модуля с кодом 200!
Значит, похоже косячит именно Друпал 8.6 в цепочке обработки запроса к несуществующей миниатюре. Попробую порыться в коде ядра.

Аватар пользователя marassa marassa 19 декабря 2018 в 15:43

Вставил $this->logger->notice() непосредственно перед
return new BinaryFileResponse($uri, 200, $headers, $scheme !== 'private');
в ImageStyleDownloadController.php. Действительно для всех вновь генерируемых картинок вызывается этот код и передается код 200.
Вопрос: что, как и зачем может поменять код ответа (и больше ничего) у уже сформированного друпалом ответа?

Аватар пользователя Phantom63rus Phantom63rus 19 декабря 2018 в 18:31

Код ответа может поменять либо веб-сервер, либо кеширующий сервер. Только они как бы таким не занимаются в стандарте.

Loglevel выставляется в конфиге апача, но не в htaccess, то что произошло это... гммм... it's a magic!^_^ В смысле там что-то не то и не так отработало, смутно догадываюсь что там есть похожая директива.

И да, скорее всего на серваке стоит nginx.

Вообще хостер радон, здесь есть их представители, надо бы их пригласить в тему.

Аватар пользователя marassa marassa 19 декабря 2018 в 20:01

Phantom63rus wrote:

хостер радон, здесь есть их представители, надо бы их пригласить в тему

Ну они формально с пользовательским кодом не обязаны разбираться, я не хотел их грузить пока достоверно не выяснится, что проблема в настройках, мне недоступных, а не в моем коде или в моих настройках. Тем более, что на другом-то сервере, который у них же хостится, всё нормально.

Аватар пользователя bsyomov bsyomov 20 декабря 2018 в 8:18

Спасибо за лестную оценку, и я бы даже помог, вот только настроить ПО на шеред хостинге, это определённо проблема. Smile

Аватар пользователя marassa marassa 20 декабря 2018 в 8:29

Да Борис уже помог чем мог на основании той скудной информации, которую я был в состоянии предоставить Wink
Теперь попробую в техподдержку Радона написать, раз все эксперты склоняются к тому, что дело в настройках сервера.

Аватар пользователя marassa marassa 20 декабря 2018 в 9:32
2

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:

А обязательно оставаться на шареде?

Не вижу пока ни одного повода съезжать с Радона. Работает всё надёжно и быстро, техподдержка отличная (если задаешь внятные вопросы по существу), а обсуждаемый в данной теме курьёз вообще ни на что не влияет, даже если так и не удастся с ним разобраться Wink
PS А лавры сам-себе-сисадмина меня никогда не прельщали, мне гораздо проще платить (смешные) деньги специально обученным профессионалам.

Аватар пользователя bsyomov bsyomov 20 декабря 2018 в 11:27
2

На самом деле, это чаще всего, правильная позиция. Нормальный шаред это вполне хорошо и удобно, если соответствует нуждам проекта. А желание переехать на VPS, без знаний и навыков, прочитав пару статеек, обычно ведёт к серьёзным проблемам. Smile

Аватар пользователя marassa marassa 20 декабря 2018 в 15:42

Выявил одну любопытную закономерность: если из файла sites/default/files/.htaccess убрать или закомментировать ВСЕ директивы после

<IfModule mod_php5.c>
  php_flag engine off
</IfModule>

то есть сделать этот файл как из дистрибутива или как на dev-сайте, то ошибка 404 сразу пропадает. При вводе туда ЛЮБОЙ директивы, даже просто "RewriteEngine on" без единого условия или правила, сразу появляется код 404 на генерируемых картинках.

Аватар пользователя marassa marassa 20 декабря 2018 в 16:28

В общем, перетащил все нужные мне директивы (явно прописав пути) в корневой .htaccess, всё работает как надо и без ошибок. А почему оно так было - пусть останется загадкой Wink

Аватар пользователя marassa marassa 20 декабря 2018 в 16:43

Кстати, и прошлогодняя проблема со стилями, из-за которой тогда пришлось вставлять костыли в settings.php, тоже прошла! Костыли убрал, пациент пляшет без посторонней поддержки.
Всё-таки правильно я чувствовал что эти две проблемы как-то взаимосвязаны.