Возникла проблема при поиске минимальной и максимальной цены для товаров в разделе. Как найти их для базовой цены понятно и с этим проблем нет. Но как узнать минимальную и максимальную цены, если на некоторые товары могут быть применены скидки от модуля catalog? При этом скидки могут применяться различным способом: на инфоблок, раздел, отдельные товары.
Максимальный размер куки 4 кб. Массив вы можете хранить только в сериализованном виде. Для хранения пользовательских данных лучше использовать что-то вроде класса CUserOption - хранит данные в БД, но привязывается к ID пользователя.
Действительно, создать парсер для дергания откуда-то описаний, фоток и даже цен - это не проблема. На яндекс.маркете стоит защита капчей от таких умников. Найти достойное описание товаров в интернет-магазинах реально очень трудно, особенно, если товар специфический, не какая-то электроника, например, а одежда. Поисковики действительно не любят дублированный контент, обычно поисковики запросто находят дублирование инфы и могут накинуть на ваш сайт какие-нибудь фильтры, вплоть до АГС, после чего вам ничего не поможет, кроме смены домена.Идеальный вариант - вручную создавать новые описания товаров, нанимать копироайтеров/рерайтеров, которые будут писать текст для товаров. Но я бы на вашем месте увеличил бы эффективность. Описания, фотки, характеристики где-то можно набрать, но серьезно разбавить сайт авторскими уникальными обзорами про многие модели товаров. В глазах поисковиков это добавит веса вашему сайту, у вас появится больше страниц входа, ну и покупатели оценят авторитетные мнения, раскидают сами ссылки на ваш сайт, чем опять же увеличат вес вашего сайта для поисковиков. Деньги в принципе те же, что за покупку ссылок на ваш сайт, но эффективность куда выше и работать каждая хорошая статья будет годами на ваш сайт.
Столкнулся с необычной проблемой на хостинге на большом проекте с большим количеством картинок для элементов инфоблока. Суть проблемы в том, что при загрузке нового файла с картинкой появляется ошибка too many links. Файловая система ext3, в ней ограничение на 32000 вложенных папок. Для решения этой проблемы в битриксе был реализован механизм создания папок из трех первых символов хэша. То есть при загрузке файл сохраняется в папку /upload/iblock/ffd/ffd22777c8976c7827c9380549a844e3/1.jpg , например. Но каким-то образом получилось так, что значительная часть файлов содержится в папках без этого трехбуквенного хэша в папке уровнем выше. То есть некоторые файлы имеют путь /upload/iblock/ffd22777c8976c7827c9380549a844e3/1.jpg . Поэтому и папок 32 тысячи получилось в /upload/iblock/. Как такое могло получиться, может быть кто-то сталкивался с подобным? Как решить проблему сейчас я примерно понимаю, сделаю небольшой скрипт для переименования папок и перезаписи данных в b_file, но лишь бы проблема не проявилась в дальнейшем. update: нормальные файлы имеют пути вида /upload/iblock/ffd/1.jpg в случае если в настройках главного модуля стоит отметка "Сохранять оригинальные имена файлов". Если этой отметки нет, то путь файла будет /upload/iblock/ffd/ffd22777c8976c7827c9380549a844e3.jpg . Такое чувство, что из-за дублирования оригинальных имен файлов начали создаваться длинные названия папок. Неужели лечится только отключением сохранения оригинальных имен?
Столкнулся с аналогичной проблемой при попытке загрузке нормальных JPG-файлов в качестве детальной картинки для элементов инфоблока. Показывает ту же ошибку.Linux 5047.ovz55.hc.ru 2.6.18-238.19.1.el5.028stab092.2 #1 SMP Thu Jul 21 19:23:22 MSD 2011 i686 PHP Version 5.2.6-1+lenny13
я бы делал от топора, лишь бы работало. Сделайте отдельный файл с выборкой данных, который запрашивается через AJAX, данные вставляйте в select и все дела.
Заведите отдельный инфоблок для составных товаров. В них вы можете сделать привязку товара к другому товару или другим товарам или товара к разделам товаров или разделов к разделам - как душе угодно. Но придется достаточно много кода дописать для обработки. К примеру, если вы связываете товар с разделом, допустим, ноутбук с сумками для ноутбуков - у каждой пары своя индивидуальная цена - ее придется считать и писать свою функцию добавления товара в корзину и пересчета в корзине. Зато на такие комплекты товаров можно воздействовать, например, скидками. Ноутбук отдельно стоит 20 т.р., сумка к нему отдельно 2 т.р., а вместе они 21 т.р. за счет скидки и автоматического расчета - красиво ж.
А это стандартный функционал от битрикса или своя доработка? Обычно такой функционал делается на основе ID товара - делается 2 выборки, отсортированные по ID в разных направлениях. Одна выборка больше текущего ID и не равна ему, вторая меньше и не равна ему. Ну и берется из каждой выборки 1 первый элемент - в одной выборке он будет следующий, а в другой предыдущий.
В стандартном компоненте корзины отправка формы происходит на сам компонент корзины методом POST, а только потом происходит редирект на компонент оформления заказа. Так что ваши данные с формы в любом случае теряются до оформления заказа, но передаются в корзину. Вам необходимо эти данные с формы перехватывать и отправлять в компонент оформления заказа либо как параметры в запросе, либо как значение в сессии. Самым безболезненным вариантом мне кажется на уровне шаблона добавить в сессию, а на странице оформления заказа из сессии взять нужные данные о кредите и вывести нужную инфу покупателю.
Если используете комплексный компонент, то в шаблоне комплексного компонента news.php можете добавить условие где-нить после основного компонента в шаблоне и добавление своего заголовка. Например:
Код
if ($_GET['PAGEN_1']>1) {
$APPLICATION->SetTitle("Новости. страница ".intval($_GET['PAGEN_1']));
}