Свеб для битрикса не рекомендую, по крайней мере дешевые тарифы. Перевел оттуда несколько клиентов с интернет-магазинами - все жаловались на тормоза.
10.11.2011 08:28:20
Пришел к выводу, что проблема на уровне хостинга. Сделал 2 абсолютно одинаковых скрипта, которые не имеют отношения к битриксу и содержат всего 2 строки:
обновляем скрипт, он показывает число, при каждом обновлении число +1. Но при переходе между скриптами сессия будто заново стартует и начинает плюсовать опять с нуля. Куки остается на месте, PHPSESSID не меняется. Что это вообще такое, может что-то в .htaccess подправить, может на хостинге PHP глючный? |
|||
|
10.11.2011 07:31:11
Александр Кудин пишет:
|
|||
|
08.11.2011 04:26:26
Имеется интернет-магазин, размещен на хостинге Агава. Есть переменная $_SESSION, в ней на первой странице сайта формируется ключ с нужным значением. Но при переходе на любую страницу внутри сайта, допусти, на site.ru/about/index.php, вся переменная $_SESSION становится пустой, то есть = array(). Куда копать?
Поясню. Заходим на /index.php и $_SESSION содержит все нужные ключи от битрикса и мою переменную. Захожу на /about/index.php , $_SESSION = array(); Возвращаюсь на /index.php , $_SESSION сбрасывается, но содержит все нужные ключи. Под сбрасыванием я понимаю сбрасывание счетчика хитов, для этого битрикс использует ключ BX_SESSION_COUNTERПри этом локальная копия работает нормально - ключи $_SESSION не теряет и не сбрасывает ничего. |
|
|
06.11.2011 01:51:12
Есть компонент с выборкой элементов. Сделал по примеру описанному в статье
Основная проблема - очищается всё. Редактирую я товар с ID = 1, логично, что очищается кеш компонента, где стоит тег element_1. Но в реальности получается, что очищается кеш всех компонентов этого же инфоблока! По сути очищается кеш всех компонентов, где выборка товаров. В БД видно, что в таблице b_cache_tag исчезают все поставленные теги вида element_*. Теперь вопрос. WTF? и как заставить управляемый кеш очищать только те кеши компонентов, где стоит нужный тег, а не все вместе? update: пока проблему удалось решить применение уникального cache_dir для каждого вызова компонента. cache_dir генерируется из cache_id и $arParams. Костыль, конечно, но, видимо, пока единственный вариант. |
|
|
29.10.2011 20:39:55
|
|||
|
29.10.2011 20:26:51
Во-первых, логично отправлять письмо пользователю в случае ИЗМЕНЕНИЯ цены, а не просто ее обновления. Еще логичней отправлять, если цена снизилась, а не просто изменилась. Для этого вам надо иметь значение цены ДО обновления и ПОСЛЕ обновления. А уже потом цену до и после сравнивать, если уменьшилась, то отправляем письмо. То же самое с наличием. Пользователю пофигу, что товара было 30 на складе, а потом стало 40. Логично, что пользователю интересен товар, которого не было в наличии, а потом появился. Поэтому тот же принцип - сначала проверяем остаток ДО, потом ПОСЛЕ и сравниваем, если до было = 0, а после стало >0, тогда отправляем пользователю письмо. Теперь реализация.
Существует несколько вариантов, как передать предыдущие параметры до изменения в функцию после изменения цены/количества. Самый простой мне показался через константы. Как вариант, можно передавать через глобальные переменные.
|
|||||||
|
26.10.2011 18:35:50
В шаблоне, где надо выводить цену используйте
|
|
|
24.10.2011 20:56:03
Чтобы сделать полный пути в URL'е, сначала надо решить несколько проблем.1. Оперативное получение текущего раздела из URL. Стандартный механизм подразумевает адрес вида /catalog/section_id/item_id/. Тут заморачиваться не надо с section_id, даже если там мнемонический код - запросили из БД и всё. А с нормальными путями у вас может быть 2 вот таких URL'а: /catalog/tv/lcd/ и /catalog/monitors/lcd/ - это я так условно пример, чтобы вы видели, что на втором уровне разделов могут встретиться два одинаковых кода для группы товаров "lcd". Стандартная реализация битрикса тут не будет работать - запросит первый попавшийся раздел с кодом "lcd". Поэтому для каждого раздела вам надо знать полный путь родителей раздела. Его можно получить 1 SQL-запросом, также есть отдельная функция в битриксе CIBlockSection::GetNavChain(). Но каждый раз запрашивать ее - тяжело. Нужно кеширование или какая-то другая фича, чтобы по полному URL определять структуру запрашиваемых разделов и конечный раздел в структуре.
2. Требуется поддержка таких URLов на уровне всех используемых компонентов, поэтому вам понадобится некая функция, которая будет генерировать новые URL-ы из полей товара или раздела и опять же проблема №1. Хотя на самом деле реализация комплексного компонента под нормальные URL - это дело 2 страниц кода. Но вот озвученные проблемы должны как-то решаться вне компонента, хоть в модуль отдельный пиши, хоть в init.php. |
|
|
05.06.2011 01:09:31
Просто отредактируйте шаблон компонента оформления заказа, вставьте нужный текст в нужном месте. Если у вас какой-то динамический текст, например, вывод описания платежной системы, выводите его соответственно. Для начала попробуйте в куске шаблона, который отвечает за вывод платежной систем, показать все значения переменных, допустим, через var_dump($arResult); - вы найдете в массиве нужный вам текст описания платежной системы, ну и выводите его, где вам надо.
|
|
|