Чтобы составить простейший шаблон для заголовка в engine.php необходимы как минимум поверхностные знания в PHP.
Да и то, поверхностные нужны только чтобы человек смог сам внести изменения в написанный код. А вот чтобы самостоятельно составить формулу/условия нужны уже немножко большие знания.

Данный хак же не требует вообще никаких знаний, кроме знания тегов шаблона DLE, по которым есть наглядный мануал.

Лучше всё таки хак для engine.php который позволяет полностью разобрать {headers} на составляющие с богатым набором переменных и условий.

Не капчи, а вотермарка ;)

- Наложение капчи с тонким конфигурированием прямо в строке вызова.
- Наконец то вынести "долбанное" подключение конфига прямо в зашифрованном коде класса, во второй (не зашифрованный) файл модуля.
- Возможность включать анимацию gif'а в параметре вызова на свой страх и риск.
- Оптимизировать нагрузку (писал вам в скайпе о неэффективном методе работы модуля без кеширования), попутно перейти две-три иерархии директорий файлов, и перейти на sha-256 / sha-512, ибо с md5 вполне могут быть коллизии.
- (!!!) Добавить префикс в параметры вызова (prefix="short_story_poster_150x150"), и использовать первую директорию с префиксом из параметров вызова, если не заданно, то используем дефолт из конфига. Данная штука позволяет более эффективно чистить старые изображения, при этом растягивать это на какое то время, а не всё скопом, что бы сервер не взвыл от нагрузки, а посетители не ждали генерации страницы по 5-10 секунд. Заодно видно какие тубмы сколько места занимают. И если меняешь формат вывода например постера, его размеры, качество, можно задать это в имени префикса, и отделить данный тим тумбов от остальных.
И убрать уже из скрипта при каждом вызове изображения изменение времени последнего редактирования файла изображения, бесполезная нагрузка для бесполезного скрипта очистки "типо бесполезных изображений".

Спасибо

Открыть /engine/modules/pinbot/pinpic.php
После первой строки

<?PHP

Вставить:

error_reporting(E_ALL ^ E_NOTICE);
@ini_set('error_reporting', E_ALL ^ E_NOTICE);

Иногда в php-error.log наблюдаю вот такую картину PHP Notice: Undefined index: sec_code_array in /var/shared/web/news/public/engine/modules/pinbot/pinpic.php on line 57

Если у вас ionCube Loader версии 6.x то просто переименуйте файл лицензии с 5.6 на 7.1

Я думал об этом, но не придумал, что можно в него добавить/улучшить и отказался от этой затеи.

Будет ли обновление модуля в ближайшее время?

А можно сделать поддержку php 7 (7.1.10)

Да.

на 12 версию подходит?

Сломать мозг работая с овер 10-уровневыми условиями, или сломать сервер?

Хм, красота в буковках или хорошая производительность? Ибо рекурсивные шаблоны в данном случае будут не из легких.

Но так же и в самом PHP, если условие первое не подходит то вслед за ним идет другое, если же оно не верно (false) то не заходит внутрь if.

[if rating>10 && comm_num>0 || rating>10 && views>100] ... [/if]

Так, разве нет?


Это довольно старый код, я его не марафетил даже.

Всего не сделаешь, чем-то нужно пожертвовать, но в данном случае жертва минимальна, приоритет как бы сохраняется и как бы нет.

Возможны ли нормальные вложенные условия (без номера условия)?
Или возможно это сделать?

