Далеко не факт, апдейтов надвно нет, видимо модуль всё таки заброшен, т.к. баланса пользователя тоже не видно.

Главные вопрос, ЗАЧЕМ?
DLE v14.0 уже из коробки это иметь будет.

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

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

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

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

Стоит поставить его на тестовый сайт и посмотреть функционал, описывать сложно, т.к. функционал был богатый.

Ну тогда всё, хороним обоих... :(

Возрадуемся...
DLE-Billing кажись ожил, возможно и модуль полноценного интернет-магазина увидим....

Нужно нормальное подобие плагинов оплаты, с проработанной структурой + 1-2 основных платёжных агрегаторов, остальное уже допишется по месту.

А не вот эти ваши жесткие привязки к кому то...

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

Прямо таки внезапно...

Ваши познания в программировании меня пугают...

Как и идеи выставлять цену товара по group_id в фронтенде, без проверке на бэке...

1с умеет общаться выгрузкой файла в её формате, кустарно конечно, но и 1с не торт...

Показали бы демо того что уже есть, пользователи бы сами сказали что и как лучше им сделать.

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

Поскольку это формат чата, стоило бы добавить всё таки таймаут на объединение сообщений при определённых условиях (например получатель его ещё не прочитал).

Юзеры любят строчить тексты, особенно есть индивидуумы отправляющие предложение по словам построчно, а это каждая строка = 1 записи в БД.

Можете уже наконец сориентировать по срокам?
Есть ли демо посмотреть? Логичнее было бы обсуждать функционал и его вид с потребителями данного модуля.

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

Вот DLE-Billing и умер окончательно...
Ну что будем делать, Sander?

Когда можно будет уже посмотреть на вторую версию?
Привязка оплаты будет к колонке balance в таблице _users?
Нормальные опции для товаров в виде доп.полей?
Нормальная шаблонизация модуля и админки?
Нормальная локализация в языковых пакетах, а не в перемешку с PHP кодом?

У вас есть информация когда DLE-Billing "оживёт"?

Это интересно чем же она обусловлена?
Кривыми руками "хомячков" которые берут VPS и строят из себя невъе....ых админов, а потом жалуются целсофтке что у них сайт не правильно IP пользователей показывает?

Ясно, ЧСВ столкнулось с критикой выбора структуры...

Завязываться на таблицу _pm была плохой идеей, структура персональных сообщений в DLE как минимум дико устарела и одной ногой торчит из начала 2000-ых, а второй опирается на костыль...

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

https://lazydev.pro/blog/34-multi-select-plugin.html ?

У ВК полно лишних стоек под БД, у DLE сайтов обычно такого нет.

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

Круто, а что бы что то ещё включить, нужно вопросительный знак добавить в конце?
Обычные чекбоксы для трусов и неудачников?

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

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

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

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

Аналог окошек от ExtJS бы ;)

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

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

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

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

А DLE-billing вкурсе этого?
А то походу он помер...

Конструкции подобного вида когда-нибудь появятся?

У конкурентов давно есть.

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

А почему не задействовано создание БД модуля через встроенный механизм?
Ограничения какие то?

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

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

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

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

А jpegoptim вы как вызываете?
Через exec?

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

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

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

Кто мешал в строке вызова функции указывать индивидуальный копирайт под размер?
Ваш модуль можно использовать не только для картинок 100x100, но и более сложные решения им делать.

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

Но там ничего нового не будет, нет того же gif'а и копирайта, хотя наверное стоит уже переписать его под себя.

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

Ну да, кастомизация это явно не ваше всё...

А что же делать, если нужен именно функционал {poster src='{image-1}' width='150'}? Или его так же можно тут использовать?
Вообще не вижу смысла в админке и прочем, если можно было бы просто добавить больше параметров в конфиг модуля и больше параметров в строку вызова, формат V2 вполне покрывал все потребности какие только могли в голову придти, разве что уменьшать картинки в тексте новости нельзя было, да и по сути не нужно оно.

А где вотермарк?
Конфиг наконец то вынесен из зашифрованного кода?
Насколько это можно кастомизировать под себя?
v2 будет как то развиваться/обновляться?

Может актуализировать хак для 12 линейки?