А что на странице /admin/config/regional/translate ?
Если в начале будут пустые (не переведенные) строки, то можно выбрать Поиск в: только переведенные строки.

PS Ещё настораживает то, что для языка "Английский" 53% строк переведено. Переведено с какого языка, если английский является базовым языком? Можно предположить, что кто-то русифицировал сайт извращенным способом, вбив русские переводы в английский язык. В общем, нужно понять кто ставил сайт, каким образом, что с ним потом делали.

А каким образом язык админки у вас изначально стал русским, при том что в списке языков русского даже нет? У вас в браузере случайно не включен автоперевод с английского на русский?

ivkoles23 wrote: При попутке удалить модуль через drush (drush pm:uninstall моймодуль) вылезает ошибка:

Ключ к решению скорее всего лежит в файле моймодуль.install.

Как вариант, в twig-шаблоне ноды подставить после статической части ссылки
{{ content.field_tags.0.value }}

Yuran25 wrote: Теперь вопрос - что сделать чтобы при включенных галках нормально работало?
До рекомендованного конфига Nginx тоже доберусь:)

Дело именно в конфиге nginx - надо с ним разбираться. Более конкретно не подскажу так как сам nginx не настраивал никогда.
И никакие папки в files вручную создавать не надо было - лучше их удалить. Пусть лучше Друпал сам создаст с правильными правами - проблемы могут быть и из-за неправильных прав на эти папки.

Этого не может быть. Вы же на своем сайте этот путь открываете?
https://vizup.ru/admin/config/development/performance
И предварительно войти админом конечно нужно.

Для начала отключите агрегацию css и js на странице /admin/config/development/performance
Потом читайте тут

pselfin wrote: А вам не проще на сервере развернуть дев, и работать с ним из любого места?

Во, а я думал я один такой

Сайт по http открывается?
https://drupal.ru/node/145300

alex-litvinov wrote: При создании пишет:
The website encountered an unexpected error. Try again later.

Это приглашение заглянуть в логи веб-сервера. Там написано в чем проблема.
Кстати, кэш чистили?

vert4 wrote: в деббагере полезли ошибки от jquery.min.js

Самое главное, ни в коем случае не говорите какие именно ошибки, а то гадать неинтересно будет

Никки wrote: Чем больше таблиц в запросе, тем запрос медленнее работает.

Это что ж за запрос такой, которому нужны абсолютно все поля всех записей?

Никки wrote: Ужас же, не?

Ну а в чём конкретно ужас-то?

А вариант решения, реализованный в issue #3314446, не устраивает чем?

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-запрос, зависит от размера базы данных и наличия в ней необходимых индексов для данного запроса.

henaki wrote: может я как-то неправильно вывожу

Да наверняка.

А модуль Interface translation включен?

Хотя нет, тут же сортировка нужна, а не фильтр.

Сам не пробовал так делать, но модуль Views Extras (Session/Cookie/Token Support) умеет использовать session variables в фильтрах view, так что можно попробовать обойтись без программирования на сервере.