Лучше не надо, я сразу не заметил этот бред, только хотел написать и вы опередили...
[ifN - это дичайший пи...
Нужна нормальная php логика со всеми её плюсами, а не сидеть и считать количество и отношение определённых if, else и if и искать где ошибся с номером.
PS: В сложных условиях это будет садомазо.

Пожалуй тоже вариант.
Но он исключает возможность приоритета.
К примеру:

[if rating>4 && comm_num>10 || news_read>500] ... [/if]

Подобная запись будет обработана так:
Получается что у новости может быть плохой рейтинг или не будет комментов, но много просмотров - текст будет показан.
Или же наоборот, просмотров мало, но хороший рейтинг и много комментов.

А если нужна иная логика:
Чтобы текст был показан только если хороший рейтинг и у новости есть комментарии или много просмотров.

PS. Зачем дублировать trim() в цикле если его можно вынести в функцию.
Почему не используешь foreach ?

Для этого я написал функцию которая разбивает по || потом смотрит есть ли там && проходит по массиву && и если первое условие срабатывает то отдает и так далее.

[if rating>4 && comm_num>10 || news_read>100 && votes>5] ... [/if]

Какой приоритет условий, где скобки ставить?
Казнить нельзя помиловать.

[if rating>4 && (comm_num>10 || news_read>100) && votes>5] ... [/if]

Если так, то все логично:
Если рейтинг хороший и (много комментов или просмотров) и много оценок то ...
Будет показан текст, если у новости хорошая активность и хороший рейтинг со многими оценками

А так уже имеем другую логику...

[if (rating>4 && comm_num>10) || (news_read>100 && votes>5)] ... [/if]

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

p.s у письмо на активацию аккаунта попадает в спам. Почта gmail.

Хм, а почему нельзя использовать || и && если значения числовые?


Не верно, у меня такой же способ реализации через preg_match, switch и if - работает быстро, никаких просадок в скорости загрузки не заметно и быть по идеи не может.

Сам функционал я его еще год назад сделал, лень было оформить и опубликовать :)

Ну что же могу сказать - работа отличная. Придется свой не много апгрейднуть тогда :) Только я все же думал сделать вложенные условии

[if ...]
    [if ...]
        ....
    [else]
        ...
    [/if]
[/if]

Но реализация с числовыми if мне понравилась. Только не понятно почему так долго не было обновления? Ведь мог давно его обновить.

Это будет несколько проблематичо.
Лучше используйте стандартные .dialog() окна. Их внешний вид, кстати, можно относительно легко настроить аналогичным образом как и в чате (собственно у меня на сайте такой же стиль).

Здравствуйте, а если как сделать, чтобы можно было посмотреть, например, правила чата в popup окне с тем же дизайном, что и окна в модуле?

Достаточно качественно фильтровать входящие значения... ;)
Я тестировал на тысячах и десятках тысяч условий, что бы получить более полную картину на высоко нагруженных проектах.

Если нет встроенной функции вывода переменной, то придётся или писать код на str_replace, или подключать встроенный DLE-шный шаблонизатор. В принципе не так критично.

В принцепе модуль нормальный, но от Gamer'а умеет ещё и это:

Что будет ещё у него в версии 5.1 не известно, но что то явно будет... ;)

В скрипт бы добавить ещё удаление новости и запись в лог DLE, доски объявлений сожрут вас и ваш модуль сразу, беглым набегом)
А так же смена категории на categories_add=1,2,3,4,5 и просто добавление категории с проверкой присутствует ли новость уже в ней (как был баг в админке DLE, когда два раза одну категорию в ячейку прописывало).
Попутно можно так же сделать и исключение из категории categories_delete=1,2,3,4,5.

А так вполне годный модуль.
Ну и скрипт операций с новостями у вас как бонус такой не хилый)

В полной новости каждый раз выполняться обработка более 100 функций preg_* и более 200 str_replace и более 300 if-else. И все они выполняются практически мгновенно. На фоне этого нагрузка от модуля ничтожная.
Нативность - это конечно хорошо, но в таком случае необходимо исключить возможность редактирования шаблонов через web-интерфейс.


DLE-шный шаблонизатор не обязательно подключать. Модуль обработает любой шаблон согласно заданным параметрам.
Нижеуказанный код подключается перед $tpl->compile('content');

		TplIf::rowSet($row);
		$tpl->copy_template = preg_replace_callback( 
			"#...#is", 
			"myFunction", 
			$tpl->copy_template
		);

Вы можете перед $tpl->compile('content'); вставить var_dump($tpl->copy_template); и увидите с какими данными работает модуль. Ему без разницы как и что выводится в шаблоне. Он работает по своим ключам.

Это печально, нагрузка и скорость при обилии условий будет не очень маленькой, тестировал шаблонизатор DLE и свой нативный на PHP подобной логике, разница в десятки раз. Ваш работает по подобию DLE-шного, только условия посложнее.

Это мне известно, просто инструкции по установке в свободном доступе нет, по этому и не совсем понятна точная реализация и момент парсинга условия.

т.е. сейчас по идее можно самому подключить код модуля в нужных шаблонах и передать туда массив со значениями устанавливаемых переменных? По идее тоже сойдёт, у кого руки прямые, те сделают себе и там условия.

Просто хотел понять, можно ли его в своих модулях использовать как шаблонизатор, или всё таки придётся и DLE-шный подключать.

