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

Я же говорил о разбиение мета тегов на отдельные теги и условия (DLE-ешные шаблонные), и благодаря aviable, можно строить для разных разделов совсем разные заголовки.

Так понятнее объяснил?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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 ед к упрощению ведения продаж и отгрузок товара, говорю вам как знакомый со всей этой темой.

В том то и дело что дружить придётся через костыли инвалида-колясочника который ещё и гриппом болеет...
Можно же опять сделать список способов оплаты, и опции для возможности положить свой обработчик в /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: Общую сумму заказов и доставки не плохо бы и разделить, доставка обычно почти не имеет навара.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И об этом опять же не слово в документации.

А как насчёт вложенных спойлеров как на рутрекере например?

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

Можно вычитать количество товара только после оплаты заказа и смены статуса заказа на определённый, например "Оплачен".
И если другой клиент не успел купить вовремя, а товар лежит в корзине уже, то при заказе уведомить его что таких то товаров уже нет в наличии, и желает ли он продолжить заказ без них (и соотвественно перерасчёт цены и списка товаров показать ему), или желает вернутся в корзину.

А можно провести тестирования производительности для первого варианта?
Если магазин более-менее крупный, получим все 300 доп.полей, а вот насколько DLE быстро обработает 300 доп.полей это уже очень хороший вопрос...

Будет ли добавлено количество товара?

Будет ли выгрузка для 1C (и не только 1С, для обновления остатков на складе) по крону (создание файла на сайте)?

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

У DLE нет подходящих доп.полей, по этому или городить в доп.поле:
"Красный|количество|цена||Зелёный|количество|цена"
Или всё таки без правок кода DLE не обойтись...

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