при update в datamanager.php переданное значение (id файла) в false скидывается и всё тут

![]()
айди моего грида
![]() по идее через BX.Main.gridManager должно вытаскиваться, но я не нашел как именно ![]() |
|||||||||
|
|
|
|
Всё получилось!
Спасибо большое за предоставленный код. Был косяк в определении страницы из параметра LEFTOVERS_LIST=page-2 в формировании данных
|
|||
|
|
|
|
Запрашиваю несуществующие картинки из /upload/ - почему то отдаётся полноценная 404-я сгенерированная аппачем,
хотя такие вещи должны "рубиться" nginx-om Закомментировал блок (см.картинку) - всё взлетело! Я так понимаю у него приоритет выше чем у блока ниже. Ситуация хоть исключительная для продакшена, но у меня например в разработке очень частая т.к. на тестовые и локальные сервера я /upload/ не перетаскиваю. В итоге куча запросов к несуществующим картинкам и сайт просто ДИКО тормозит! Кто "шарит" в nginx - подскажите как пофиксить правильно это дело |
|
|
|
|
|
ну смысл я думаю Вы уже поняли:
в кеше по сути две переменные (видно на вашем скрине VARS) arResult + переменная отвечающая за сам шаблон (тут не важно что именно, этим Вы не порулите) в шаблоне для построения html кода может использоваться очень много данных из arResult, которые по факту дальше не нужны - вот их и "рубят" с помощью SetResultCacheKeys |
|
|
|
|
|
смысл такой - в arResult передаём всё что нужно для генерации шаблона (это понятно)
потом смотрим, что нам потребуется в component_epilog.php - и пихаем это в SetResultCacheKeys() по умолчанию этот метод не вызывается и куча лишнего идёт в кеш, хотя 99% всё это просто не используется я бы на месте Битрикса сделал наоборот, и было бы понятнее - если вызова SetResultCacheKeys не было - то arResult вообще не кешировать |
|
|
|
|
|
|||
|
|
|
|
|||
|
|
|
|
такого кода не было, добавил в шаблон - ничего не изменилось
тестирую так: в JS шаблона прописал 2ю страничку явным образом
вроде всё просто - ошибиться негде хз куда дальше копать ![]() |
|||
|
|
|