Ни то ни другое. preg_match, preg_replace_callback, switch, if.

В короткой новости (и custom) кешируется полностью весь контент, готовый сформированный шаблон. Все теги соответственно тоже. В полной новости кешируется только запрос в БД, обработчик выполняется каждый раз.

Я подумаю над этим.

Модуль не имеет никакого отношения к выводу данных.

Ваш метод основан на str_replace и т.д. или компилируемый код (преобразование в php код)?

Имел ввиду попадает ли работа модуля в кеш кратких новостей например, или каждый раз будет идти обработка шаблона?


В принципе как у Gamer'а, но у него вроде как в любых шаблонах работает.
Может реализуете во всех шаблонах? Тогда цены ему не будет.

А как вывести саму переменную шаблоне? Только стандартным методом через $tpl->set()?

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

Работа с кешем в данном случае будет занимать больше времени, что сама работа модуля.

В инклюдных шаблонах тоже работает?

Да.

Можно, но не во всех. В некоторых шаблонах это будет проблематично, к примеру addcomments.tpl, addnews.tpl, info.tpl и т.п.


Модуль принимает массив данных, в случае с новостями и комментариями это переменная $row

TplIf::setRow($row);

С тем же успехом можно скормить ассоциативный массив:

TplIf::setRow([
    'field_string' => 'значение',
    'field_integer' => 54,
    'field_date' => 1509002550
]);

В шаблоне будет:

[if field_integer>20] ... [/if]
[if date.field_date='2017-10-26'] ... [/if]

Можно сравнение с аналогичным модулем от Gamer'а?
Как тут дела с кешированием?
В инклюдных шаблонах тоже работает?
Можно ли заставить работать во всех шаблонах? Включая доп.модули?

Привязка переменных идёт по колонкам таблицы данных, или по $tpl->set()? Или переменные вообще предустановленные, и для добавления своих кастомных колонок нужно править код модуля?

Последний пункт установки повторить для engine/modules/show.full.php

А можно ли вывести в fullstory? чтоб там тоже отображалось

Был маленький недочет с этим itemprop. Для RDFa и микроразметки он по разному должен быть прописан.
На гугловском валидаторе проверил, оба варианта работают исправно, ошибок нет.

После обновления до DLE 12 (либо это вообще не связано с обновлением, однако до этого проблема не возникала) столкнулся со следующей ошибкой валидатора:

The itemprop attribute was specified, but the element is not a property of any item.
/span></a><meta itemprop="position" content="1" /></li><

The itemprop attribute was specified, but the element is not a property of any item.
/span></a><meta itemprop="position" content="2" /></li><

давно не был)
хорошо было бы ещё реализовать или добавить тем, у кого есть корзина, а лучше в саму корзину это тоже добавить.
функционал фильтра.
ну например в категориях, чтобы фильтры выводились, на основе доп поля получается.
таким образом в определённых разделах, где это нужно, выводим свой фильтр с определёнными доп полями, и по ним фильтруем товар допустим... ну фильтров куча, это я понимаю, но если он будет в коробке с корзиной, это будет лучше!
также выше вижу https://sandev.pro/uploads/comments/2017-08/thumbs/150360749910.96601500.png это отлично, так получается можно будет к одному товару, не дублируя его если он например там в разном количестве продаётся или цвета, весе и так далее. то получается теперь достаточно будет создать 1 новость и к ней привязать уже там единицы измерения или параметры. грубо говоря становится более гибкая настройка. Самое главное, чтобы цены в экспорте передавались адекватно! вот тогда будет айс...

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

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

вот такие идеи по развитию. спасибо

http://d13.sandev.pro/mobile_phones/26-mobilnyy-telefon-nokia-105.html#option_id=28
Cyan / 1 200 Р (В наличии: -2)

Количество "-2" это нормально?

Это такая отговорка?
Что я такого не реализуемого написал?
Что из этого потребует полной переделки DLE?

Пусть увеличится стоимость в 2-3 раза, если то что я описал будет полностью внедрено, зато количество затрачиваемого времени менеджеров будет прилично сокращено.
Это всё равно дешевле чем делать на том же битриксе или фреймворке, тем более там, где они по сути не требуются и с головой хватит того что уже есть, и того базового минимума что описан мной.

