Возможно какое-то обновление ядра что-то поломало.
Я сам сейчас бьюсь с очередной загадочной проблемой с генерацией стилей, правда в восьмерке, попробую написать подробное описание того, что происходит, может коллективный разум найдет причину, может и с вашим случаем заодно разберемся.
Рад, что помогло, но надо понимать, что это не решение, а затычка. Надо бы разобраться почему именно стили перестали создаваться и исправить .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-кода лайтбокса.
Уже попробовал "на коленке" - действительно при включенном IPC анониму всегда отдается единожды закэшированная страница независимо от куки. Но при выключенном IPC даже кэш-контекст не пришлось в явном виде настраивать - страницы отдаются чотко разные с кукою и без. Возможно модуль Request data conditions что-то сам колдует с кэшем - я не вникал пока.
Так уже написаны - в упомянутом Request data conditions реализованы условия и по cookie, и по session storage, и по query parameter. Они появляются прям в Block Layout/Configure Block. Имя куки и ее значение вводятся там же в условиях, в код ничего не зашито.
Тут, наверное, следует пояснить, что отображение полей самой ноды не меняется вообще никак - они сидят в одном и том же виде и в одном и том же месте страницы независимо от режима. Все блоки, которые отображаются по-разному в разных режимах (карты, фотогалереи), являются вьюшками, увязанными с текущей нодой через контекстный фильтр.
В общем, подумал и оставил как есть
Меня смущали две вещи: "бинарность" данных, помещаемых в строковую переменную, и их потенциальный размер.
Прочтение документации по PHP показало, что размещение произвольных бинарных данных (включая 0x00) в строке абсолютно штатная ситуация для PHP (подозреваю, что все, кроме меня, это знали давно, но я же не настоящий сварщик
для представлений подходит, а мне нужно именно на ноде такое сделать.
А что такое "следующая нода" вне контекста представления? Последовательность нод, отобранная по определённым критериям и отсортированная нужным образом, и есть представление. С пейджером на 1 ноду и views infinite scroll.
В данном случае от REST'а фактически используется только инфраструктура, на самом деле не представляю себе выдачу KML/KMZ именно в REST-контексте - речь идёт об отдаче пользователю файла, который он сохраняет.
Перестали отображаться аватары пользователей.
Возможно какое-то обновление ядра что-то поломало.
Я сам сейчас бьюсь с очередной загадочной проблемой с генерацией стилей, правда в восьмерке, попробую написать подробное описание того, что происходит, может коллективный разум найдет причину, может и с вашим случаем заодно разберемся.
Перестали отображаться аватары пользователей.
Рад, что помогло, но надо понимать, что это не решение, а затычка. Надо бы разобраться почему именно стили перестали создаваться и исправить .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-кода лайтбокса.
Разные режимы просмотра одной и той же ноды - как лучше реализовать
PS Да, модулёк сам грамотно проставляет правильный кэш-контекст, ничего дополнительного делать не нужно.
Разные режимы просмотра одной и той же ноды - как лучше реализовать
Уже попробовал "на коленке" - действительно при включенном IPC анониму всегда отдается единожды закэшированная страница независимо от куки. Но при выключенном IPC даже кэш-контекст не пришлось в явном виде настраивать - страницы отдаются чотко разные с кукою и без. Возможно модуль Request data conditions что-то сам колдует с кэшем - я не вникал пока.
Разные режимы просмотра одной и той же ноды - как лучше реализовать
Сначала так попробую, конечно. Но, судя по нагугленному, придется.
Я про куки раньше только слышал, в руках ни разу не держал
Разные режимы просмотра одной и той же ноды - как лучше реализовать
Так уже написаны - в упомянутом Request data conditions реализованы условия и по cookie, и по session storage, и по query parameter. Они появляются прям в Block Layout/Configure Block. Имя куки и ее значение вводятся там же в условиях, в код ничего не зашито.
Разные режимы просмотра одной и той же ноды - как лучше реализовать
Тут, наверное, следует пояснить, что отображение полей самой ноды не меняется вообще никак - они сидят в одном и том же виде и в одном и том же месте страницы независимо от режима. Все блоки, которые отображаются по-разному в разных режимах (карты, фотогалереи), являются вьюшками, увязанными с текущей нодой через контекстный фильтр.
Отдача большого зипа из контекста REST-энкодера
В общем, подумал и оставил как есть
Меня смущали две вещи: "бинарность" данных, помещаемых в строковую переменную, и их потенциальный размер.
Прочтение документации по PHP показало, что размещение произвольных бинарных данных (включая 0x00) в строке абсолютно штатная ситуация для PHP (подозреваю, что все, кроме меня, это знали давно, но я же не настоящий сварщик
Отдача большого зипа из контекста REST-энкодера
Мне почему-то интуитивно так и казалось - спасибо за подтверждение
Отдача большого зипа из контекста REST-энкодера
После обновления ядра Drupal с 8.6.2 до 8.6.3 ошибка отображения административной темы
Deja vu?
https://drupal.ru/node/138315
Автоподгрузка следующей ноды при скролинге страницы
А что такое "следующая нода" вне контекста представления? Последовательность нод, отобранная по определённым критериям и отсортированная нужным образом, и есть представление. С пейджером на 1 ноду и views infinite scroll.
Отдача большого зипа из контекста REST-энкодера
В данном случае от REST'а фактически используется только инфраструктура, на самом деле не представляю себе выдачу KML/KMZ именно в REST-контексте - речь идёт об отдаче пользователю файла, который он сохраняет.
Ссылки поверх разных областей изображения, как сделать?
https://www.drupal.org/project/responsive_imagemaps ?
PS Я им не пользуюсь, чиста умею гуглить