если речь про google pagespeed на опыте убедился что jpegtran и им подобные не дают никакого эффекта - т.к. уменьшает всего на несколько процентов. (убедится можно попробовав https://rivetweb.github.io/rodzeta.pageoptimizeplus/ ) и гугл все равно выводит эти изображения для оптимизации.
а вот уменьшение качества jpg изображения до 90 или 85 дает очень даже хороший эффект. файл уменьшается до половины размера и гугл становится доволен результатом.
Anatoly Stupin написал: Не подскажешь, стандартная форма обратной связи уже вшита в "Управление сайтом"? Ибо не вижу в админке ничего, их, похоже, вручную писали ребята, которые предоставили сайт.. с неработающими формами)
это стандартный компонент БУС который поставляется с самой начальной редакции - "Первый сайт". а мой модуль всеголиш добавляет доп поля для него через стандартный механизм событий Bitrix. не вижу смысла писать кастомный компонент - веть это лишние затраты на его поддержку.
единственное что надо сделать - добавить полей в коде шаблона компонента. в будущем добавлю какойто мастер чтобы это мог простой пользователь.
какая разница на чем делать http-запросы. хоть из bash через curl.
почитайте как правильно составлять http запросы из .NET - это стандартные возможности .NET фрейморка описанные в документации. нафига это index.aspx
сделайте тестовый скрипт без интерфейса, без ничего чтобы локализовать проблему. я думал уровень .NET разработчиков намного больше. пишут unit тесты всякие и т.п. а тут такое
bitrix достаточно консервативен и имеет единообразное окружение. почему нельзя просто настроить N-проектов в одной виртуалке? зачем городить под каждую отдельный образ?
Евгений Жуков написал: В обновлении 16.5.4 вышла возможность получения пользовательских полей разделов. Работа со значениями свойств элементов еще не реализована.
В 17 версии нам ждать или продолжать вести "гибридную" разработку?
нет. надо использовать только старое api и забить на новое.
Николай Гайдукевич написал: Не терпится начать полноценно использовать D7, но делать симбиоз старого и нового API в компонентах не хочется.
пару раз пробовал типа написать полность на новом api но плюнул на это дело - документации адекватной нет. функционал недоделан.
когда появится человеческая документация уровня старого api. тогда и перейду на это хваленое d7. с какой стати надо тратить время на поиск аналогов. когда с помощью проверенного старого апи можно решить задачу 10 раз писателям bitrix-документации рекомендую прямо сейчас начать добавлять в документации старого api ссылки на аналоги в новом api или удалить к черту эту новую недо-документацию по d7 генеренную автоматом.
веть уже реализовано в php, просто и стандартно - нет надо обязательно свой велосипед изобрести с несовместимым api. время разработчика веть все равно девать некуда. пусть изучает и разбирается в логике работы.
yii2 програмисты такие програмисты. им фреймворк мозг атрофирует настолько что готовы даже выдрать код из обмена битрикс. вместо того что бы почитать доку и формат по обмену с 1С не говоря уж об элементарно изучении начальных материалов по возможностям CMS Bitrix
никак. точнее это можно сделать чере SQL запросы - но это уже будет не по канонам D7 ORM. поэтому работайте через события сущности и забудьте про все крутые фичи СУБД. потомучто D7 ORM использует принципы NoSQL - т.е. все плюшки СУБД должны быть отброшены в угоду объектноориентированности сущностей.
Андрей Герасименко написал: В результате фильтрация по всему, чему нужно - свойствам заказа, свойством баскетов, принадлежащих этому заказу, пользовательским свойствам баскетов - у нас производится через один простой и понятный getList. Надеюсь, не путано объяснил.