PS: Смысл делать корзину, которая останется ущербной и безфункциональной в будущем? Есть уже полно кривых и древних вариантов корзины заказа, ещё +1 что ли?
Думаю многие покупали модуль в расчёте на то что он будет улучшаться, и не рюшечками и свисто...ками, а способами оплаты, доставки, калькуляторами и прочим что упрощает продажи и поддержку магазина.
И вместо той же удобной интеграции нового способа оплаты путём создания записи в админке + 2-3 php файла для приёма платежей, вы говорите:

Зачем же тогда простой корзине онлайн оплата?
Зачем печать документов?

PS2: Нужно бы ещё карточки заказчиков сделать, например привязкой доп.полей пользователей к доп.полям корзины (заполнил один раз и потом оно подставляется сразу, причём в доп.полях пользователя должны заменятся данные из последнего заказа), что бы на основе этого можно было сделать конструктор документов как например в Битрикс24 (обычные шаблоны и переменные с данными покупателя и продавца), и уже сразу из админки печатать УПД, договор и т.д.
Это даст +1000 ед к упрощению ведения продаж и отгрузок товара, говорю вам как знакомый со всей этой темой.

Вам нужен интернет магазин, а не модуль корзины заказов.
Если реализовывать в полной мере весь перечисленный вами фукнционал, то и стоимость модуля увеличиться раза в 2-3 раза. Однако я этого делать не стану.
Настоятельно рекомендую вам использовать специализированные движки или фреймворки такие как bitrix, magento или OpenCart.
Данный модуль вам не подойдет.

В том то и дело что дружить придётся через костыли инвалида-колясочника который ещё и гриппом болеет...
Можно же опять сделать список способов оплаты, и опции для возможности положить свой обработчик в /engine/modules/cart/pay/{pay_id}/pay.php и в итоге там код которому доступны $user_id, $order_id и другие необходимые переменные. Это позволит вообще делать что угодно по оплате, хоть борзыми щенками принимать её, и главное без каких либо проблем с обновлениями модуля.

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

Там где идут операции с деньгами, нужно полное логирование, причём не полное, а ПОЛНЕЙШЕЕ ПОДРОБНЕЙШЕЕ ЛОГОГИРОВАНИЕ, каждого чиха (опять же можно дать возможность администратору чекбоксами отмечать что логировать), странно что вы этого не знаете...


Это я давно знаю, но раз уж мы тут все мазохисты, и собрались делать что то подобное на DLE, можно же хотя бы функционал корзины по максимуму функциональным сделать? Что бы он по максимуму был похож на полноценный магазин, а что вообще не реализуемо без полной переделки DLE тогда уж не трогать.
Понимаю что если нужен полноценный магазин, адекватные люди обычно на DLE не смотрят, но иногда магазин это доп.раздел на сайте, или людям нужен минимум от интернет-магазина, без этих монстрообразных функций как у битрикса например, а иногда у них и вовсе мелкий бизнес, и всякие там битриксы и прочее это слишком жирно для них в финансовом плане... ;)

Для остатков каждого параметра отдельное доп.поле?

Опять же для каждого параметра отдельное доп.поле типа изображения? А если различных опций товаров в магазине сотни? Это порядка нескольких килотонн доп.полей?

Это необходимо реализовать, и ещё бы настройку, что бы выбирать самостоятельно при смене на какие статусы вычитать количество товара.

Имелись ввиду условия [product_quantity=1,2,3,4,5]Товара очень мало[/product_quantity], с возможностью вложения в друг друга. Сторонний хак это хорошо, но не всегда.

Т.е. хотите сказать что имеем все те же дубликаты товаров, но только теперь они сняты с показа на сайте (approve) и теперь мучаемся с ними только в админке?

Я вкурсе этого решения, но что если нужно полностью скрывать товар, на странице 10 товаров, а из них с нулевым остатком 9-10? Как то не очень хорошо получается.
Или опять же нужно сложить в корзину-архив данный товар, а если он появится, то перенести его оттуда в нужную категорию (уже вручную видимо).

А не проще сделать это, со списками и т.д., а обработчик уже пусть пишут клиенты под своего агрегатора? Потому как просто при обновлении чуть подправить код в своём файле лежащем в папке модуля проще, чем перелопачивать код модуля и сравнивать изменения.

Тоже необходимо, т.к. менеджер может забыть нажать на кнопку уведомления, и клиент так и не узнает что его заказ пошёл в работу, пока не зайдёт на сайт под своим аккаунтом.

