Александр Тарасенко

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

Речь о функционале - на примере Подарки - допустим есть плагин Подарки 1.0 - он добавляет подарок в корзину, появился новый плагин Подарки 1.1 - он тоже добавляет подарок в корзине - итого в корзине будет два подарка, как итог гневное обращение в ТП что плагин работает неправильно, ответ что нужно удалить один плагин - как результат негатив со стороны покупателя

Также настройки - покупатель долго и нужно настраивал плагин, вышел плагин 1.2 - и опять все по новой нужно настраивать

Также и с темами дизайна - если раньше для поддержки плагина нужно было добавить код (как пример) {shopAddgiftsPlugin::inProduct($product)} то теперь понадобится {shopAddgifts10Plugin::inProduct($product)}{shopAddgifts12Plugin::inProduct($product)}{shopAddgifts20Plugin::inProduct($product)} и т.д. 

То есть инструкции для некоторых плагинов и так сложные - усложнятся в N раз - и нужно будет постоянно следить а не вышла ли новая версия плагина 

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

Смотрю забастовка плавно и тихо закончилась, пошумели и вернулось все на круги своя (( очень жаль

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

тут очень сильно усложняется интеграция тем и плагинов

да и сами версии 1 2 3 будут конфликтовать между собой (

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

Владимир, не стоит изобретать велосипед. У вас есть пример успешного конкурента - Битрикс/Битрикс24 

До этого года в Битрикс24 был обычный маркетплей с ценами - сейчас они полностью перешли на подписку - все решения бесплатны если есть подписка

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

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

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

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

up без данных "официальных" методов происходят постоянные конфликты со сторонними плагинами (так как каждый пишет сам в поля формы как хочет, в результате чего происходят конфликты вплоть до зацикливания) так и постоянные проблемы после выпуска обновления Shop-script

Можно узнать - будут ли подвижки в данном направлении?

1) Ссылки в меню (плагин Подарки), доп. возможности - изменяем стандартную таблицу/список вывода товаров меняя ссылки или целые поля (например быстрый редактор рейтинга)

2) Подарки, Редактировать в один клик, Рейтинг в твоих руках, Правильные изображения

потому что это бакэнд) так как

1) не описано в документации что это фронт 

2) переменные в стиле php

3) заглянули в имеющиеся события фронта, и там нет этих "хуков" только это: https://yadi.sk/i/dTHg_Ncln38c...

1 хуки - эти события для backend, но нам нужны для frontend-а, когда пользователь находится на странице

2 все эти события - изучены давным давно - они все информирующие, тоесть информацию получить от webasyst можно, а вот повлиять - никак, даже найденное в коде region_change - не описано в документации

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

Вот можно узнать какие и где?)

кроме вызова события region_change - ничего не нашли

Up - из-за отсутствия данного метода - приходится городить костыли, которые начинают конфликтовать с другими плагинами

4 года прошло) https://developers.webasyst.ru... а воз и ныне там

Для себя сделали выводы - что webasyst ничего менять не будет/не желает/не может

Они лучше придумают свой кастомный UI 2.0 который никто не знает, чем возьмут что-то популярное и известное, например bootstrap, не нравится bootstrap - пожалуйста, есть tailwind (стильно, модно, молодежно)), но нет мы потратим кучу сил и усилий на свое, родное ) чем внедрим какие-то стандарты и регламентируем взаимодействие частей системы - ведь стандарты, это так скучно, а вот свой UI 2.0 - это так круто

в хуке frontend_order_cart_vars

Уже как минимум два человека обратили на это внимание  https://developers.webasyst.ru/forum/22154/podderzhka-theme_settings-v-blokakh-i-v-kontente-stranitsy/

Но воз и ныне там уж почти три года

Up

С июля тянется данная проблема ( чуть по другому сформирована - но по сути проблема та-же

https://support.webasyst.ru/forum/32831/poterya-vvedennykh-dannykh-pri-izmenenii-indeksa/

Хук вызывается после сохранения товара,  product_presave - перед

$params['instance'] - это клас shopProduct сохраняемого товара

Еще раз посмотрите в сторону product_presave - в нем вы можете менять данные до сохранения товара

На самом деле все логично, метод $product->save() вызывает хук product_save, соотвественно делая такое сохранение в хуке вы получаете бесконечную рекурсию, тут или воспользуйтесь моделью shopProductModel или используйте другой хук возможно вам более подойдет хук product_presave 

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

Не получится, так как в checkout_before_confirm - не передаются данные о стоимости заказа, они появляется только в хуке checkout_after_confirm

Ещё меня смущает, что скидка не привязана к item'ам.

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

Ну и это не наша прихоть, это задача от одного из работающих магазинов довольно крупного причем

Функционал "финальная скидка", то есть скидка должна добавляться уже после всего расчета. И самое интересное, что если вызвать waOrder.form.reload() (синтаксис по пдословно не помню) то покажутся правильные числа, с чем это связано загадка, сейчас так и реализовали из минусов - двойные запросы при изменении данных

Но на создаваемый заказ-то это никак не повлияет.

Для этого можно использовать хук order_action.create

Теоритически это можно сделать с помощью checkout_* хуков

там есть before process after и финальный checkout_result

НО! как обычно ноль документации, ноль примеров, а недоработки уже всплывают:

https://developers.webasyst.ru/forum/33953/nevozmozhno-polnostyu-ispolzovat-khuki-checkout_/

По моему мы говорим о разных вещах, для описанных вами действий достаточно использовать переменную $action, я говорю о массиве $breadcrumbs генерируемом webasyst -  в этом массиве сейчас только name и url

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

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

Обнаружили первую возможную причину:

Данные longAction хранятся в wa-cache - соответсвенно если кто то сбросит кеш или установит/обновит какой плагин (а при этом сбросится кеш) процесс прервется, но это не объясняет "зависание" процесса 

Почему не будет? И зачем $wa->globals()?

Это уже есть, первые несколько штук нормально обрабатываются

плюсуйте и тут )

https://support.webasyst.ru/forum/32239/razreshit-zagruzku-svg-v-nastroykakh-tem-dizayna/

Правильно ли я понимаю - предполагается что пользователь должен вручную! устанавливать цены для всех товаров участвующих в акции?