Сергей Вольвич написал: Вот уж и правда, ну наломали дров, за надцать лет, ну зачем в обновление пихать еще один новый велосипед, с этим драным шрифтом? Жесть какая-то. Чесотка что-ли там в бюро инновации битрикса? Дело не в размере css-кода, как выше писали, там же еще подгружается пара десятков шрифтовых файлов размером уже 986кБ!!!, дядя Коваленко! Всем клиентам хардкодю код и пусть весь мир подождет.
Добрый день! Подскажите, что делаете и в каком месте?
Виталий Глазунов написал: Можно кастомизировать стандартные шрифты путём копирования в local нужных шрифтов. Например, так кастомизировать шрифт OpenSans и добавить ему параметр font-display: swap, копируем папку /bitrix/js/ui/fonts/opensans/ в /local/js/ui/fonts/opensans/. В config.php соответственно, исправляем ссылку на local.
Либо чтобы просто отключить данный шрифт можно в config.php ничего не возвращать.
этот шрифт уже есть у любого, кто посетил хотя бы десяток сайтов, в кеше браузера, а то и в опер. системе, грузить его еще раз полный дебилизм разраба.
PS Интересно, на сколько битрикс наварился за последние дни, в плане покупки продлений лицензий?)
о повод для конспирологии, эт я люблю
ну если дыра в модуле есть, это как минимум известно и прогеру этого модуля. Вы митингуете против теорий заговора, но что скажете про подобную историю с обиженным прогером под модикс в 2018 - он просто ушел из команды и не закрыл дыру, компонент gallery, причем этот компонент в отличие от других компонентов несколько лет не обновлялся, т.е. по мнению разраба там было все отлично, но нет... через какое-то время дыра была использована в массовом масштабе. Решение по лечению было такое - УДАЛИТЬ этот компонент и далее обновить движок. А термин "теория заговора" был придуман и введен в оборот именно теми, кто не желал каких-то раскопок и расследований, заставляя высмеивать всех сомневающихся, как видим, в 21 веке этот термин становится весьма опасен, будучи употреблен...
Алексей Вдовин написал: Ещё вариант по ядру - думаю в саппорте можно запросить файловый архив актуальной версии ядра, у себя все снести и накатить так, сказать с эталона - тогда вариант бэкдора в файлах ядра точно уйдёт в минус.
Сам проект в гите должен быть (для быстрого отлова изменений), плюс можно и ядро в гит запихать (пока не уладится с вируснёй).
А каким редактором кода редактировали css? Как вариант, сохраните себе на компьютер этот файл template_styles.min.css и затем удалите его с хостинга, тогда битрикс подключит несжатую версию template_styles.css, в которой скорее всего остался исходный работоспособный вариант. А пока что ситуация выглядит так - испортил файл, все слетело, почему я забыл про бекапы.
Андрей Николаев написал: Сергей Вольвич , судя по описанию, предполагаю что кто-то в index.php вынес компонент bitrix:catalog.section без включенного ЧПУ
Вынести вынесли, да вот SEF включен там... Пришел к выводу, что это была проделка малограмотного криворука, правило было самым последним в urlrewrite.php и с наибольшим SORT, т.е. отрабатывало, если другие правила не подошли, сам каталог в urlrewrite.php прописан выше вот так:
Сама регулярка '#^\\??(.*)#' по факту возвращала true для ЛЮБОГО адреса))) Т.е. некий такой криворукий аналог отработки ошибки 404, при том что есть штатная возможность. Что и приводило к основной ошибке - несуществующие адреса для статичных папок перекидывало на главную, сам каталог 404 отрабатывал правильно. Снес к чертовой матери, все заработало как часы.
Александр Гусев написал: Да, этот код для торговых предложений...
А в чем логика? Страница товара с ТП должна весить в два раза больше? Ну да ладно бы если так. Но. Проверил страницы товаров без ТП, там также генерируется простыня кода.
Господа, при встрече с дефолтным шаблоном eshop_bootstrap_некий_цвет бегите от него подальше!!!)))
Александр Гусев написал: попробуйте уберите. ищите в шаблонах по вхождению JCCatalogItem на первый взгляд — в вашем проекте это не нужно
К сожалению, не победил... Формируются куски JCCatalogSectionComponent, JCCatalogItem, каждый в нескольких экземплярах, т.е. на каждый товар, который есть на странице, включая модули Популярные, Похожие, перс. рекомендации и прочая... Отключая генерацию этих кусков кода, теряю возможность в товарах с ТП выбирать тут же цвет, размеры. Еще обратил внимание, например, модуль Похожие товары, там формируются уменьшенные картинки, в исходном коде так и есть, НО эти обсуждаемые скрипты вставляют туда опять большие оригинальные картинки, из своего массива... Содом и Гоморра какая-то)))
Георгий Коваленко написал: Можно сказать, что эти полкилобайта и 100 миллисекунд ни на что не влияют, но даже если так — как по мне, это не повод держать их просто так.
не! Дело не в размере css-кода, как выше писали, там же еще подгружается пара десятков шрифтовых файлов размером уже 986кБ!!!, дядя Коваленко!
Вот уж и правда, ну наломали дров, за надцать лет, ну зачем в обновление пихать еще один новый велосипед, с этим драным шрифтом? Жесть какая-то. Чесотка что-ли там в бюро инновации битрикса? Дело не в размере css-кода, как выше писали, там же еще подгружается пара десятков шрифтовых файлов размером уже 986кБ!!!, дядя Коваленко! Всем клиентам хардкодю код и пусть весь мир подождет.
Egor Jorik написал: Столкнулся с аналогичной проблемой.
Блин, зачем лопатить компоненты, страдая в течение всего жизненного пути сайта, если достаточно тщательнее изучить правила редиректа, иной раз достаточно одной строки в htaccess. Сейчас яндекс уже через неделю подхватывает новые урлы взамен старых. Байка о полном провале всего индекса и обновлении нового индекса не ранее чем через три месяца эксплуатируется горе-сеошниками, пытающихся тянуть бабло из всех щелей...
Для владельцев старых версии и не желающих платить за свежую версию ))): /bitrix/modules/socialservices/classes/general/vkontakte.php в строке, где получаем юзера, вместо
oleg@prilepa.ru написал: Подскажите, когда планируется доработать этот момент?Чтобы понимать, есть смысл сейчас продолжать городить обработчики событий, или нет.
require($_SERVER["DOCUMENT_ROOT"]. "/bitrix/header.php");
//Подключаем модуль работы с инфоблоками
CModule::IncludeModule('iblock');
//Уточняем какой будем использовать инфоблок
$arFilter = array(
'IBLOCK_ID' => 17,
);
//Получаем массив всех элетметов
$res = CIBlockElement::GetList(false, $arFilter, array('IBLOCK_ID','ID'));
//Перебираем все элементы инфоблока и записываем в массив их IDшники
while($el = $res->GetNext()):
echo $arElementsID[] = $el['ID'];
endwhile;
//Устанавливаем значения шаблонов SEO-данных у элементов, в данном случае пустые, т.к. нужно было их удалить
foreach($arElementsID as $key):
$ipropTemplates = new \Bitrix\Iblock\InheritedProperty\ElementTemplates (17, $key); //еще раз уточняем ID инфоблока
$ipropTemplates->set(array(
"ELEMENT_META_TITLE" => "",
"ELEMENT_META_KEYWORDS" => "",
"ELEMENT_META_DESCRIPTION" => "",
));
endforeach;
require($_SERVER["DOCUMENT_ROOT"]. "/bitrix/footer.php");
Алексей К написал: А можно ли сделать так, чтобы одна группа покупателей могла покупать под заказ при остутствии, а другие группы нет?
Я делал подобное, там же два пальца об асфальт))) Это голый php Формируешь без кеша переменную ГРУППА ПОКУПАТЕЛЯ Получаешь её в шаблоне где надо - в товаре или в категориях, в модулях НОВИНКИ и прочей лабуды... Применяешь условие - если да то ага, если нет то наверное)))
Только непонятно, зачем гавнять мою тему абсолютно посторонними вопросами??? Что один (Игорь Седых), что второй (Алексей К) - или ленивые на 200% или религия не позволяет... аминь!
Есть и еще один нюанс, что kernel_main.js и его брат css абсолютно не оптимизированы сами по себе, у меня например в шаблоне 20 css и js выведены почти в одну строку, а эти динозавры из версии в версию идут с миллиардом отступов в коде, пустыми строками и внимание(!!!) - с комментариями!!! ажуеть! КОМУ эти комменты? ЗАЧЕМ? Для себя походу оставляют, чтоб совсем не свихнуться в нагромождениях.... Мое мнение - это полнейшее неуважение к таким же коллегам по перу...