Если бы ещё API служб доставки использовать, что бы на сайте сразу отображалась информация о доставке, то было бы вообще шикарно.

Я имел ввиду на сайте, что бы человек ввёл почтовый индекс, и ему сразу стоимость доставки посчитать, а менеджер уже потом проверяет, что бы особо хи...опые товарищи её не занизили.
Ну или в админке тоже сделать кнопку расчёта. Админка вся на шаблонах? Как сам модуль? Или другой шаблонизатор?

Не совсем и индивидуальный, если у сайта есть постоянная аудитория, то это необходимый функционал, а если там все покупатели купили и забыли об этом магазине, то да, это "Слишком индивидуальный функционал.".
А все ли владельцы хотят что бы у них купили и забыли о них? Личный менеджер это всегда плюс к карме магазина.


Опять же вкурсе что можно и так, но имея богатую историю заказов и скажем 100 заказов на странице, то какую нагрузку мы получим? А ещё и стоимость доставки возможно надо посчитать, это ещё +1 запрос к каждому показываемому заказу. Не проще ли хранить в двух ячейках _users и сделать это по дефолту?
Это разгружает менеджеров от ненужно работы, а модуль должен по максимуму автоматизировать всё что можно.
PS: Общую сумму заказов и доставки не плохо бы и разделить, доставка обычно почти не имеет навара.

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

Остатки хранятся в стандартном доп.поле.


Используется функционал DLE. Модуль только берет значение адреса из указанного в настройках поля.


Вычитание происходит когда статус заказа меняется с "новый" на любой другой кроме "отменен". Если заказ был принят в работу, а потом по каким-либо причинам будет отменен, то остаток необходимо будет вручную обновить в новости. Хотя подумаю над этим, чтобы в новости возобновлялся остаток при смене статуса на "отменен".


Для этого можно использовать хак Условия IF. В ближайшее время постараюсь выложить обновленную версию с более расширенным функционалом if ... elseif ... else ...


Да. Физически параметры - это отдельные новости, которые программно связаны с составным товаром и не отображаются в самом DLE.
http://d13.sandev.pro/mobile_phones/26-mobilnyy-telefon-nokia-105.html#option_id=28
Или же по прямой ссылке (прямой доступ к параметру закрыт, выполняется редирект):
http://d13.sandev.pro/mobile_phones/28-mobilnyy-telefon-nokia-105.html


Нет. Пока не вижу необходимости в подобном функционале. При желании можно шаблонно скрывать конструкцию типа такой:

[if xfvalue_allow_cart && xfvalue_cart_count] тут кнопка [elseif !xfvalue_cart_count] товар закончился [else] снят с продажи [/if]

В общем релизе - нет. Кто захочет подключит и пропишет самостоятельно.


Скорее всего сделаю.


Скорее всего сделаю.


Да, это уже давно можно


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


Слишком индивидуальный функционал. Его можно реализовать, но только в частном порядке.

SELECT sum(`cost`) as sum FROM dle_cart WHERE user_id = 123 AND status = 3;

Стоимость доставки нужно будет подсчитывать отдельным запросом.


Пока не планируется.


На данный момент есть разграничение на 2 группы. Админ и менеджеры.
Менеджеры могут только управлять заказами.


WM и так есть, в первую очередь.
webmoney, megakassa, interkassa, robokassa - у всех у них одинаковый алгоиртм работы и подключить еще одну кассу не составит труда. А вот к примеру по paypal или "Сбербанк онлайн" я уже не подскажу.
С DLE-Billing в принципе можно будет подружить. Достаточно будет написать обработчик который будет вычитать баланс и менять статус заказа.
Но это будет отдельный скрипт, на отдельной странице или AJAX, без разницы.


Именно такого функционала нету. Но ведь пользователь не сможет оплатить товар если не получит ссылку на оплату.


На сайте действий как таковых нет. Только добавление заказа.
В админке идет лишь частичное логирование. Т.е. идет запись что такой-то даты тот-то отредактировал информацию о заказе или изменил товары/количество, сменил статус и т.п.


Будет.

Отдельно хочу сделать крайне важное замечание.
Данный модуль позволяет лишь организовать заказ товаров на базе DLE. Это не полноценный интернет магазин со всеми его особенностями, акциями, скидками распродажами, фильтрами, рассылками и т.д. и т.п.

