1. Главная
  2. OldWarrior

OldWarrior: Комментарии

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

15 августа в 16:56

Обмен полотенцами текста подразумевается. Это вместо кодописания, как бы. Всё равно - хоть так стучать по клаве, хоть так. Подумаешь, на несколько Кб больше. У нас же, у программистов, времени с избытком, любой дурак знает.

27 июля в 1:20

Да, прошу прощения. Сам уже забыл, что в случае с главной всё не так просто.

Тогда:

1. либо модуль, который подсказал Васек
2. либо правка шаблона page--front.html.twig
3. либо вместо штатного вьюс (которая по адресу /node) создать свою страницу (тип материала "Страница"), например, с синонимом /frontpage и указать её в качестве главной в "Конфигурация > Система > Основные настройки сайта"

Мне последний пункт представляется самым быстрым и простым.

26 июля в 16:29

xSPiRiTx wrote: Это вьюха с названием "Главная страница". Как сделать главную страницу полностью пустой?
Требуется сделать главную, которая состоит только из блоков.

В чём проблема не понял. Тест "Добро пожаловать" - это просто блок (который так и называется обычно - "Содержимое"). Скройте его для главной.

19 июля в 17:58
1

1. Просто welcome screen. Чтобы дефолтное сообщение ушло, нужно создать какой-то материал и тогда именно созданные материалы будут отображаться на главной. По сути, главная страница отображает представление списка материалов. См. "Структура > Представления".

Блоки (если прям реально они все выключены в "Структура > Схеме блоков") могут вставляться в регионы шаблона темой оформления по умолчанию.

2. Штатно - нет.

3. В точку.

10 июля в 13:42

РЕШЕНИЕ:

В общем, в итоге быстрее всего оказалось решить вопрос через сисадмина, поскольку доступа к конфу nginx у меня нет. Растормошил его и дал маску пути /flag/flag/like_content/*. Он уже добавил нужные правила для 404 в конф.

10 июля в 13:23

Andruxa wrote: ого, там Апач?

Да вот только что растормошил админа, говорит, что там nginx. Т.е. мои манипуляции в расчёте на апач были бесполезны. ) Что-то вообще не подумал об nginx-альтернативе.

Кстати, вопрос: а почему "ого"? Апач на нагруженных проектах - редкость?

10 июля в 12:54

Andruxa wrote: написать свой RouteSubscriber где заменить контроллеры модуля Flag на свои, возвращающие 404, ну или хакнуть пропатчить контроллеры Flag'a - думаю, больному от этого хуже уже не станет

1 июля в 17:30

marassa wrote: То есть Internal Page Cache (не путать с Dynamic Page Cache, который у меня включён и что-то не особо ускоряет) вообще игнорирует контексты. Тогда зачем их добавлять в билд-массив?

Я сейчас смутно припоминаю: году так в 2016, когда D8 был свеж, как утренняя булочка из пекарни, мы вроде как парились на одном проекте с аналогичным вопросом. Вроде что-то кешировалось неуместным образом для гостей в форме на фронте. Не помню точно, как решилось тогда, но кажется, действительно выключили модуль Internal Page Cache.

1 июля в 11:15

PS. Опять же, мы рассматриваем типичный случай, когда build-массив представляет содержимое, отдаваемое контроллером. Но всё вышенаписанное справедливо и для любых других рендер-массивов, например, блоков.

1 июля в 11:05

marassa wrote: То есть в самом начале работы контроллера страницы нужно проверить нет ли уже в кэше страницы с этим адресом И ЭТОЙ КУКОЙ, и если есть, то просто отдать из кэша. А если нет, и дело дошло до рендеринга страницы, то после рендеринга нужно положить свежеотрендеренную страницу в кэш, причем с id, включающим куку.

12 июня в 20:16

Тогда в теории они таки обязаны заняться вашей проблемой. Поскольку MySQL-сервер работает, так сказать, в глобальном контексте - для всех аккаунтов и, следовательно, вы не можете напрямую повлиять на его работу и файлы БД. На shared-хостингах обычно вообще ни на что из окружения невозможно повлиять.

12 июня в 20:11

chei1ahJoh8K wrote: какая база

Указанный автором файл .FRM относится к структуре таблиц MySQL.

chei1ahJoh8K wrote: там же написано - много открытых файлов

Вторую часть сообщения я несколько пропустил. Ну да, много открытых файлов, поэтому открыть semaphore.frm система уже не может. Возможно, имеются какие-то незавершённые процессы, не закрывшие корректно файлы. Тут ребутнуть MySQL бы, но у автора shared-хостинг .

12 июня в 18:16

Ну, строго говоря, пользовательские БД (и стало быть связанные с ними файлы) - это как бы данные пользователя. Т.е. на хостинге-то может быть всё и хорошо, как они говорят: ОС в норме, ресурсы в норме, сервера крутятся-пашут. А вот пользовательские данные - это данные, относящиеся к аккаунту, а не к хостингу. Так что с формальной стороны они могут быть правы, хотя это и не очень чуткий к клиенту подход. )

Но вообще здесь многое зависит от разновидности хостинга. Какой у вас: shared или что-то выделенное?

12 июня в 17:23

Браузер мог также закешировать сопоставление IP - домен. Попробуйте из другого браузера, например.

Кстати (это не прямо относится к проблеме, но упоминаю, раз переносили на другой IP) - стоит посмотреть ещё 'trusted_host_patterns' в settings.php. Бывает, что паттерны там прописывают не по домену, а по IP. В таком случае, тоже могут возникнуть проблемы позднее. Но это уже актуально, когда сайт на Друпале доступен и работает.

12 июня в 17:16

Kublahan wrote: Что такое semaphore.frm?

FRM files are used to define the format of a table used with MySQL. MySQL is a cross-platform relational database . FRM files will have the same name as the table they reference, but with a . FRM extension.

Иными словами - побилась база на хостинге. Если есть бекап БД, то лучше восстановиться, тут больше ничего не сделаешь.