Ну нет у меня никаких следов и упоминаний nginx'а и его конфигурации на радоновском хостинге. Лежит в корне нетронутый web.config от друпаловского дистрибутива, сейчас снес его вообще для прикола - ничего не изменилось.
Минуточку. Миниатюры не генерятся в момент запроса картинки. Миниатюры генерятся во время рендера форматтеров и всего такого. То есть, сервер перед тем, как "выплюнуть" ссылку на миниатюру в атрибуте src, должен её предварительно сгенерировать, если в папке со стилями этой картинки ещё нет.
Попробовал вставить LogLevel debug в .htaccess , получил довольно неожиданный результат: все картинки отдались с кодом 500, но при этом отдались и отрисовались как ни в чем ни бывало
Никаких других подробностей в логе нет - по прежнему одна запись на один запрос.
Может опять глупость скажу: а если gallery_formatter отключить, тогда эффект сохраняется?
Я пробовал с другой галереей и другим стилем (просто снёс часть давно сгенерированных "миниатюр"): результат такой же, куча 404 при первом обращении, при этом все картинки генерируются и показываются.
Отвечу на все вопросы сразу:
Панель управления хостингом - cPanel, хостинг один и тот же, сервер - Apache.
Вот - весь /sites/default/files/.htaccess от прод-сервера, где проблема есть:
Возможно какое-то обновление ядра что-то поломало.
Я сам сейчас бьюсь с очередной загадочной проблемой с генерацией стилей, правда в восьмерке, попробую написать подробное описание того, что происходит, может коллективный разум найдет причину, может и с вашим случаем заодно разберемся.
Рад, что помогло, но надо понимать, что это не решение, а затычка. Надо бы разобраться почему именно стили перестали создаваться и исправить .htaccess.
Файл error_log должен быть в корне инсталляции друпала, там же где index.php, .htaccess и директории core, modules, themes и т.п. Директория logs это на уровень выше.
Может ли кто-нибудь пояснить, о чем идет речь и нужно делать?
Это просто комментарий к его последнему патчу, пояснение что именно он там поменял в коде. Разбираться в этом не обязательно. "Что делать?" - поставить патч. Если всё равно не работает - написать туда же.
Слово "перестали" подразумевает что раньше работали, так? Что менялось в конфигурации перед тем как перестали работать? Не накосячено ли в теме, шаблонах, стилях? Может оно выводится, но или белым по белому, или через какой-нибудь display:none спрятано?
Присоединюсь к предыдущему оратору насчёт перевода и добавлю, что в восьмёрке специально введена возможность "переводить" с дефолтного языка на дефолтный же, то есть просто модифицировать системные сообщения для конкретного сайта под конкретные нужды.
На странице /admin/config/regional/language выбрать язык по умолчанию и поставить галку напротив "Включить перевод интерфейса на xxx". Потом вводить свои варианты сообщений как обычные переводы на /admin/config/regional/translate
PS Сущность в любом случае называется picture и содержит ровно одну картинку (эдакая Media для бедных), и количество строк вью всегда равно количеству картинок, так что тут проблем не будет.
Да, я уже вхукнулся через hook_views_post_execute и убедился, что total_rows содержит правильный тотал во всех моих конкретных случаях. А раз так, и никакой дополнительной нагрузки на сервер не требуется, то я наверное из этого хука буду сохранять тотал в drupalSettings (в разрезе вью), и брать оттуда уже из js-кода лайтбокса.
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Ну нет у меня никаких следов и упоминаний nginx'а и его конфигурации на радоновском хостинге. Лежит в корне нетронутый web.config от друпаловского дистрибутива, сейчас снес его вообще для прикола - ничего не изменилось.
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Так выяснили и посмотрели давно.
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Попробовал вставить LogLevel debug в .htaccess , получил довольно неожиданный результат: все картинки отдались с кодом 500, но при этом отдались и отрисовались как ни в чем ни бывало
Никаких других подробностей в логе нет - по прежнему одна запись на один запрос.
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Я пробовал с другой галереей и другим стилем (просто снёс часть давно сгенерированных "миниатюр"): результат такой же, куча 404 при первом обращении, при этом все картинки генерируются и показываются.
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Попробую попозже, если это возможно сделать на уровне .htaccess, без доступа к общей конфигурации апача.
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Боюсь что нет (или я просто не умею его искать
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Нету ничего.
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Apache. В логах сервера вот так:
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Убрал (вместе с соответствующими RewriteCond), ничего не изменилось. Картинки все отдаются, но свежесгенерированные с кодом 404.
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Отвечу на все вопросы сразу:
Панель управления хостингом - cPanel, хостинг один и тот же, сервер - Apache.
Вот - весь /sites/default/files/.htaccess от прод-сервера, где проблема есть:
Стилизованные картинки нормально генерятся и отдаются, но с кодом 404
Всё верно, но зачем свежесгенерированная картинка отдается с кодом 404? Причем на одном сайте из двух?
Перестали отображаться аватары пользователей.
Возможно какое-то обновление ядра что-то поломало.
Я сам сейчас бьюсь с очередной загадочной проблемой с генерацией стилей, правда в восьмерке, попробую написать подробное описание того, что происходит, может коллективный разум найдет причину, может и с вашим случаем заодно разберемся.
Перестали отображаться аватары пользователей.
Рад, что помогло, но надо понимать, что это не решение, а затычка. Надо бы разобраться почему именно стили перестали создаваться и исправить .htaccess.
Перестали отображаться аватары пользователей.
Ok.
Настройка перевода материала Книга в Drupal 8
Файл error_log должен быть в корне инсталляции друпала, там же где index.php, .htaccess и директории core, modules, themes и т.п. Директория logs это на уровень выше.
Настройка перевода материала Книга в Drupal 8
И еще раз: это не совет. Это краткое описание того, что он изменил своим патчем.
Настройка перевода материала Книга в Drupal 8
Это просто комментарий к его последнему патчу, пояснение что именно он там поменял в коде. Разбираться в этом не обязательно. "Что делать?" - поставить патч. Если всё равно не работает - написать туда же.
Шаблон для типа материала в Drupal 8
https://www.drupal.org/project/drupal/issues/2867746
Проблема с Views - не работают некоторые форматы вывода - D8
Ну вот, пока писал...
Проблема с Views - не работают некоторые форматы вывода - D8
Слово "перестали" подразумевает что раньше работали, так? Что менялось в конфигурации перед тем как перестали работать? Не накосячено ли в теме, шаблонах, стилях? Может оно выводится, но или белым по белому, или через какой-нибудь display:none спрятано?
Материал публикуется автоматически, когда размер изображения больше допустимого
Так не устанавливайте ограничение по весу вообще, и всё.
Как изменить системные сообщения о статусе заполнения формы?
Присоединюсь к предыдущему оратору насчёт перевода и добавлю, что в восьмёрке специально введена возможность "переводить" с дефолтного языка на дефолтный же, то есть просто модифицировать системные сообщения для конкретного сайта под конкретные нужды.
На странице /admin/config/regional/language выбрать язык по умолчанию и поставить галку напротив "Включить перевод интерфейса на xxx". Потом вводить свои варианты сообщений как обычные переводы на /admin/config/regional/translate
Не соображу куда воткнуть $view->total_rows для последующей передачи в js-лайтбокс
PS Сущность в любом случае называется picture и содержит ровно одну картинку (эдакая Media для бедных), и количество строк вью всегда равно количеству картинок, так что тут проблем не будет.
Не соображу куда воткнуть $view->total_rows для последующей передачи в js-лайтбокс
Да, я уже вхукнулся через hook_views_post_execute и убедился, что total_rows содержит правильный тотал во всех моих конкретных случаях. А раз так, и никакой дополнительной нагрузки на сервер не требуется, то я наверное из этого хука буду сохранять тотал в drupalSettings (в разрезе вью), и брать оттуда уже из js-кода лайтбокса.