Смотрите в документации описание шаблонного тега show_dynamic
там можно указать ID модулей и сущностей из которых выдергивать.

Ага, втыкай микроразметку - не прогадаешь :)

Где указывался?

В $result гляньте где массив с корзинкой, туда может и масса и габариты идут. Я на память не помню.

Юрий, как у Вас с php? )))

Я делал допил и выводил 1е по счету изображене прикрепленное к модулю

а что значит ?

Вы конечно тут разговоры не о чем водите, но хосинг там полное днище, каждый раз проклинаю его когда админить приходится.

У меня ПЦ гемор с этой херней. Я так не грустил уже очень и очень давно, по причине того что у клиента бешаный трафон с инсты.

Скоро тоже разверну площадку текстовую. От себя заметил следующее:

- не авторизуется
- не сохраняет корзину между переходами страниц.

как думаете, может он куки полностью сбрасывает каждый переход?

Опытные разработчики - подключайтесь к исследованию. Сейчас с этой долбаной инстой народ работает мама не горюй и и трафон с нее льют бешеный.
Эта проблема не обойдет Вас стороной - будьте уверены. Такое дерьмо в Ваш адрес и адрес CMS полетит, мало не покажется.

Под страхом миграции на bitrix еще и не то сделаешь



А я еще колебался ехать или нет )

Выяснил что куки в порядке и что с ними ничего не происходит.

При нормальной работе каждый заход на сайт создается записать в таблицу SESSIONS, НО
когда мы работаем через инстаграм она НЕ создается при рефрешах страниц, а более того очищается.

Описываю сценарий:
1. заходим на сайт - в SESSIONS пусто
2. добавили товар - в SESSIONS появилась запись
3. перешли со страницы на страницу - данная и только данная запись в SESSONS очистилась

https://monosnap.com/file/sJvGeHsbPDiMYf0qSjlb0bGdrPjBsU

ПРОБЛЕМА РЕШЕНА!!!! Оказалось виной всему длина юзерагента инсты куда она пишет помимо всего чуть ли не цвет нижнего белья обладателя смартфона

В БД лимит на поле useragent стандартный 255 симв.

А useragent инсты более 255 симв в длину, итого мы не могли выполнить SELECT where useragent = потому что юзерагент при инсерте в БД обрезался, а SELECT делался уже с полным юзерагентом.


Заплатка "по быстрому":

ALTER TABLE `diafan_sessions`
MODIFY COLUMN `user_agent` varchar(999)


Напьюсь сегодня на радостях

В функции show block в модельке правим запрос таким образом что делаем join таблицы с кол-вам просмотров и ordery по этим просмотрам вот и все :)

да уж, ссылочку выучили )

Голосую за то чтобы его в дистрибутив воткнули.

Может правда настрйоки сервера.

В свойстве $config shop.admin.php вроде как можно сделать

Мне вообще кажется, что вот эта реализация товаров имеющих несколько модификаций была стратегически неверной. В шмитриксе идея торговых предложений, когда каждая модификация по сути отдельный товар со всеми вытекающими гибче что-ли будет.

Я буду пилить в ближайшем будущем.

Я бы AJAX запросом сделал например. Или запрос в функции list бы дополнил WHERE NOT IN (SELECT id FROM {shop_rel} ...)

передайте GET параметр на кнопку "Скрыть похожие товары". В модельке в функции list его отловите и по его наличию допишите запрос.

Потом можно уже будет и ajax накрутить.

Не помню что делает. Можно и функцию фильтра теоретически допилить для тех же самых нужд.

в модельке метод ищи соответствующий

Ну кстати да. Совсем уже программизм мозгом завладел, что простейшие способы стал забывать ))

Вы прям по воробью из пушки :)

Но за скорость входа в программирование на Diafan вам респект ))

Только я бы все это дело вынес через частичную кастомизацию



after private function list_category_query() {

$row["htitle"] = DB:: ...

}

Юзал какой-то php класс для word доков. Как раз там так и было. В вордовском доке вставляешь плейсхолдеры типа %varible%, а класс потом эти плейстходлеры подменяет нужными данными и сохраняешь свой докс нужными данными.

Вот это класс, точняк https://github.com/PHPOffice/PHPWord

Мне прям интересно кто 1 января работал )

Да