Если для поднятия левела в php, то можно и всё дописать. И без всякого друпала.

gun_dose wrote:

за был, как называется.

http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html

Не стоит быть столь категоричным в спорных утверждениях. Не значит, а вероятно.

На втором скрине вам гугл ответил, почему так происходит.

Невозможно.

Не, борьба с бутстрапом (по крайней мере раньше), заключалась в борьбе со стилями, который он навешивает по дефолту на тэги.

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

Почему не подходит? Взято с этой страницы, везде работало.

В settings.php добавить
$conf['x_frame_options'] = '';

Вы глобальный скоуп метатэгов редактируете? Или для конкретной Entity?
Мне кажется вам должна помочь данная страница доки, раздел "Standard usage scenario", пункт 4.

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:

Это к чему?

Прочитав рекомендацию, можно подумать, что надо работать из под пользователя root. Это фиаско.

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:

В моем архиве D7 его нет

А в коробке - есть.

1. Вес страницы - это значимая вещь без всякого сео. На тех же мобилках. Меньше скриптов, меньше стилей, больше кэша.
2. Это требуют не сеонисты, а сеорасты.

OMG

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:

под ssh root

Да! Прямо из под рута!

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:

rm -rf misc scripts includes modules themes profiles

Выше сказано.

Придёт @VasyOK, станет рассказывать за хлебные крошки на views - вы его не слушайте.

Великолепный ответ. А главное - подходит практически к любому вопросу на форуме.

Теоретически во всём виноваты контекстные ссылки (или как они там в д8), у которых классы убили.

Вообще говоря есть такое понятие, как critical_css. Оно имеет смысл. Если с умом подойти.

Тупой вариант в лоб:
1. Определить свой роут через hook_menu
2. Передавать ему в аргументы nid
3. В callback функции вызывать node_delete

Варианты повеселее - ставить модули для REST.

И совсем-совсем не друпальный путь - выяснить, почему всплывают 404-е если кэш не почистить

Теоретически - срипт мониторинга, который тупо отслеживает сколько проца отожрал солр, если больше какого-то значения - создавать писать в какое-либо доступное для друпала место (файлик в tmp, redis, drush vset, абстрактную систему мониторинга), мол баста карапузики, солр на ресурсной диете. Далее, уже в друпале, непосредственно перед поиском, проверять досутпен ли поиск по этому значению, да - ищем, нет - показываем message, мол попробуйте позднее.

Теоретически, на примере nginx - создать под поиск новый location с низким таймаутом, по таймауту отправлять на специфичную страницу ошибки. Ну то есть, если страница поиска отрабатывает больше 5 секунд - солру нездоровится, попробуйте позднее.

Да.

Ну да. Часто встречается сайт с API какого-либо сервиса на друпале сделанный. У твитера раньше был, сейчас из последнего встреченного - у logmein https://goto-developer.logmeininc.com/