Yuran25 wrote: Теперь вопрос - что сделать чтобы при включенных галках нормально работало?
До рекомендованного конфига Nginx тоже доберусь:)
Дело именно в конфиге nginx - надо с ним разбираться. Более конкретно не подскажу так как сам nginx не настраивал никогда.
И никакие папки в files вручную создавать не надо было - лучше их удалить. Пусть лучше Друпал сам создаст с правильными правами - проблемы могут быть и из-за неправильных прав на эти папки.
PS И еще надо на режим кэширования посмотреть - если для страницы разрешено кэширование, и она уже закэшилась в своем прежнем виде, то никакой хук и вызываться не будет - просто возьмется готовый рендер из кэша.
"it is very important to have ORDER BY with LIMIT executed without scanning and sorting the full result set, so it is important for it to use index – in this case, index range scan will be started, and query execution stopped as soon as the required amount of rows generated" https://www.percona.com/blog/mysql-order-by-limit-performance-optimization/
Вьюс сам по себе не умеет ни шерстить базу, ни перебирать кучу статей по фильтру. Вьюс передает SQL-серверу ровно один SQL-запрос (его можно посмотреть прямо в определении view в самом низу) и получает от него ответ. Параметры пейджера (LIMIT и OFFSET) включены в этот запрос, так что возвращено будет ровно столько строк, сколько указано в настройках пейджера.
А вот насколько быстро и оптимально будет выполняться этот самый SQL-запрос, зависит от размера базы данных и наличия в ней необходимых индексов для данного запроса.
Сам не пробовал так делать, но модуль Views Extras (Session/Cookie/Token Support) умеет использовать session variables в фильтрах view, так что можно попробовать обойтись без программирования на сервере.
Я про это и говорю. Друпал мотает по всей дороге из ряда в ряд. Сначала заставили мышекликеров учить CLI и композер, в результате половина ушла в ВордПресс. А всего то нужно было приделать к композеру дружелюбную веб-морду. Теперь интерфейс даже не пользователя, а сайтбилдера затачивают под людей, которые не в состоянии читать и понимать написанное, а в состоянии только выбрать наиболее понравившуюся картинку из десятка предложенных...
Ключ к решению скорее всего лежит в файле моймодуль.install.
Как вариант, в twig-шаблоне ноды подставить после статической части ссылки
{{ content.field_tags.0.value }}
Дело именно в конфиге nginx - надо с ним разбираться. Более конкретно не подскажу так как сам nginx не настраивал никогда.
И никакие папки в files вручную создавать не надо было - лучше их удалить. Пусть лучше Друпал сам создаст с правильными правами - проблемы могут быть и из-за неправильных прав на эти папки.
Этого не может быть. Вы же на своем сайте этот путь открываете?
https://vizup.ru/admin/config/development/performance
И предварительно войти админом конечно нужно.
Для начала отключите агрегацию css и js на странице /admin/config/development/performance
Потом читайте тут
Во, а я думал я один такой
Нет, в том-то и дело. Отключил, вроде ничего не отлетело. Пока
Сайт по http открывается?
https://drupal.ru/node/145300
Это приглашение заглянуть в логи веб-сервера. Там написано в чем проблема.
Кстати, кэш чистили?
Самое главное, ни в коем случае не говорите какие именно ошибки, а то гадать неинтересно будет
Это что ж за запрос такой, которому нужны абсолютно все поля всех записей?
Ну а в чём конкретно ужас-то?
А вариант решения, реализованный в issue #3314446, не устраивает чем?
Для 10.2 надо использовать старый хук entity_view_mode_alter и код "Before" из Вашей первой ссылки - там всего-то на одну проверку больше.
PS И еще надо на режим кэширования посмотреть - если для страницы разрешено кэширование, и она уже закэшилась в своем прежнем виде, то никакой хук и вызываться не будет - просто возьмется готовый рендер из кэша.
А версия Drupal на сайте точно 10.3? Хук ведь только в версии 10.3 появился.
"it is very important to have ORDER BY with LIMIT executed without scanning and sorting the full result set, so it is important for it to use index – in this case, index range scan will be started, and query execution stopped as soon as the required amount of rows generated"
https://www.percona.com/blog/mysql-order-by-limit-performance-optimization/
Вьюс сам по себе не умеет ни шерстить базу, ни перебирать кучу статей по фильтру. Вьюс передает SQL-серверу ровно один SQL-запрос (его можно посмотреть прямо в определении view в самом низу) и получает от него ответ. Параметры пейджера (LIMIT и OFFSET) включены в этот запрос, так что возвращено будет ровно столько строк, сколько указано в настройках пейджера.
А вот насколько быстро и оптимально будет выполняться этот самый SQL-запрос, зависит от размера базы данных и наличия в ней необходимых индексов для данного запроса.
Да наверняка.
А модуль Interface translation включен?
Хотя нет, тут же сортировка нужна, а не фильтр.
Сам не пробовал так делать, но модуль Views Extras (Session/Cookie/Token Support) умеет использовать session variables в фильтрах view, так что можно попробовать обойтись без программирования на сервере.
В фильтрах view добавлено условие что поле is not empty (NOT NULL)?
Может быть не хватает модуля Slick Views ?
Я про это и говорю. Друпал мотает по всей дороге из ряда в ряд. Сначала заставили мышекликеров учить CLI и композер, в результате половина ушла в ВордПресс. А всего то нужно было приделать к композеру дружелюбную веб-морду. Теперь интерфейс даже не пользователя, а сайтбилдера затачивают под людей, которые не в состоянии читать и понимать написанное, а в состоянии только выбрать наиболее понравившуюся картинку из десятка предложенных...