Maxim_web_developer wrote:

И в итоге то что?

А в итоге - hook_rdf_namespaces не позволяет переопределять урлы. Массивы, которые определяются данным хуком объединяются по ключу, и если значения неодинаковые - ключ тупо дропается.

Результат выполнения функции block_get_blocks_by_region сохранить в переменную, в функцию render передавать перемменную.

А если бы код был не скрином, то и пример кода вам бы наваян был.

Да нифига. Есть сайт, о котором никто пока не знает. Тем не менее на него уже пришёл какой-то бот, определил CMS (запросами по характерным для CMS урлам), после чего попытался заюзать мартовскую уязвимость. Домену два дня, сайту день.

Вот вы тут иронизируете, а через пару недель выйдет какая-нибудь SA-CORE-005 - incorrect password hashing.

Поправка: взлом был через соседний сайт на хваленном вордпрессе с автообновлением.

VasyOK wrote:

Смысл Authcache - кешировать страницы для авторизированных пользователей?

Смысл Authcache - не кэшировать части страницы, уникальные для пользователя, и не важно, авторизован он, или нет. Например корзину, или токены форм.

Ну тогда скорее всего проблема где-то в кастомном коде. Других причин лично я не знаю.

В настройках прав досутпа - использовать страницы администрирования у пользователя стоит?

1. Не быстро, смысл есть.
2. Конфликтуют. Блок корзины не обновляется.
3. Разумеется.

Я вообще говоря хз что посоветовать. Интернет магазин - это не сайт для анонимов, без сессии не обойдёшься, а сессия убивает кучу механизмов кэширования друпала. Надо смотреть в сторону Authcache, я думаю.

Оформление -> Тема оформления административных страниц -> Seven и галочку Использовать административную тему при редактировании или создании материала

Тупое решение в лоб - добавить товарам Entity Reference поле "Сопутствующие товары" и выводить их вьюхой где надо.

misha89 wrote:

php.module(80)

Оооо, у вас батенька php-фильтр. Собственно надо искать, где используется эта гадость и выдирать её оттуда. Это ошибка уже не друпала, а родителей разработчика, который заюзал php-фильтр.

7.2 не поддерживается седьмым друпалом. Можно или отключить deprecated, или откатиться на php7.1

Будет. Рекомендованная - 7.1, минимальная поддерживаемая - 5.5.9
https://www.drupal.org/docs/8/system-requirements/drupal-8-php-requirements
UPD: только третий

Есть подозрение, что рабочие эксплоиты уже есть.

Прям всё-всё с нуля? Работу с базой, CSRF-защиту форм, админку для юзверей, движок для шаблонов, роутинг, управление ассетами, валидаторы и тысячи других юзкейсов?

Существуют причины, по которым люди используют CMS и фреймворки, и главная - не писать всё с нуля. А если используете чужие наработки - будьте готовы к уязвимостям в них.

А на чём? Видите ли, найденные уязвимости не говорят о "плохости" системы. Вопрос же не в самих найденных уязвимостях, а в оперативности их закрытия. Вот сейчас появляется куча топиков, мол взломали сайт. Так проблема не в друпале, а в том, что люди не обновились. Представьте себе, что подобную уязвимость нашли на впшечке, или джумле (не к ночи будет помянуто), всех точно так же за неделю предупредили, кто-то забил на обновление, сайт взломали. И что теперь? Система плохая? Или зря не обновлялялись?

Прямо в той же таблице, колонка uid - это id юзера. Добавляйте в условие.

SELECT COUNT(*) FROM node n WHERE n.type = :type AND n.created > :date_start AND n.created < :date_end

pr0g wrote:

Сайт был отключен для посетителей?

drup-user wrote:

Сервер - локалхост.

Смотря как сделана карта сайта, но вообще можно или изменить алиас или добавить новый.

По идее можно же на location вешать.

http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html
Но вдумчиво.

Модули для кропа