Вообще не вижу "лёгких денег" в "галочке". Ведь помимо того, чтобы её поставить, надо же ещё и сами обновления сделать.
Основная идея: нет обновлений - нет денег, нет денег - нет обновлений.
Клиент покупает продукт (плагин/тему) и получает год (ограниченное время) обновлений. Продлевает - аналогично.
А если клиент по окончанию срока лицензии будет видеть в Инсталлере:
- Мелкие исправления
- Мелкие исправления
- Мелкие исправления
Зачем продлевать обновления на такой продукт (плагин/тему)?
Не хотелось бы опускаться до откровенного саботажа, но как ещё донести мысль?!
Пока не могу раскрывать подробности, но через несколько месяцев все покажем.
Через пару месяцев мы подумаем над обновлением продуктов до ПРЕМИУМ.
А это
имеет полное право делать новые продукты взамен старых, когда приходит время больших обновлений и новых поколений продуктов
разве забота об интересах конечных пользователей?! Новый отдельный продукт устанавливается и настраивается с нуля вместо обновления "одной кнопкой".
Обновления требуют хорошей рекламы
Какие инструменты у нас для этого есть? Публиковать баннер-растяжку, как это делает ШС? А разработчики тем должны публиковать такой баннер сразу во фронтенде?!
Текущая система временной подписки с ограничением функциональности - это рациональная модель монетизации?!
$order_id = 1;
$stock_id = 1;
$original_data = (new shopOrderModel())->getOrder($order_id);
if ($original_data) {
foreach ($original_data['items'] as &$item) {
$item['stock_id'] = $stock_id;
}
// ignore_stock_validate опционально. Если установлено, то новый склад может в минус уйти.
// Если не установлено, то надо ошибки обработать.
$order_new = new shopOrder($original_data, ['ignore_stock_validate' => true]);
$order_new->save();
}
Интересно было бы разобраться почему не работает, если это действительно так. У меня на двух установках (более старый фрейм и ШС и почти актуальный) всё ок. Иначе бы не выкладывал.
Поэтому:
1) Плагин siterouting для ШС(!)
2) Чистим кэш (!!)
3) урл siterouting_url открываем в поселении сайта. Например, /site/siterouting_url
Я к тому, что если менять что-то в редактировании категории, следовало бы аналогично менять и в редактировании товара. Ещё более нелогичным будет, если в категории будет работать хук, а в товаре - нет.
мое дело - указать на проблему
Ну, тогда моё дело указать на потенциальную проблему при решении проблемы "в лоб" XD
Если хук "внезапно" станет вызываться там, где не вызывался ранее, это может привести к проблемам в существующих плагинах.
Ждём интерфейс 2.0. Там, может, будет всё иначе :) Ну или ошибка будет, но уже в другом интерфейсе.
По поводу "дёргать нужные хуки" может быть чревато тем, что плагины могут ожидать данные в POST, чтобы сохранить настройки категории. При редактировании только названия эти данные не передаются. Соответственно, могут быть скинуты какие-то настройки. Такое было со Smart Filters при импорте товаров.
Аналогично хук product_save не вызывается при редактировании названия товара.
Вместо отключения функциональности (которая может кому-то нужна и удобна), можно было бы предложить добавить новый хук.
А если говорить о решении задачи здесь и сейчас, хуки controller_before и controller_after помогут.
Согласен про "понимание", но хуки, имхо должны вызываться отдельно для каждого действия.
Либо должен быть инструмент, который в явном виде даст возможность вызвать один хук вместо другого. И тут тоже важно, чтобы у админа магазина было "понимание".
Категорически против вызова order_action.pay вместо order_action.tipa-oplachen как поведение по умолчанию.
P.S. Для себя взял за практику, что если плагин делает что-то по определённому действию, в настройки такого плагина выношу GROUPBOX с выбором нескольких действий.
Что-то, коллеги, вы ночью решили поспорить о шкуре неубитого медведя. Пока никакой вариант не реализован.
Но почему должен быть только один правильный?
Сейчас тоже можно поставить "неадекватную цену" на всё тот же "снег" (да что к нему приколупались?!) в 49 999. Так делают? Так покупают?
Если конечный клиент видит цену и понимает, как она будет меняться со временем, он сам сможет принять решение о покупке того или иного плагина. А ценовая политика обновлений может стать дополнительным инструментом в конкурентной борьбе аналогов.
Также недурно было бы вывести публично лог изменения цены/политики обновлений. Но это уже другая история.
Плата за конкретные обновления может выглядеть странной
А кому-то покажется странным платить за месяц подписки без обновлений :)
Но, имхо, больше различных вариантов монетизации - лучше. Вероятно и разработчики и их клиенты в конечном итоге нашли бы баланс.
Например, опции, различные комбинации которых, позволили настроить ценовую политику по своему усмотрению:
1) выбор что будет с продуктом без подписки: будет отключён, ограничена функциональность или просто нельзя обновиться?
2) срок подписки: месяц, год или произвольный (по сути плата за отдельные обновления)?
Лично мне бы подошёл вариант с отсутствием обновлений и подпиской на год (ещё и с дисконтом на своевременное продление), либо с платой за отдельные обновления, которые я бы всё-равно не делал чаще. В таком случае я могу строить хоть какие-то прогнозы относительно затраченного на разработку времени.
Но всё сводится к тому, что Webasyst "должны" придумать "идеальный" вариант, вместо того, чтобы дать возможность экспериментировать уже нам.
не надо так пробовать)
Если соблюдать нейминг из поста, выйдет так
где id плагина должен указываться без квадратных скобок.
в ответ на Как вызвать функцию внутри плагина
¯\_(ツ)_/¯
Вот кто-то зайдёт на форум с тем же вопросом, а вы тему удалили.
Написали бы решение, а мы бы с удовольствием его почитали и приняли на заметку ;)
Ну а по теме, можно глянуть как реализовано тут или тут.
Но если хочется жести, её можно устроить при помощи controller_before.* и controller_after.*
Правда, я уверен, что есть решение попроще.
в ответ на Хук редактирования заказа.
@Koin, таков путь.
в ответ на Обращение к руководству Webasyst
Вообще не вижу "лёгких денег" в "галочке". Ведь помимо того, чтобы её поставить, надо же ещё и сами обновления сделать.
Основная идея: нет обновлений - нет денег, нет денег - нет обновлений.
Клиент покупает продукт (плагин/тему) и получает год (ограниченное время) обновлений. Продлевает - аналогично.
А если клиент по окончанию срока лицензии будет видеть в Инсталлере:
Зачем продлевать обновления на такой продукт (плагин/тему)?
Не хотелось бы опускаться до откровенного саботажа, но как ещё донести мысль?!
Через пару месяцев мы подумаем над обновлением продуктов до ПРЕМИУМ.
А это
разве забота об интересах конечных пользователей?! Новый отдельный продукт устанавливается и настраивается с нуля вместо обновления "одной кнопкой".
Какие инструменты у нас для этого есть? Публиковать баннер-растяжку, как это делает ШС? А разработчики тем должны публиковать такой баннер сразу во фронтенде?!
Текущая система временной подписки с ограничением функциональности - это рациональная модель монетизации?!
в ответ на Обращение к руководству Webasyst
В связи с отсутствием каких-то подвижек в данном направлении объявляю забастовку.
Цена на платные плагины будет 9999 как стоимость обновления Shop-Script.
в ответ на Обращение к руководству Webasyst
Где подписывать? :)
в ответ на Обращение к руководству Webasyst
Хук вызывается при загрузке layout'а. При этом контент сайта в основном обновляется аяксом.
Поэтому при хук вызывается по сути только при перезагрузке страницы.
в ответ на getCurrentUrl()
Вы можете принудительно установить язык в настройках профиля (правый верхний угол).
Затем очистить кэш в приложении "Настройки"
в ответ на Проблема с переводом на русский язык
Как-то так:
в ответ на Перемещение по складам в заказе
Странно, у меня такая же нога и не болит.
Интересно было бы разобраться почему не работает, если это действительно так. У меня на двух установках (более старый фрейм и ШС и почти актуальный) всё ок. Иначе бы не выкладывал.
Поэтому:
1) Плагин siterouting для ШС(!)
2) Чистим кэш (!!)
3) урл siterouting_url открываем в поселении сайта. Например, /site/siterouting_url
в ответ на Роутинг плагина если у приложения нет фронтенда ?
плагин не запускал, но осуждаю.
в ответ на Роутинг плагина если у приложения нет фронтенда ?
Я к тому, что если менять что-то в редактировании категории, следовало бы аналогично менять и в редактировании товара. Ещё более нелогичным будет, если в категории будет работать хук, а в товаре - нет.
Ну, тогда моё дело указать на потенциальную проблему при решении проблемы "в лоб" XD
Если хук "внезапно" станет вызываться там, где не вызывался ранее, это может привести к проблемам в существующих плагинах.
в ответ на Переименование категории
Ждём интерфейс 2.0. Там, может, будет всё иначе :) Ну или ошибка будет, но уже в другом интерфейсе.
По поводу "дёргать нужные хуки" может быть чревато тем, что плагины могут ожидать данные в POST, чтобы сохранить настройки категории. При редактировании только названия эти данные не передаются. Соответственно, могут быть скинуты какие-то настройки. Такое было со Smart Filters при импорте товаров.
Аналогично хук product_save не вызывается при редактировании названия товара.
Вместо отключения функциональности (которая может кому-то нужна и удобна), можно было бы предложить добавить новый хук.
А если говорить о решении задачи здесь и сейчас, хуки controller_before и controller_after помогут.
в ответ на Переименование категории
пфф... будет.
в ответ на Роутинг плагина если у приложения нет фронтенда ?
Можно подписаться на хук routing приложения shop или site.
в ответ на Роутинг плагина если у приложения нет фронтенда ?
Это преобразование, например, заложено в основе перевода суммы заказа в текст в печатных формах.
Плюс добавить автоматическую локализацию контролов из настроек, и картинка складывается.
А вот почему в английской не тянется, да и почему подтягивается системная - тайна покрытая мраком.
в ответ на Преобразование чисел в слова в селекте в настройках плагинов
Код - это кука shop_cart. Она генерируется уникальной для каждого покупателя при первом добавлении товара в корзину.
Более подробно логику формирования можно посмотреть в конструкторе класса shopCart.
Про документацию не знаю - не читал :)
в ответ на Как получить содержимое корзины в плагине?
Если код плагина выполняется из браузера от имени конкретного покупателя, то можно получить так
Если вызов API идёт откуда-то извне или, например, из консоли, нужно первым параметром передать код корзины
в ответ на Как получить содержимое корзины в плагине?
Мета-обновления не срабатывают при первой установке плагина.
Для этого есть файл install.php
Особенность мета-обновлений в том, что они помогают обновиться до следующей версии (удалить лишние файлы, внести правки в БД и т.п.).
Временная метка как раз помогает отследить нужно ли выполнять мета-обновление или нет.
Исходная метка будет либо в момент установки плагина, либо в момент установки последнего мета-обновления.
Соответственно, когда пользователь обновит плагин через Инсталлер, выполнятся все мета-обновления с меткой больше исходной.
в ответ на Не устанавливаются метообновления
Тело POST-запроса вроде передаётся не в JSON, а urlencoded.
Вот так:
в ответ на Проблема получения токена при работе с фреймворком
Идея, хотя её следовало публиковать отдельным постом, не нова.
Как я понимаю, по историческим причинам такое уже вряд ли будет реализовано.
Однако добавили хуки notifications_send.before и notifications_send_one.before с передачей параметров по ссылке.
в ответ на В кастомных действиях не срабатывают хуки из настройки "Поведение"
Сейчас и вызывается хук order_action.tipa-oplachen.
В своём плагине можно подписать как на конкретно это событие, так и на любое по маске.
в ответ на В кастомных действиях не срабатывают хуки из настройки "Поведение"
Согласен про "понимание", но хуки, имхо должны вызываться отдельно для каждого действия.
Либо должен быть инструмент, который в явном виде даст возможность вызвать один хук вместо другого. И тут тоже важно, чтобы у админа магазина было "понимание".
Категорически против вызова order_action.pay вместо order_action.tipa-oplachen как поведение по умолчанию.
P.S. Для себя взял за практику, что если плагин делает что-то по определённому действию, в настройки такого плагина выношу GROUPBOX с выбором нескольких действий.
в ответ на В кастомных действиях не срабатывают хуки из настройки "Поведение"
Для работы с заказами используются коллекции. В них есть 3 удобных хука:
Но вот автокомплит не использует коллекций ¯\_(ツ)_/¯
Думаю, что правильным решением было бы не добавление нового хука, а интеграция коллекций в автокомплит.
Вроде обсуждалась такая доработка с кем-то из WA. Но, увы, не помню с кем и где.
в ответ на Хук в поиске заказов
1) Коллекции
Да, активно пользуюсь как коллекциями (1), так и действиями с ними (2)
Не совсем относится к коллекциям, но к разделу товаров: в табличном режиме отдельные колонки (3) или дополняю существующие (4)
в режиме эскизов обычно иконками ограничиваюсь.
Было бы удобно, если бы пункты можно было бы сортировать перетаскиванием, и сортировка бы сохранялась для каждого пользователя отдельно.
в ответ на Использование коллекций товаров в плагинах для Shop-Script
Тут для включения беты нужно согласие двух сторон.
в ответ на Новые возможности для разработчиков: подписка для приложений, бета-тест продуктов без модерации
Время в секундах задаётся. Эта опция устанавливает значение CURLOPT_TIMEOUT при запросе.
Поэтому вероятно, что дробное значение обрезается до 0, а это вовсе отключает ограничение.
в ответ на не работает настройка "Время ожидания ответа от плагинов доставки"?
Что-то, коллеги, вы ночью решили поспорить о шкуре неубитого медведя. Пока никакой вариант не реализован.
Но почему должен быть только один правильный?
Сейчас тоже можно поставить "неадекватную цену" на всё тот же "снег" (да что к нему приколупались?!) в 49 999. Так делают? Так покупают?
Если конечный клиент видит цену и понимает, как она будет меняться со временем, он сам сможет принять решение о покупке того или иного плагина. А ценовая политика обновлений может стать дополнительным инструментом в конкурентной борьбе аналогов.
Также недурно было бы вывести публично лог изменения цены/политики обновлений. Но это уже другая история.
в ответ на Фреймворк Webasyst 2.2.0 и «Фото» для Webasyst 2
А кому-то покажется странным платить за месяц подписки без обновлений :)
Но, имхо, больше различных вариантов монетизации - лучше. Вероятно и разработчики и их клиенты в конечном итоге нашли бы баланс.
Например, опции, различные комбинации которых, позволили настроить ценовую политику по своему усмотрению:
1) выбор что будет с продуктом без подписки: будет отключён, ограничена функциональность или просто нельзя обновиться?
2) срок подписки: месяц, год или произвольный (по сути плата за отдельные обновления)?
Лично мне бы подошёл вариант с отсутствием обновлений и подпиской на год (ещё и с дисконтом на своевременное продление), либо с платой за отдельные обновления, которые я бы всё-равно не делал чаще. В таком случае я могу строить хоть какие-то прогнозы относительно затраченного на разработку времени.
Но всё сводится к тому, что Webasyst "должны" придумать "идеальный" вариант, вместо того, чтобы дать возможность экспериментировать уже нам.
в ответ на Фреймворк Webasyst 2.2.0 и «Фото» для Webasyst 2
Вот есть же вменяемый пример обновлений ШС: покупка возможности обновляться в течение года.
Если за год разработчик ничего не выпустил или выпустил недостаточно для того, чтобы клиент счёл нужным обновиться, то не продлевать, да и всё.
И добавить в Инсталлере галочку "не учитывать в счётчике обновления продуктов с истёкшей лицензией".
в ответ на Фреймворк Webasyst 2.2.0 и «Фото» для Webasyst 2