Сжимается только HTML, генерируемый PHP. Можно использовать модуль PHP gzip. Основной параметр - уровень сжатия. Этот же модуль "имитируется" в модуле компрессии. Так что особой разницы что использовать нет. Главное, чтобы не то и то сразу От степени сжатия тоже многое не зависит, при уровне в 4 оптимальное время и степень сжатия. Больше степень - сжатие не на много больше, а время сжатия увеличивается в разы. Тот же уровень сжатия используется в модуле компрессии.
Не, это не в компоненте вообще, копать надо в /bitrix/modules/sale/ru/delivery/delivery_cpcr.php - это скрипт для расчета стоимости доставки СПСР. Для остальных служб свои скрипты. Уже не помню где там именно была строчка с расчетом веса, попробуйте найти закомментированные строки с переменной $arOrder["WEIGHT"]
Проблема не в компоненте, а в скрипте расчета. Там вес товара округляется или вообще не учитывается - сделано для кэширования. В самом скрипте строчка кода закомментирована, где учитывается вес. Я недавно ковырялся с автоматической доставкой для СПСР - раскомментировал строку, всё заработало
Можно решить путем парсинга кода страниц данных сервисов. Также этот метод называют граббингом (от слова grab). К сожалению, данные этих сервисов не однозначны, один и тот же товар всегда имеет цену в виде разброса от и до. И очень часто минимальная цена... как бы это сказать... уж очень минимальна. Скорее всего будет ниже вашей. А если пользователь пойдет смотреть эти данные, он обязательно найдет где подешевле. Вам оно надо?
Я бы сделал в инетрнет-магазине сравнение цен с несколькими ведущими магазинами. Допустим, продаю я телевизор за 50 т.р., где-нить в 003.ru, eldorado.ru он всяко будет дороже на 5-10%, я покажу на странице товара, что там он дороже, чем у меня и это будут реальные данные - пусть покупатель сравнивает.
Лучше пригласить программиста 1С, который сделает обработчик на каждый Excel-прайс, загонит их программулька в базу 1С:Предприятие и периодически будет синхронизировать. А уже из 1С выгружает пусть в Битрикс.
Несовместимость выражается в глюках при визуальном редактировании. Например, может не открываться визуальный редактор на странице в публичной части в режиме редактирования сайта. Где-то тут писали уже на эту тему.
Вопрос поставлен немного некорректно - элемент инфоблока не может быть "файл". Видимо, у вас в инфоблоке есть свойство типа "файл". Можно дернуть всю запись инфоблока функцией GetIBlockElement($id) - будет сразу массив с записью инфоблока и его свойствам. Если действовать более точно:
где $code - ID свойства, в котором у вас хранится файл. $prop['VALUE'] будет номером файла. Его уже можно показать с помощью CFile::GetPath() или CFile::ShowImage().
Нужен разработчик для доработки сайта на 1С-Битрикс. Сайт небольшой, но очень переработанный. Используются нестандартные компоненты. В основном надо просто переделывать вид форм, таблиц. Писать vitaminych@gmail.com
Наполнение контентом сайтов на Битрикс. Писать на iris_198181@mail.ru - Ирина. Из опыта: http://avkenergo.ru/ - заполнение каталога продукции (текст, таблицы, схемы), 3000+ позиций за 1.5 месяца.
Да, разброс цен на дизайн огромный, цены практически от пары баксов до нескольких тысяч, а то и десятков тысяч долларов. Средний диапазон, где качество уже есть, а амбиции еще в пределах 4-значных сумм - $800-1500.
Сергей Чуев пишет: Так что итог: 1. Не надо плакаться работодателям. 2. Оценивайте достойно труд наемного работника. 3. Создавайте условия для роста.
Проблема не в плохих работодателях и уходящих сотрудниках, а именно в отсутствии достойных работников, которые бы хотели работать. Навалом php-программеров, которые готовы за $500 пахать, но толку от них, если проекты на Битриксе? Им надо как минимум месяц, что "въехать в тему".
Обучение все-таки не миллионы стоит, чтобы человек не смог их отдать. Пару десятков тысяч рублей - это пол зарплаты нормального программиста, то есть те самые 2 недели отработки после заявления об увольнении. Или может за него этот "выкуп" даст новый работодатель. А начисление процентов на эту сумму довольно сомнительный ход, трудовой кодекс у нас по-прежнему на стороне работника.
Проблема поиска сотрудников как на единичные проекты, так и на постоянку сегодня мне уже кажется огромной и нерешаемой. Суть проблемы в том, что нет нормальных программеров на Битрикс. Один не выдерживает никаких стандартов и код у него отвратный. Другой срывает несколько раз сроки и пропадает. Третий не достаточно квалифицирован для выполнения средних и больших проектов. В общем, не везет с кадрами, а проекты делать кому-то надо. По-моему, мы сталкиваемся с проблемой роста - технология очень востребована, а предложений по качественной реализации очень мало. Просто-напросто некому делать проекты.
Обновление компонентов - конечно тема огромная. Централизованное обновление на данный момент я себе плохо представляю. То, что некоторые компоненты пойдут по рукам - это однозначно, но я не думаю, что уровень распространения будет такой, что компонент прямо перестанут покупать. Не стоит из-за этого париться. Компоненты в конце концов надо периодически обновлять в связи с развитием как самого компонента, так и развитием модулей Битрикса - новые возможности, новый API, оптимизация кода и функционала.
И я думаю, что компоненты в первую очередь нужны самим партнерам, а не клиентами. Партнеры могут покупать компоненты друг у друга для экономии времени разработки. Допустим, надо сделать на каком-то сайте хорошую доску объявлений - это займет 2 недели работы собственного программиста и примерно 30 т.р. денег на него. А можно купить компонент за 15-20 т.р. и сэкономить 2 недели - по-моему, очень хороший бюджетный вариант. Я бы покупал с удовольствием. Да и тем, кто пишет эти компоненты - 5 продаж окупят все затраты на создание компонента. А 5 продаж хорошего компонента, как доска объявлений, вполне реально.