Наверное стоит так же заголовок новости поправить, и написать жирным шрифтом что пока без возможности обновления с прошлых версий.

Можно "пару" вопросов сразу тут, что бы остальные не переспрашивали, кому будет тоже интересно.

Как хранятся остатки и параметры товара? В доп.полях, в отдельном поле в таблице _post в виде массива, в отдельной таблице корзины или ещё как то?
Нужно для понимания того как это потом интегрировать с выгрузкой со склада из 1С / SLS и т.д. и т.п.

Как загружаются и где хранятся изображения доп.товаров? Есть ли параметры уменьшения, лимиты и т.д. Как потом они удаляются при удалении новости?

Можно ли настраивать вычитание товара из остатков при определённом статусе заказа, и возвращении товара в остаток, при отмене заказа?
Например человек оформил заказ, но менеджер его ещё не подтвердил, или оплата ещё не пришла, и что бы особо умные товарищи не выгребли все остатки зланомерно.

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

При выборе параметра товара, меняется ли везде изображение данного товара? Корзина, каталог, история заказов и т.д.

Можно ли снимать показ товара (лучше в настройках модуля), при его нулевом остатке по всем параметрам? Можно ли сделать перенос такого товара в категорию-архив?

Будет ли интеграция с SMS агрегаторами для уведомления покупателей и рассылок?

Будет ли опция в настройках модуля (а лучше групп, хранить в _usergroups, но редактировать в модуле магазина для каждой группы отдельно), что бы при смене статуса заказа, автоматически отправлялось уведомление на e-mail / SMS покупателя о смене статуса?

Будет ли возможность формирования списка служб доставки, и уже например на основе выбранной службы для данного заказа, формировать в шаблоне ссылку с трек-номером, что бы при переходе по ней, открывалось отслеживание конкретной посылки на сайте службы доставки (там где это возможно)?

Можно ли стоимость доставки корректировать менеджером, после обработки им заказа?
Можно ли подключить калькулятор и формировать уже примерную стоимость по индексу например?

Можно ли будет сделать возможность привязки определённого клиентского аккаунта к определённому менеджеру? Нужно для постоянных клиентов, что бы ими занимался определённый менеджер, а не кому попало кидало в работу. Если менеджер не берёт заказ в работу в течении установленного времени, то он бы передавался в свободный доступ.

Можно ли будет сделать вывод (лучше всего из ячейке в _users) общей суммы всех завершённых (т.е. фактически законченных) заказов данного пользователя? Нужно например для ручной или автоматической установке скидок, не вручную же сидеть и с калькулятором плюсовать все заказы каждый раз?

Будет ли в будущем переход в другие группы в зависимости от заказов в модуле, скидки, купоны и т.д.?

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

Будет ли другие способы онлайн оплаты с меньшими комиссиями, например тот же WM или ЯД? Насколько реально прикрутить свой обработчик к способам оплаты? Есть ли для этого удобные функции или API?
Например на сайте есть модуль DLE Billing, и нужно дать возможность оплачивать заказы с баланса аккаунта в автоматическом режиме, насколько это реально сейчас сделать, прикрутив к способу оплаты свой обработчик?

Можно ли настраивать возможность онлайн оплаты, лишь при определённых статусах заказа?
Например, сначала заказ подтверждает менеджер, и только потом человек сможет его оплатить, это актуально для некоторых типов товаров и для складов, что бы не получилось так что человек оплатит товар которого нет на скаладе.

И самое главное, будет ли ПОЛНОЕ ЛОГИРОВАНИЕ ВСЕХ (и на сайте, и в админке) действий в модуле, что бы можно было жестоко карать провинившихся злодеев?

Будет ли полный обзор столь масштабных нововведений? Всё таки это не две новые кнопки и рюшечки.

Это наиболее частные вариации использования вашего модуля, думаю не только мне будет интересно это знать перед покупкой.

PS: Брать скорее всего буду, т.к. в целом радует то что модуль не заброшен и активно развивается, получая всё больше и больше функционала.

Тогда нет вопросов, это отлично что по user_id, с учётом того что 99,9% разработчиков делают всё по логину, а целсофт забивает болт М48 на сторонние разработки, видим полный писец в БД и вообще на сайте, при использовании сторонних модулей, а потом ещё и кучу проблем.
Рад что вы пошли по другому пути.

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

Супер новость, покупаю, устанавливаю

Но ведь для этого можно использовать JS.