main 26.650.0: сброс счётчиков ленты пачкой и превью своих ссылок без похода наружу
Два изменения в ядре, оба — про лишнюю работу, которую система делала на ровном месте. Счётчики живой ленты научились сбрасываться одним вызовом вместо цикла, а превью ссылок перестало ходить HTTP-запросом на собственный портал. Ломающих удалений нет: все правки сигнатур — добавление аргументов с дефолтами.
Счётчики ленты: один вызов вместо N
Появился CAllUserCounter::clearLiveFeedCodes():
\CUserCounter::clearLiveFeedCodes(
$userId,
['**', 'livefeed'], // коды счётчиков
SITE_ID,
sendPull: true,
cleanCache: true,
);
Зачем — понятно из соседнего модуля в том же батче. В im 26.800.0 приехали LiveFeedReadAllHandler и событие onSpaceLiveFeedReadAll: сценарий «прочитать всё» в ленте. Раньше он означал обход кодов по одному, и на каждый код — свой pull-event и своя инвалидация кэша. Пользователь жал одну кнопку, портал получал пачку пушей. Теперь коды гасятся списком, а pull уходит один.
Рядом — SendPullEvent() с новым аргументом $ensureZeroForGroupedCode = false. Это про застревающие счётчики: когда сгруппированный код обнуляется, клиенту нужно явно отправить ноль, иначе UI останется с висящей цифрой, которую нечем сбить.
UrlPreview: свой домен больше не дёргаем снаружи
Новый protected-метод UrlPreview::isOwnDomain(Uri $uri) сравнивает хост ссылки с SITE_SERVER_NAME и опцией main.server_name. Если хост свой и Router::dispatch() узнаёт URL — превью помечается как TYPE_DYNAMIC и строится без внешнего запроса.
До этого портал, встретив в сообщении ссылку на самого себя, честно шёл за ней HTTP-клиентом. В худшем случае — на закрытом контуре, за прокси или при кривом DNS — этот запрос просто не проходил, и превью внутренних страниц не работало вовсе. Заодно на один исходящий запрос по пользовательской ссылке меньше — обычная SSRF-гигиена.
API миграций: два новых параметра
Ядро продолжает докручивать UpdateSystem\Migration (модули на него как раз массово переезжают в этом же батче):
Migration\Event::register()/registerCompatible()—?int $sort = null, порядок вызова обработчика. Раньше сортировку в миграции задать было нечем, всегда получалось 100.Migration\Stepper::add()/addIfModuleExists()/addIfModuleInstalled()—?int $execDelay = null, задержка первого запуска.
С execDelay есть неочевидная деталь, которую видно только в коде: внутри стоит max($delay, $execDelay ?? 0), где $delay — среда исполнения (60 секунд по умолчанию, 600 в облаке, 900 при установке дистрибутива). То есть execDelay умеет только отодвинуть запуск, но не приблизить. Указать 10 секунд и получить старт через 10 не выйдет — параметр про «этот степпер тяжёлый, пусть подождёт подольше».
Что делать
- Если у вас есть свой сценарий массового прочтения ленты — перепишите цикл на
clearLiveFeedCodes(). - Если наследуете
Event::register,Stepper::addилиSendPullEvent— допишите новые параметры в сигнатуру наследника, иначе PHP 8 выдаст предупреждение о несовместимости. - Обычные вызовы этих методов трогать не нужно: все аргументы опциональные.
